Привет, Хабр!
Решили выложить в open source наш конвейер данных RoDL. Если у вас проблемы с выгрузкой и хранением данных из Яндекс.Метрики, Яндекс.Директ, VK Ads или Calltouch, то этот проект создан для вас.
Что это?
Конвейер, который выгружает данные по API и сохраняет их в БД. Запускает выгрузку по расписанию, проверяет данные и заменяет старые если они изменились.
Зачем это?
Построение отчётности, витрин данных, кастомных показателей, в целом быть менее зависимыми от поставщиков данных.
Откуда данные?
На дату публикации добавлены API: Яндекс.Метрика, Яндекс.Директ, VK Ads, Calltouch.
Для кого это?
Небольшие или средние агентства. Бизнес который уже дорос до автоматизации отчётности/процессов, и построения KPI.
Что под капотом?
Prefect 3 + ClickHouse + Телеграмм бот + Пайплайны/конфигураторы/коннекторы для данных. Всё работает внутри Docker Compose.
Конфигурация коннекторов и баз данных - в одном YAML файле. Удобно выключать/включать/добавлять свои коннекторы
Предыстория
Шел 2024 год, в агентстве для построения отчётности использовали бесплатные "коннекторы" (Они так называются в магазине расширений Google Looker St, такое название я и буду использовать). То есть, они нужны для подключения по API и выгрузке данных в момент составления отчёта в Looker St. Такая схема накладывает некоторые проблемы, а именно:
Проблема с самим коннектором. Пользуется коннектором множество человек, а запускается он на бюджетных серверах, в рандомный момент всё может лечь на N количество часов. Для отчётности это критично.
Проблема с API. Иногда сервисы провайдеров данных находятся на обслуживании, или недоступны из‑за высокой нагрузки/сбоев.
Проблема с Looker St. На дату написания статьи не работает в России.
Потребление токенов для запросов. Дашборды и онлайн аналитика затратная по токенам и сложная по агрегации штука.
Провели небольшое исследование, что на рынке вообще есть для выгрузки/хранения данных, а там песня:
Готовые решения существуют, но часто всё равно требуют хостинг своей БД;
Снова привязывание и создание дополнительной сервисной прослойки;
Сложная тарификация, и при больших объёмах выгрузки невыгодная.
Не буду делать подробный разбор, и останавливаться на сторонних решениях, на этом этапе мы решили создавать своё колесо.
К середине 2025 года мы сделали систему, которая состояла по‑сути из разрозненных обработчиков данных и сливала всё в PostgreSQL (Плохой выбор для аналитической БД в связке с BI. Не повторяйте наших ошибок). У такой системы был ряд минусов и узких мест, я решил её довести до ума, в результате появился RoDL.
В open source уже есть проекты которые решают похожие проблемы, отпишусь, почему не Airbyte или Meltano:
Решение спроектировано под специфику API, а не под универсальную модель коннекторов;
Полный контроль над пайплайнами данных: нет ограничений SDK/фреймворка;
Оптимизация под ClickHouse и высокую нагрузку: схема, батчи, очистка диапазонов, запись и обработка данных;
Легко интегрируется с Telegram и, при необходимости, с внешними интерфейсами для логов, управления и уведомлений.
Благодаря выбору такой платформы и нехитрым манипуляциям, получилось реализовать все хотелки
У проекта есть свои фишки
"Обуз" API Яндекс метрики, используя два API: отчётов и Logs.
Чтобы получать данные, которые невозможно совместить из интерфейса.
API отчётов урезано по квотам и запросам. Кроме этого, не все показатели есть в API отчётов, потому данные скрещиваются по ID визита с logs API, получается таблица с любыми доступными по API полями.
Для Яндекс.Метрики обязательно создание выделенного аккаунта и добавления счётчиков на аккаунте в избранное (В системе это "агентский" аккаунт).
Пришли к такому решению так как часто не нужно выгр��жать все счётчики и проще контролировать это через интерфейс метрики: нужно чтобы данные выгружались - добавил доступы, выделил избранным. Клиент ушёл: убрал из избранного. Основной плюс -контролировать выгрузку может любой сотрудник и без доступа к RoDL. Отмечу, что выгрузка происходит на отдельных аккаунтах (желательно), чтобы не упираться в квоты. В доступах добавлено два аккаунта: агентский, который видит все счётчики, и где отмечается избранное, и аккаунт для выгрузки, с него списываются API лимиты. Если у вас несколько агенств — не страшно, логика это поддерживает.
Для Яндекс Директ используются две версии БД: быстрая для отчётов и аналитическая для полноты данных.
Данные в Яндекс Директ, скажем так, имеют свою специфику. Они выгружаются по API уже сгруппированные, нельзя получить сырые строки (1 клиент = 1 строка), сделано это конечно для безопасности пользовательских данных. Но получается ситуация, что при выгрузке сложно сгруппированных данных по миллионам строк, расход начинает дрейф, а именно, расходится потому что Яндекс не отправляют точный расход, а уже слегка его округляет. Чем меньше данных и группировок, тем меньше расхождений с интерфейсом, потому данные разбиты на две БД. Учитывайте, что группировка по уже сгруппированным показателям по процентам или среднему некорректна, грамотно подбирайте показатели и поля для выгрузки.
Коннекторы оптимизированы под квоты API и эффективно их используют, обрабатывают ошибки и умеют проверять изменения и выгружать только дни в которых они были, а не перезаписывают сверху N интервал.
Расписание для запусков можно настроить из файла конфигурации. У Яндекс Директ есть встроенный метод для проверки изменений, но работает он плохо, я бы даже сказал рандомно. Куда честнее выгружать мини‑слайс данных за 60 дней и сверять его с БД, а далее обновлять дни с изменениями. Внимательные заметят: зачем 60 дней? В документации сказано, что данные активно изменяются за последние ~3 дня, но на практике мы регулярно наблюдали как конверсии и клики списываются и более 60 дней назад. Параметр настраивается, можете выбрать другой оптимальный интервал.
Управлять зверополисом можно из телеграм бота, и из админ панели Prefect.
ТГ бот также имеет функции сброса таблиц, массовой/индивидуальной выгрузки данных по клиенту, очистки данных: подскажет клиента у которого давно не было свежих данных. Функционал бота постоянно допиливается, лучше посмотреть в GIT что было сделано на актуальную дату.
С безопасностью все нормально, пользователи не имеют доступа к таблице с данными токенов, чувствительная информация хранится отдельно.
Поддержка “мультиагентских” аккаунтов, и аккаунтов которые не привязаны к агентствам для Яндекса и ВКонтакте.
Для каждого коннектора написана документация, читайте внимательно.
Структура оптимизирована для написания собственных коннекторов. Примеры есть в документации.
Установка
Чтобы загрузить данные, нужно заполнить .env файл, развернуть докер контейнер, через ТГ бота добавить логины/токены и запустить выгрузку. При массовой выгрузке в боте можно задать количество дней для обновления. Первая выгрузка может занимать чуть больше времени.
Полная инструкция в репозитории проекта
Далее добавляете ClickHouse в любую BI, или делайте собственные выгрузки через SQLAlchemy/Spark/DataGrip etc.
Пример нашего дашборда по авто отрасли.
Описания полей соответствует официальной документации API сервисов, буду рад любым предложениям по развитию. Проект преследует цель дать сообществу удобный и быстрый вариант развёртывания собственного хранилища данных, без привязки к платным сервисам.
