Привет! Меня зовут Илья, я работаю инженером данных в компании Selectel. В отделе BI мы собираем информацию из внутренних и внешних источников и предоставляем аналитикам.
У нас достаточно большой набор внешних ресурсов, данные из которых нужно собирать и обрабатывать. Среди них — различные SMM-площадки вроде VK и Telegram, платформы лидогенерации, инструменты таргетированной рассылки писем, системы автоматизации и многое-многое другое.
Так как компания развивается, мы спрогнозировали, что число источников тоже будет только расти. И назрела мысль, что нам нужно подобрать специализированное ПО, которое будет отвечать за доставку данных из внешних ресурсов в DWH. Время прошло, идея воплощена: мы используем Airflow и самописные коннекторы на Python. Но могло сложиться все иначе — и мы бы использовали Airbyte, если бы не одно но…
Краткий обзор Airbyte
Когда мы выбирали инструмент для сбора данных, то придерживались двух критериев.
- Хотелось использовать готовые наработки, поскольку каждый источник имеет свои подводные камни в части содержания данных. Люди, которые работали с Google Analytics, понимают, о чем я. И подразумевалось, что готовые коннекторы должны «под капотом» эти проблемы решать.
- Инструмент должен быть open source, чтобы у нас была возможность «причесать» его внутрянку и уверенность, что развитое сообщество поможет с решением технических казусов.
Во время исследования рынка мы наткнулись на видео с многообещающим названием «Новый современный стек данных Airbyte Airflow DBT». В названии мы увидели Airflow, один из самых популярных open source-инструментов оркестрации, и DBT, зарекомендовавший себя инструмент преобразования данных. Поэтому выбор пал на Airbyte.
Кредит доверия к этому инструменту изначально был высок. Также в интернете мы наткнулись на исследования, в которых было сказано про «лидирующие позиции Airbyte на рынке инструментов извлечения данных». Поэтому сомнения были минимальны.
Что предлагает Airbyte
Сегодня в Airbyte доступно более 300 готовых коннекторов, есть интеграция с популярными DE-инструментами вроде DBT, Airflow, Dagster и Prefect. А еще — конструктор, в котором можно «слепить» собственный коннектор при необходимости. Кроме того, фреймворк легко разворачивается на VM, Kubernetes и Docker. Кажется, Airbyte подходит по всем критериям. Или нет?
Что нам не подошло
Возможности шаблонов загрузки
Airbyte позволяет загружать данные при помощи шести шаблонов загрузки.
→ Full refresh – overwrite — из источника приходят все имеющиеся данные; в хранилище полностью перезаписываются строки.
→ Full refresh – append — из источника приходят все имеющиеся данные; в хранилище дописываются новые строки.
→ Incremental sync – append — из источника приходят только новые или измененные данные по ключу (в примере ниже в качестве ключа выступает дата и время); в хранилище дописываются все поступившие строки, удаленные в источнике данные не фиксируются.
→ Incremental sync – deduped history — из источника приходят только новые или измененные данные по ключу (в примере ниже в качестве ключа выступает дата и время); в хранилище дописывается новая информация, обновленные строки обновляются, удаленные в источнике данные не фиксируются.
→ CDC – incremental sync – append — из источника приходят только новые или измененные данные; в хранилище дописываются все поступившие данные, удаленная в источнике информация фиксируется как удаленная.
→ CDC – incremental sync – deduped history— из источника приходят только новые или измененные данные; в хранилище дописывается новая информация, обновленные строки обновляются, удаленные — удаляются.
Подводные камни
Все эти шаблоны применимы только в тех случаях, когда системы-источники поддерживают технологию инкрементальной репликации на основе логирования измененных строк. В случае с Airbyte CDC реализован для источников Postgres, MySQL и MSSQL.
При эксплуатации шаблонов стало понятно, что данный инструмент нам не подойдет. Основная проблема кроется в том, что ряд источников имеет особенность досчитывать различные метрики отчетности через некоторое время, иными словами — менять данные задним числом (возникает проблема backfill-a данных).
К таким особенностями мы хотели приспособиться за счет шаблонов загрузки за указанный период. То есть при обращении к источнику мы бы указывали «дату с» и «дату по», а затем перезаписывали в хранилище данные за указанный период.
Такой метод позволяет реализовать достаточно гибкую механику. Например, в отчетах Google Analytics третьей версии можно задать «плавающее окно» в пять дней. И если данные за вчера досчитались в самом источнике, при следующей итерации загрузки изменения будут учтены.
Однако при изучении возможностей загрузки данных нам не удалось приспособить к такому подходу ни один из шаблонов. CDC-шаблоны хорошо подошли бы для решения данной задачи, но Google Analytics не предоставляет механизмов трекинга изменений, поэтому такой шаблон сразу отпадает.
В настройках источника Google Analytics есть поле Start Date. Оно указывает, начиная с какой даты Airbyte будет забирать данные для отчетов. Для загрузки за определенный период можно было бы использовать данное поле пускай и по текущий день, а не произвольный. Тогда подошли бы шаблоны группы Full Refresh.
Однако эта настройка влияет на все отчеты данного соединения: нельзя «перезагрузить» данные за произвольный период для точечного отчета. Можно, конечно, создать несколько соединений под каждый отчет, но тогда придется сопровождать каждое из них. Кроме того, «из коробки» на данный параметр нельзя влиять вне данной настройки. Это немного ограничивает и не позволяет программно задавать произвольный период.
А как же другие шаблоны
Здесь тоже непросто: группа Incremental Sync в принципе не подходит для такой задачи, так как не предусматривает удаления строк, что вполне возможно при пересчетах задним числом.
Что еще можно было попробовать сделать
Помимо того, что данный источник предоставляет преднастроенный набор отчетом для выгрузки, в настройках источника Google Analytics есть поле Custom Reports, с помощью которого можно задать произвольный набор изменений и метрик в отчете в формате JSON.
Аналогичный формат использовать в самом API Google Analytics четвертой версии. Он позволяет использовать ключ dateRanges, однако Airbyte такой возможности не дает. Указать вы его, конечно, можете, но строить отчет Airbyte будет по собственному параметру Start Date.
Коннекторы
Airbyte действительно предоставляет широкий перечень коннекторов как со стороны источников, так и на стороне «пунктов назначения». Однако есть два нюанса.
Подводные камни
Многие из систем находятся в состоянии разработки. Например, в июне 2023 года PostgreSQL, как конечная точка выгрузки данных, находился в статусе Alpha.
Какие особенности у Alpha-коннекторов? В документации написано так: «Alpha connectors are in development and support is not provided». Сейчас же данный коннектор находится в состоянии Support: Community. Это значит, что за сопровождение коннектора отвечает сообщество, а сама команда Airbyte не планирует его развивать дальше: последние изменения в коннектор разработчики вносили в том же июне.
Аналогичная ситуация с ClickHouse — он на сопровождении у сообщества, а последнее обновление было в июне прошлого года. То же самое касается и источников.
Ожидаемо: мало отечественных систем. Среди отечественных систем, которые мы используем, оказалась только Яндекс Метрика. VK, Huntflow, AmoCRM, Mindbox и других в Airbyte нет. Не то чтобы мы ожидали обратного, но отсутствие этих систем увеличивает количество источников, которые придется настраивать вручную.
Airbyte предоставляет возможность самостоятельно создавать собственные коннекторы в рамках фреймворка. Можно делать как простые коннекторы через интерфейс (с помощью готового конструктора), так и более сложные. На практике второй сценарий встречается чаще и большинство источников требуют дополнительной самостоятельной разработки внутри Airbyte.
Конфигурирование выгружаемой структуры данных
Если в случае Google Analytics мы могли конфигурировать самостоятельно, какие данные и в каком виде будем загружать, то в ряде других источников такой опции нет. Например, если нужно загрузить данные по страницам «популярной социальной сети», то придется выгрузить целых 1 157 атрибутов данного потока данных.
Подводные камни
Кто-то скажет: «Просто грузи ELT, а потом выбирай то, что тебе нужно на других слоях данных». Но нет, данный источник в своем API позволяет выбрать нужный мне набор атрибутов. Иными словами, я могу получить ответ только в «сыром» виде — с заданным набором атрибутов, а не со всеми, которые присущи рассматриваемому объекту.
Однотипность преобразования сложных JSON-структур
Airbyte позволяет загружать данные в сыром виде, используя собственные средства нормализации, либо с помощью DBT. Но нужно учитывать формат, в который будут упакованы данные.
Подводные камни
При загрузке в формате Raw data данные будут упакованы в одну единственную ячейку с типом JSON. Есть также метод basic normalization. Однако при загрузке данных со сложными структурами Airbyte не позволяет влиять на то, как именно будет храниться каждый из объектов. А загружать их с вложенными JSON-ами будет методом создания многоуровневой структуры из подчиненных таблиц.
Кажется, в Pandas метод json_normalize из коробки справляется с этой задачей немного лучше. C этим можно жить, но если бы в Airbyte была возможность выбора нужных атрибутов загрузки, было бы намного удобнее.
Выводы
В целом, Airbyte оставил положительное впечатление о себе, как инструменте и целостном продукте. Фреймворк прост в установке и конфигурировании. Его можно использовать проприетарно, с поддержкой от производителя, или в формате on-premise: задеплоить Airbyte можно в Docker всего за пару кликов.
Решение дружелюбное с прозрачное с точки зрения интерфейса, установки соединения между источниками и хранилищами. Кроме того, в Airbyte большой ассортимент готовых коннекторов, а если их не хватает — можно создать свои через встроенный конструктор. Также разработчики позаботились о пользователях и подготовили не одну готовую интеграцию с популярными в DE решениями, такими как Airflow, Prefect, DBT.
Мы отказались от этого инструмента из-за того, что он не позволяет управлять загрузкой ретроспективных изменений. Данный критерий выбора был для нас критичный в виду специфики сервисов, с которыми мы работаем. Кроме того, коннекторы в Airbyte пока что «сыроваты», а нам нужно быть уверенными, что загрузка из источников работает в штатном режиме. Остальные замечания можно было бы адаптировать под наши потребности, но без первых двух пунктов мы не смогли сделать выбор в пользу Airbyte.
