Сегодня Операционная аналитика и практики reverse ETL - не столько дань моде, сколько насущная потребность многих компаний. Создать идеальное Хранилище мало, ведь данные создают ценность только тогда, когда вы способны их использовать.
В этой публикации я резюмирую свой опыт выбора решения класса reverse ETL:
Место reverse ETL в схеме потоков данных
Потребность в решении задач операционной аналитики
Различные способы организации reverse ETL
Кейс: Census для синхронизации данных в Pipedrive CRM
Место reverse ETL в схеме потоков данных
Прежде чем приступить к погружению и рассмотрению конкретных инструментов и способов решения проблемы, я предлагаю разобраться в том, какую задачу мы будем решать. Рассмотрим схему потоков данных и этапов работы с ними:
Интеграция данных (Extract - Load)
Моделирование, трансформация (Transform)
Бизнес-аналитика (BI / Business Intelligence)
Активация данных (reverse ETL)
Если пункты 1-3 привычны, ожидаемы и знакомы почти всем, то пункт 4 в схеме - что-то новое.
Активация или Операционализация данных - использование обогащенных и достоверных массивов данных (накопленных в Аналитических Хранилищах) в операционных системах. Именно об этих практиках пойдет речь в данной публикации.
Исходя из схемы, более-менее ясным становится происхождение названия этой области работы с данными – reverse ETL, ведь теперь данные из DWH идут в сторону Операционных систем и сервисов, будто замыкая цикл.
Потребность в решении задач операционной аналитики
Важным шагом будет привести несколько основных сценариев использования практик Reverse ETL. Как правило, всё сводится к тому, чтобы люди, непосредственно взаимодействующие с клиентами компании, имели максимально релевантный контекст и могли бы выстраивать свою деятельность самым эффективным образом.
Команды Customer Success
Преподнести ценность и набор features продукта в нужное время для клиентов,
Корректная приоритизация заявок и клиентских обращений,
БОльшие возможности самообслуживания в плане данных, меньшая зависимость от команд Data Analysts,
Сокращение времени ответа на распространенные вопросы поддержки.
Команды Sales
Автоматический скоринг лидов и заявок по заданным параметрам и характеристикам,
Точное понимание того, какие функции больше всего понравились клиентам,
Прогнозирование продаж в режиме реального времени,
Представление о взаимосвязях контактов и организаций, в которых они работают.
Команды Marketing
Использование разнообразных измерений и метрик для сегментации и персонализации предложений,
Повышение эффективности экспериментов с таргетингом рекламы и оценкой предпочтений пользователей,
Избавление от необходимости в ручных операциях (загрузка адресов электронной почты и прочее),
Получение актуальных данных непосредственно в CRM-системе.
Резюмируя, данные создают ценность только тогда, когда вы способны их использовать.
Для полноты картины нелишним будет взглянуть на список интеграций одного из решений класса reverse ETL - Hightouch
В списке есть сервисы самых разнообразных назначений:
Advertising
CRM
Customer Success
E-Commerce
Email
Live chat & Helpdesk
Payments
SMS & Push
Sales
И многие другие
Существуют различные способы организации reverse ETL
Разработка и поддержка собственных интеграций
Как всегда, любую интеграцию можно сделать собственными силами и множеством различных способов. Вопрос лишь в том, насколько трудоемок будет процесс разработки и поддержки готового решения. Если ваша команда обладает достаточными компетенциями и может себе это позволить, то почему бы и нет?
Однако в таком случае следует иметь в виду, что на плечи разработчика ложатся следующие задачи:
Обеспечение инфраструктуры (VM, Docker, Lambda),
Код логики потоков данных (Python, Java, SQL),
Оркестрация операций и data syncs (Airflow, Dagster),
Оптимизация потоков данных: incremental syncs, data diffs,
Работа с особенностями API сервисов: data schema, rate limits, maximum entries,
Обработка ошибок, поддержка retries, мониторинг и уведомления.
И вот уже эта задача не выглядит очень простой.
Автоматизация с помощью инструментов Point-to-Point
Инструменты Point-to-Point или технологии iPaaS (integration platform as a service), такие как Zapier, Tray и Workato, могут быть привлекательным вариантом для решения сценариев использования Reverse ETL, поскольку они позволяют отправлять данные с одной платформы на другую без единой строчки кода. Однако они создают сеть сложных цепочек, которые тяжело масштабируются.
Все инструменты iPaaS работают примерно одинаково – они выполняют действия на основе заданного триггера. Вы создаете собственные workflows для каждой интеграции в вашем стеке данных, и уже при наличи 3-4 систем это схема выглядит как что-то, что будет очень тяжело и неприятно поддерживать и развивать.
Использование специализированных сервисов класса reverse ETL
Решения класса reverse ETL создают подход принципа центр - периферия (hub & spoke), в котором хранилище является вашим источником достоверной информации, устраняя сложную паутину связей и потоков между различными сервисами.
Сегодня на рынке можно выделить следующих игроков:
Использование инструментов класса reverse ETL несет несколько ключевых преимуществ:
Сокращение времени, которое Data Teams тратят на рутинную и утомительную часть работы по построению и поддержке пайплайнов данных,
Интеграция с инструментами Modern Data Stack – Cloud Data Warehouses, dbt, dbtCloud,
Использование понятного и надежного решения, выполняющего возложенные на него задачи,
Стимулирование принятия взвешенных решений, основанных на достоверных данных (Data Driven Culture),
Повышение эффективности работы команд, взаимодействующих с клиентами компании.
Использование Census для синхронизации данных в Pipedrive CRM
Продемонстрирую этапы развертывания решения reverse ETL на примере сервиса Census.
Задача: по мере обновления витрин в Хранилище Данных актуализировать карточки водителей (chauffeurs) в CRM системе с тем, чтобы команда Operations могла быстро и качественно взаимодействовать с новыми и действующими водителями.
Подключение к источнику и приемнику данных
В нашем случае источник - DWH Amazon Redshift, применик - Pipedrive CRM.
Создание dbt-моделей, используемых для интеграции данных
Это 2 витрины:
Deals - потенциальные водители (лиды), которым предстоит пройти аттестацию,
People - действующие водители.
Маппинг модели в Census
Доступны несколько способов создания модели (набора данных) в Census:
SQL-запрос,
Интеграция с dbt-проектом,
Интеграция с Looker (Looks).
После получения списка атрибутов из источника данных, их необходимо связать с атрибутами сервиса-приемника. Иными словами, провести маппинг (соответствие) колонок.
Поля в источнике и приемнике называются идентично, поэтому Census смог автоматически определить связи, и мне не пришлось щелкать эти соответствия руками, браво!
Создание Syncs и Segments
Хорошо, к этому моменту мы подключились к источнику и приемнику данных, создали необходимые для синхронизации выборки данных (модели), установили маппинг (соответствие) атрибутов.
Следующая задача - установить правила регулярной синхронизации данных.
Опции по стратегии обновления:
Update or Create
Update only
Append
Опции по расписанию обновления:
Запуски вручную (Manual),
Сron-выражение,
Continuous (непрервыно),
dbtCloud trigger (после завершения dbt jobs),
API call (программный вызов),
Sequence (связать в цепочку, например, после одной из других синхрноизаций Census).
Богатый выбор на любой сценарий использования.
Кроме того, синхронизировать можно определенные сегменты записей (подмножество). В моём случае - это карточки водетелей, разбитые по разным странам. У каждой страны есть локальная команда, которая работает со своим пулом лидов, поэтому у меня таких сегментов несколько.
Мониторинг и отчетность
После того как всё сконфигурировано, протестировано и установлено на расписание, важно внимательно следить за работой пайплайна, получать уведомления об ошибках и изменениях. Это легко делать в web-панели, либо настроив уведомления на почту или в Slack.
На что еще стоит обращать внимание
Вопросы безопасности потоков ваших данных
Безопасное подключение к сервисам,
Процессинг данных на стороне вашего Хранилища,
Audit & Compliance, проверки сервиса аудиторскими компаниями.
Developer Experience
Доступ к программному интерфейсу (API access),
Версионирование пайплайнов с помощью git (Syncs Version Control),
Расширенное логирование, Debug Mode для детальных проверок и поиска проблемных мест,
Автоматический маппинг полей без утомительного перетягивания полей мышкой (для меня это сыграло роль в выборе в пользу Census вместо Hightouch).
Прозрачное ценообразование сервиса
Для планирования трат и бюджета и оценки стоимости использования.
Этим особенностям и многим другим знаниям, связанным с современной и удобной организацией работы с данными я и мои коллеги учим на занятиях Analytics Engineer в OTUS.
Это не просто набор занятий по темам, а единая, связная история, в которой акцент делается на практические навыки, так необходимые компаниям-работодателям. На live-сессиях мы делимся своим опытом и реальными кейсами:
Организация Хранилища Данных,
Продвинутое моделирование в dbt,
Аналитические паттерны и SQL,
DataOps-практики: Оркестрация, CI-CD, Data Quality, reverse ETL,
Кейсы: Сквозная аналитика, Company's KPI, Timeseries analysis.
Также своими наблюдениями, опытом и практиками я делюсь в ТГ-канале Technology Enthusiast.
Напишите комментарий, если имеете опыт в организации reverse ETL потоков данных. Какую задачу решали, с помощью каких инструментов, чего удалось достичь, с какими трудностями столкнулись?
Спасибо!
