ETL и коннекторы

Классический ETL извлекает данные, преобразует их на внешнем сервере, а затем загружает очищенный результат. Современные хранилища меняют порядок последних двух шагов: ELT сначала извлекает и загружает необработанные данные, а затем преобразует их внутри хранилища с помощью SQL.

ELT выигрывает, потому что вычислительные ресурсы хранилища недороги и эластичны. Вы сохраняете необработанные данные навсегда, можете повторно преобразовать их при изменении бизнес-логики и никогда не теряете детали из-за преждевременной очистки.

Коннектор — это механизм EL: он проходит аутентификацию в API источника, по расписанию получает записи и записывает их в таблицы хранилища, соответствующие схеме источника. Он обрабатывает разбиение результатов на страницы, ограничения частоты запросов, повторные попытки и изменения схемы, поэтому Вам не приходится писать хрупкие скрипты.

Управляемые коннекторы превращают недельную работу по подключению API в несколько нажатий для OAuth и настройку частоты синхронизации.

Несколько платформ специализируются на готовых маркетинговых коннекторах. Fivetran и Airbyte — универсальные инструменты EL с сотнями источников. Funnel, Supermetrics и Adverity сосредоточены именно на маркетинговых данных и данных о рекламе.

Компромисс заключается в следующем: управляемые инструменты стоят денег — часто оплата рассчитывается за строку или активный источник, — зато экономят время инженеров и самостоятельно восстанавливаются при изменениях API. Для нестабильных рекламных API такая надёжность очень ценна.

Большинство маркетинговых источников используют OAuth 2.0: Вы предоставляете коннектору доступ с ограниченными правами, который можно отозвать, не сообщая пароль. Коннектор хранит токен обновления и незаметно продлевает доступ.

Следите за сроком действия токена и областями разрешений. Распространённая проблема возникает, когда настроивший подключение маркетолог покидает компанию, отзывает разрешение OAuth, и все последующие синхронизации незаметно прекращаются.

При полной загрузке каждая синхронизация заново получает все записи — это просто, но при большом объёме дорого и медленно. При инкрементальной загрузке извлекаются только записи, изменившиеся с момента последней синхронизации, с помощью указателя, например временной метки последнего изменения.

В большинстве рабочих конвейеров данных для обработки объёма используют инкрементальные синхронизации, а периодические полные обновления — чтобы обнаруживать удаления и исправления. Правильный выбор указателя определяет, получите ли Вы актуальные данные или незаметные пробелы.

API источников меняются без предупреждения: платформа переименовывает поле, добавляет столбец или изменяет тип данных. Это изменение схемы, которое незаметно нарушает работу последующих моделей и панелей.

Хорошие коннекторы автоматически обнаруживают новые столбцы и добавляют их, записывают изменения типов и предупреждают о нарушениях совместимости. Тем не менее слой преобразований следует проверять, чтобы изменение схемы проявлялось как неудачная проверка, а не как неверное число на панели CEO.

Насколько актуальными должны быть маркетинговые данные? Ежедневной загрузки достаточно для отчётности по расходам, а для управления темпом текущих кампаний важны данные в течение дня. Более частые синхронизации означают более высокие затраты на коннектор и хранилище.

Соотносите частоту с принимаемым решением. Панель управления темпом расходования бюджета может синхронизироваться ежечасно, а модель когорт LTV, обновляемая ежемесячно, нуждается лишь в ночной загрузке. Не платите за актуальность, которой никто не пользуется.

Коннекторы должны записывать данные в отдельную схему необработанных данных, не изменяя их и только добавляя новые записи. Никогда не позволяйте аналитикам или инструментам BI напрямую запрашивать необработанные таблицы и никогда не преобразуйте данные на месте.

Необработанная зона — это Ваша страховка: если в преобразовании есть ошибка или бизнес-логика меняется, Вы можете повторить обработку на основе необработанных данных, не запрашивая API заново. Относитесь к ней как к неизменяемой системе учёта.

Конвейер данных может работать и в обратную сторону. Обратный ETL синхронизирует моделированные данные из хранилища с операционными инструментами: передаёт вычисленный сегмент LTV в Meta для создания похожей аудитории или оценку оттока в Salesforce.

Так замыкается цикл. Хранилище перестаёт быть тупиком для отчётности и становится мозгом, который возвращает каналам более эффективное таргетирование и персонализацию.

Вы можете самостоятельно написать экстракторы на Python для каждого API, получив полный контроль и избежав оплаты за строки. Но тогда Вам придётся отвечать за обновление аутентификации, ограничения частоты запросов, разбиение на страницы, изменения схемы и дежурство в случае изменений API в два часа ночи.

Большинство команд покупают управляемые коннекторы для стандартных источников, а собственные решения создают только для нишевых или закрытых систем. Время инженеров обычно более ограничено, чем бюджет на подписку на коннекторы.

Бесшумный сбой конвейера хуже явного, потому что люди продолжают доверять устаревшим панелям. Рабочему EL необходим мониторинг: оповещения об успешности синхронизации, проверки актуальности и обнаружение аномалий в количестве строк.

Установите соглашения об уровне актуальности данных — например, данные о расходах на рекламу не должны быть старше 24 часов — и предупреждайте о нарушении. Доверие к данным строится на знании момента их устаревания, а не на обнаружении проблемы во время совещания.

Вычислительные ресурсы Вашего хранилища недороги и эластичны, а Вы хотите сохранить все детали источника, чтобы повторно моделировать данные при изменении бизнес-логики. Какой способ загрузки подходит и где должны выполняться преобразования?

Коннекторы — это механизм EL, который проходит аутентификацию в источниках, обрабатывает инкрементальные синхронизации и изменения схемы и помещает необработанные данные в неизменяемую зону. Управляемые инструменты, такие как Fivetran, Airbyte и Supermetrics, обменивают стоимость подписки на надёжность.

Современные стеки предпочитают ELT, выполняют преобразования внутри хранилища, добавляют обратный ETL для передачи результатов обратно в каналы и считают мониторинг конвейеров данных и соглашения об уровне актуальности обязательными, а не необязательными.