Ключевые выводы
- CDP и DWH — две взаимодополняющие системы, и в зрелой enterprise-архитектуре они работают в паре, а не конкурируют
- DWH хранит исторические данные для глубокой аналитики, CDP — операционные данные для real-time активации
- Типовой паттерн: данные сначала собираются в CDP (для скорости), потом архивируются в DWH (для долгосрочной аналитики)
- Совмещение функций приводит либо к медленному CDP, либо к слабой аналитике — каждая система должна решать свою задачу
- Bidirectional интеграция между CDP и DWH — критичная часть архитектуры enterprise-проекта на 5+ млн профилей
CDP и DWH совместимость — частый вопрос на этапе архитектурного проектирования enterprise-CDP-проекта. На бумаге они кажутся похожими: оба хранят данные о клиентах, оба позволяют делать отчёты, оба интегрируются с источниками. На практике это две принципиально разные системы с разными задачами и разной архитектурой.
Эта статья — практическое объяснение различий между CDP и DWH, типичных паттернов их совместной работы и решений по разделению функционала.
Принципиальные различия
| Параметр | CDP | DWH |
|---|---|---|
| Главная задача | Активация данных в реальном времени | Долгосрочная аналитика |
| Латентность чтения | 10-100 мс | 1-60 секунд |
| Модель данных | Профиль клиента + события | Звезда / снежинка / data vault |
| Глубина истории | 2-5 лет (с архивацией) | 10+ лет |
| Тип запросов | OLTP, point-lookups | OLAP, агрегации |
| Пользователи | Маркетинг, операционные процессы | Аналитики, BI-команда, финансы |
| Технологии | PostgreSQL, Redis, Kafka | ClickHouse, Vertica, Snowflake |
Разные задачи требуют разной архитектуры. CDP должна отвечать за миллисекунды на запрос «какой сегмент у клиента X». DWH должна за 30 секунд агрегировать миллиард строк по 20 измерениям. Один движок не может одновременно быть оптимальным для обеих задач.
Типовая интеграция CDP и DWH
Стандартный паттерн в enterprise-проекте на 5+ млн профилей:
- Источники → CDP — события и обновления профилей идут сначала в CDP с минимальной задержкой
- CDP → DWH — раз в час или раз в сутки данные реплицируются в DWH в нормализованном виде
- DWH → BI — на основе DWH строятся витрины и отчёты
- DWH → CDP (опционально) — производные метрики (LTV, CLV, churn score) из DWH возвращаются в CDP для использования в сценариях
Этот двунаправленный поток даёт лучшее из двух миров: CDP остаётся быстрым и ориентированным на активацию, DWH накапливает глубокую историю для аналитики.
Когда совмещение оправдано
В небольших проектах (до 1 млн профилей) роль DWH может закрываться аналитической нагрузкой на CDP — особенно если используется ClickHouse как backend для аналитических запросов. Это даёт экономию на отдельной DWH-инфраструктуре в первые 1-2 года.
Признаки, когда DWH становится необходим:
- Объём данных превышает 10 ТБ
- Аналитические запросы начинают тормозить операционные сценарии
- Возникает потребность в долгосрочной истории (5+ лет)
- Появляются ad-hoc запросы от финансов, аудита, регуляторов
- Нужна интеграция с другими корпоративными системами через DWH (ERP, финансовый учёт)
Антипаттерны при работе с CDP и DWH
Использование DWH как источника для активации
Маркетинг хочет запустить кампанию — выгружает сегмент из DWH, передаёт в email-сервис. Это работает для разовых кампаний, но не для real-time сценариев. Для триггерных рассылок латентность DWH в десятки секунд недопустима.
Хранение истории событий только в CDP
Через 2-3 года CDP накапливает миллиарды событий, и операционные запросы начинают тормозить. Без DWH-архива невозможно безопасно удалить старые данные из CDP.
Дублирование логики между CDP и DWH
Сегмент «VIP-клиенты» рассчитывается и в CDP, и в DWH разными способами. Через полгода — расхождение результатов на 10-15%. Маркетинг отправляет одну версию сегмента, финансы видят другую. Обязательное правило: одна метрика — одно место расчёта, остальные системы получают результат.
Архитектурные паттерны интеграции
CDC (Change Data Capture)
CDP публикует все изменения через CDC-механизм (Debezium, Kafka Connect), DWH потребляет эти изменения и обновляет свои таблицы. Низкая латентность, гарантия доставки, минимальная нагрузка на CDP.
Batch ETL
Раз в час или раз в сутки запускается ETL-пайплайн (Airflow, dbt), который выгружает изменённые данные из CDP и загружает в DWH. Простой паттерн, подходит для проектов без требований real-time аналитики.
Streaming через Kafka
Все события идут в Kafka как первичный source-of-truth, CDP и DWH — независимые consumer'ы. Это даёт максимальную гибкость, но требует зрелой команды и инфраструктуры.
Типовая стоимость инфраструктуры
| Объём профилей | CDP инфраструктура | DWH инфраструктура |
|---|---|---|
| До 1 млн | 1-2 млн ₽ | 0 (опционально) |
| 1-5 млн | 2-4 млн ₽ | 1-2 млн ₽ |
| 5-20 млн | 5-8 млн ₽ | 3-6 млн ₽ |
| 20+ млн | 8-15 млн ₽ | 6-12 млн ₽ |
FAQ о CDP и DWH
Можно ли построить CDP поверх существующего DWH?
Технически — да, но это будет компромиссом. DWH-движок не оптимизирован под точечные запросы по ID профиля с миллисекундной латентностью. Можно использовать DWH как backend для аналитических задач CDP, но операционный слой (профиль, сегменты, real-time) лучше держать отдельно.
Какой DWH подходит для интеграции с CDP?
В РФ в 2026 году типичный выбор — ClickHouse (open source, отлично работает на больших объёмах) или Vertica (коммерческий, классический MPP). Snowflake и BigQuery недоступны без облака зарубежных провайдеров. Для российского enterprise оптимум — ClickHouse self-hosted.
Кто отвечает за качество данных при двунаправленной интеграции?
Принцип one-source-of-truth: если данные приходят из источников в CDP, то CDP — источник правды для DWH. Если LTV и предсказательные метрики рассчитываются в DWH, то DWH — источник правды для CDP. Smешение источников приводит к расхождениям и потере доверия к обоим системам.
Как часто синхронизировать CDP и DWH?
Зависит от потребностей. Для отчётности достаточно раз в сутки. Для near-real-time дашбордов — раз в час. Для строгой синхронизации — CDC через Kafka. Конкретное решение зависит от бизнес-требований и зрелости команды.
Стоит ли использовать data lake вместо DWH?
Для unstructured данных (логи, raw события, файлы) — да. Для structured аналитических задач — DWH остаётся предпочтительным. Современный паттерн — lake-house: data lake как первичное хранилище, DWH как витрина для BI и аналитики.
Что в итоге
CDP и DWH совместимость — это не про «или-или», а про правильное разделение задач. CDP занимается активацией данных в реальном времени; DWH — долгосрочной аналитикой и историей. В зрелом enterprise-проекте оба обязательны, и грамотная интеграция между ними даёт лучший value.
Готовы помочь с проектированием связки CDP и DWH под ваш масштаб и бизнес-требования — обсудим в формате архитектурной консультации.