Serving: куда уходят данные

Финальная стадия пайплайна — serving: данные доходят до потребителей. Это критическая точка: если на serving сломалось, вся работа DE не приносит ценности.

В этом уроке: пять каналов serving, главные инструменты и как DE с ними работает.

Пять главных каналов

Канал 1: BI-инструменты

Главный канал для большинства компаний. Дашборды, отчёты, KPI.

Что делает DE для BI

• Готовит mart-таблицы — финальные модели в Gold-слое DWH.
• Документирует — описывает, что значит каждая колонка.
• Гарантирует SLA — дашборды должны обновляться до 9 утра, иначе бизнес недоволен.
• Performance — дашборд не должен открываться 30 секунд.

Анти-паттерн: аналитик строит дашборд прямо на raw таблицах с сложным SQL. Когда DE меняет схему raw — дашборд ломается. Правильно — строить на stable mart таблицах, которые DE контролирует.

Канал 2: Ad-hoc SQL

Аналитики и DS пишут разовые SQL-запросы прямо в DWH. Через:

• DBeaver / DataGrip — десктопные клиенты.
• Snowflake UI / BigQuery Console — встроенные web-UI.
• Hex / Mode / Deepnote — SQL + Python notebooks.
• Jupyter — через snowflake-connector-python.

Что DE для этого делает:

• Документирует таблицы (название, описание, owner).
• Даёт права (GRANT SELECT ON ... TO analyst_role).
• Следит, чтобы один тяжёлый ad-hoc запрос не положил DWH (cost controls, resource monitors).

Канал 3: ML Feature Store

Когда у компании серьёзный ML, простого «SELECT из DWH» не хватает:

• ML-моделям нужны фичи в реальном времени (для inference).
• Фичи должны быть переиспользуемы между моделями.
• Должна быть point-in-time correctness (training-serving skew).

Эту проблему решает feature store:

В маленьких командах feature store не нужен — хватает таблиц в DWH. В крупных (где десятки моделей) — must.

Канал 4: Embedded Analytics

«Дашборд внутри твоего продукта». Например:

• Stripe Dashboard для мерчантов («твоя выручка за день»).
• Shopify Analytics для магазинов.
• B2B SaaS, который показывает клиентам их usage-данные.

Инструменты:

• GoodData, Sisense, Domo — embedded BI коммерческие.
• Cube.dev — open-source semantic layer для embedded.
• Кастомные API — backend строит API поверх DWH.

DE-задача: построить быстрые витрины, на которых backend строит API. Обычно это денормализованные таблицы, оптимизированные под конкретные query patterns.

Канал 5: Reverse ETL

Идея: «возвращаем посчитанные данные обратно в SaaS-системы».

Зачем это нужно:

В DWH собирается полная картина клиента: продукты, активность, поддержка. Но продакт-менеджеры и маркетологи работают в Salesforce / Mailchimp / Intercom. Без reverse ETL у них в SaaS — устаревшие данные.

С reverse ETL: рассчитал в DWH «топ-100 клиентов с риском churn» -> загрузил в Mailchimp -> запустил retention-кампанию.

Инструменты:

• Census — лидер reverse ETL.
• Hightouch — главный конкурент.
• Polytomic, Grouparoo — другие.

В МDS-стеке reverse ETL становится таким же стандартом, как ingestion.

SLA и доверие

Главная некодная задача DE для serving — построить доверие:

Реальный пример

E-commerce, как все цепочки serving работают вместе:

DWH (Snowflake)
├── mart.daily_revenue              -> Looker dashboard (продакт)
├── mart.customer_360                -> Census -> Salesforce
├── mart.churn_features              -> Feast -> Online model
├── api.public_metrics_for_partners  -> Backend API -> embedded dashboard
└── (всем доступ через Snowflake UI для ad-hoc SQL)

Один и тот же DWH обслуживает 4 разных канала. DE отвечает за качество данных и SLA на каждом канале.

Распространённые ошибки

Попробуй сам

1. Открой любой public BI-дашборд (например, на public.tableau.com). Подумай: какие mart-таблицы должны быть в DWH, чтобы этот дашборд работал? Какие колонки, какие агрегации?
2. Прочти страницу Census или Hightouch (5 минут на сайте). Подумай: какие 3 use cases reverse ETL были бы полезны твоей компании или воображаемой? Запиши.