Сегодня Операционная аналитика и практики reverse ETL - не столько дань моде, сколько насущная потребность многих компаний. Создать идеальное Хранилище мало, ведь данные создают ценность только тогда, когда вы способны их использовать.

В этой публикации я резюмирую свой опыт выбора решения класса reverse ETL:

  • Место reverse ETL в схеме потоков данных

  • Потребность в решении задач операционной аналитики

  • Различные способы организации reverse ETL

  • Кейс: Census для синхронизации данных в Pipedrive CRM

Место reverse ETL в схеме потоков данных

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

Data Loop (Census)
Data Loop (Census)
  1. Интеграция данных (Extract - Load)

  2. Моделирование, трансформация (Transform)

  3. Бизнес-аналитика (BI / Business Intelligence)

  4. Активация данных (reverse ETL)

Если пункты 1-3 привычны, ожидаемы и знакомы почти всем, то пункт 4 в схеме - что-то новое.

Активация или Операционализация данных - использование обогащенных и достоверных массивов данных (накопленных в Аналитических Хранилищах) в операционных системах. Именно об этих практиках пойдет речь в данной публикации.

Исходя из схемы, более-менее ясным становится происхождение названия этой области работы с данными – reverse ETL, ведь теперь данные из DWH идут в сторону Операционных систем и сервисов, будто замыкая цикл.

Потребность в решении задач операционной аналитики

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

  1. Команды Customer Success

  • Преподнести ценность и набор features продукта в нужное время для клиентов,

  • Корректная приоритизация заявок и клиентских обращений,

  • БОльшие возможности самообслуживания в плане данных, меньшая зависимость от команд Data Analysts,

  • Сокращение времени ответа на распространенные вопросы поддержки.

  1. Команды Sales

  • Автоматический скоринг лидов и заявок по заданным параметрам и характеристикам,

  • Точное понимание того, какие функции больше всего понравились клиентам,

  • Прогнозирование продаж в режиме реального времени,

  • Представление о взаимосвязях контактов и организаций, в которых они работают.

  1. Команды Marketing

  • Использование разнообразных измерений и метрик для сегментации и персонализации предложений,

  • Повышение эффективности экспериментов с таргетингом рекламы и оценкой предпочтений пользователей,

  • Избавление от необходимости в ручных операциях (загрузка адресов электронной почты и прочее),

  • Получение актуальных данных непосредственно в CRM-системе.

Резюмируя, данные создают ценность только тогда, когда вы способны их использовать.

Для полноты картины нелишним будет взглянуть на список интеграций одного из решений класса reverse ETL - Hightouch

Hightouch Integrations List
Hightouch Integrations List

В списке есть сервисы самых разнообразных назначений:

  • Advertising

  • CRM

  • Customer Success

  • E-Commerce

  • Email

  • Live chat & Helpdesk

  • Payments

  • SMS & Push

  • Sales

  • И многие другие

Существуют различные способы организации reverse ETL

  1. Разработка и поддержка собственных интеграций

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

Однако в таком случае следует иметь в виду, что на плечи разработчика ложатся следующие задачи:

  • Обеспечение инфраструктуры (VM, Docker, Lambda),

  • Код логики потоков данных (Python, Java, SQL),

  • Оркестрация операций и data syncs (Airflow, Dagster),

  • Оптимизация потоков данных: incremental syncsdata diffs,

  • Работа с особенностями API сервисов: data schemarate limitsmaximum entries,

  • Обработка ошибок, поддержка retries, мониторинг и уведомления.

И вот уже эта задача не выглядит очень простой.

  1. Автоматизация с помощью инструментов Point-to-Point

Инструменты Point-to-Point или технологии iPaaS (integration platform as a service), такие как ZapierTray и Workato, могут быть привлекательным вариантом для решения сценариев использования Reverse ETL, поскольку они позволяют отправлять данные с одной платформы на другую без единой строчки кода. Однако они создают сеть сложных цепочек, которые тяжело масштабируются.

Point to point schema (Hightouch)
Point to point schema (Hightouch)

Все инструменты iPaaS работают примерно одинаково – они выполняют действия на основе заданного триггера. Вы создаете собственные workflows для каждой интеграции в вашем стеке данных, и уже при наличи 3-4 систем это схема выглядит как что-то, что будет очень тяжело и неприятно поддерживать и развивать.

  1. Использование специализированных сервисов класса reverse ETL

Решения класса reverse ETL создают подход принципа центр - периферия (hub & spoke), в котором хранилище является вашим источником достоверной информации, устраняя сложную паутину связей и потоков между различными сервисами.

Hub & Spoke schema (Hightouch)
Hub & Spoke schema (Hightouch)

Сегодня на рынке можно выделить следующих игроков:

Использование инструментов класса reverse ETL несет несколько ключевых преимуществ:

  • Сокращение времени, которое Data Teams тратят на рутинную и утомительную часть работы по построению и поддержке пайплайнов данных,

  • Интеграция с инструментами Modern Data Stack – Cloud Data Warehouses, dbt, dbtCloud,

  • Использование понятного и надежного решения, выполняющего возложенные на него задачи,

  • Стимулирование принятия взвешенных решений, основанных на достоверных данных (Data Driven Culture),

  • Повышение эффективности работы команд, взаимодействующих с клиентами компании.

Использование Census для синхронизации данных в Pipedrive CRM

Продемонстрирую этапы развертывания решения reverse ETL на примере сервиса Census.

Задача: по мере обновления витрин в Хранилище Данных актуализировать карточки водителей (chauffeurs) в CRM системе с тем, чтобы команда Operations могла быстро и качественно взаимодействовать с новыми и действующими водителями.

  1. Подключение к источнику и приемнику данных

В нашем случае источник - DWH Amazon Redshift, применик - Pipedrive CRM.

Census Data Sources
Census Data Sources
  1. Создание dbt-моделей, используемых для интеграции данных

Это 2 витрины:

  • Deals - потенциальные водители (лиды), которым предстоит пройти аттестацию,

  • People - действующие водители.

reverse ETL dbt models
reverse ETL dbt models
  1. Маппинг модели в Census

Доступны несколько способов создания модели (набора данных) в Census:

  • SQL-запрос,

  • Интеграция с dbt-проектом,

  • Интеграция с Looker (Looks).

После получения списка атрибутов из источника данных, их необходимо связать с атрибутами сервиса-приемника. Иными словами, провести маппинг (соответствие) колонок.

Census Models
Census Models

Поля в источнике и приемнике называются идентично, поэтому Census смог автоматически определить связи, и мне не пришлось щелкать эти соответствия руками, браво!

  1. Создание Syncs и Segments

Хорошо, к этому моменту мы подключились к источнику и приемнику данных, создали необходимые для синхронизации выборки данных (модели), установили маппинг (соответствие) атрибутов.

Следующая задача - установить правила регулярной синхронизации данных.

Опции по стратегии обновления:

  • Update or Create

  • Update only

  • Append

Опции по расписанию обновления:

  • Запуски вручную (Manual),

  • Сron-выражение,

  • Continuous (непрервыно),

  • dbtCloud trigger (после завершения dbt jobs),

  • API call (программный вызов),

  • Sequence (связать в цепочку, например, после одной из других синхрноизаций Census).

Богатый выбор на любой сценарий использования.

Census sync schedule
Census sync schedule

Кроме того, синхронизировать можно определенные сегменты записей (подмножество). В моём случае - это карточки водетелей, разбитые по разным странам. У каждой страны есть локальная команда, которая работает со своим пулом лидов, поэтому у меня таких сегментов 3: RU, FR, UK.

Census sync segments
Census sync segments
  1. Мониторинг и отчетность

После того как всё сконфигурировано, протестировано и установлено на расписание, важно внимательно следить за работой пайплайна, получать уведомления об ошибках и изменениях. Это легко делать в web-панели, либо настроив уведомления на почту или в Slack.

Census sync history
Census sync history

На что еще стоит обращать внимание

  1. Вопросы безопасности потоков ваших данных

  • Безопасное подключение к сервисам,

  • Процессинг данных на стороне вашего Хранилища,

  • Audit & Compliance, проверки сервиса аудиторскими компаниями.

  1. Developer Experience

  • Доступ к программному интерфейсу (API access),

  • Версионирование пайплайнов с помощью git (Syncs Version Control),

  • Расширенное логирование, Debug Mode для детальных проверок и поиска проблемных мест,

  • Автоматический маппинг полей без утомительного перетягивания полей мышкой (для меня это сыграло роль в выборе в пользу Census вместо Hightouch).

  1. Прозрачное ценообразование сервиса

Для планирования трат и бюджета и оценки стоимости использования.

Этим особенностям и многим другим знаниям, связанным с современной и удобной организацией работы с данными я и мои коллеги учим на занятиях Analytics Engineer в OTUS.

Это не просто набор занятий по темам, а единая, связная история, в которой акцент делается на практические навыки, так необходимые компаниям-работодателям. На live-сессиях мы делимся своим опытом и реальными кейсами:

  • Организация Хранилища Данных,

  • Продвинутое моделирование в dbt,

  • Аналитические паттерны и SQL,

  • DataOps-практики: Оркестрация, CI-CD, Data Quality, reverse ETL,

  • Кейсы: Сквозная аналитика, Company's KPI, Timeseries analysis.

Также своими наблюдениями, опытом и практиками я делюсь в ТГ-канале Technology Enthusiast.

Напишите комментарий, если имеете опыт в организации reverse ETL потоков данных. Какую задачу решали, с помощью каких инструментов, чего удалось достичь, с какими трудностями столкнулись?

Спасибо!

Комментарии (0)