Операционализация аналитики c инструментами класса reverse ETL – опыт использования Census

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

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

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

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

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

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

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

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

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,

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

2. Команды Sales

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

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

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

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

3. Команды Marketing

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

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

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

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

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

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

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

• 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 syncs, data diffs,

• Работа с особенностями API сервисов: data schema, rate limits, maximum entries,

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

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

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

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

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

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

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

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

• Hightouch

• Census

• Grouparoo (стал частью Airbyte)

• Polytomic

• Omnata

• Hevo Activate

Использование инструментов класса 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.

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

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

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

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

3. Маппинг модели в Census

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

• SQL-запрос,

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

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

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

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

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

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

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

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

• Update or Create

• Update only

• Append

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

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

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

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

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

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

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

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

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

5. Мониторинг и отчетность

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

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

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

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

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

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

2. Developer Experience

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!