Ключевые выводы
- Архитектура CDP простыми словами — это 5 слоёв: ingestion (приём), storage (хранение), processing (обработка), activation (активация), governance (управление)
- Каждый слой решает свою задачу и может быть реализован разными технологиями — от простых до enterprise-grade
- Для CIO главное — понимать, как слои связаны между собой, а не детали технической реализации каждого
- Сложность CDP-архитектуры растёт нелинейно с объёмом данных и количеством каналов: 1 млн профилей и 1 млн профилей с omnichannel — разные задачи
- Правильное проектирование архитектуры на старте экономит 30-50% бюджета развития системы в горизонте 3 лет
Архитектура CDP on-prem простыми словами — это объяснение того, как платформа на самом деле работает, в терминах, понятных нетехническому руководителю. Большинство CIO принимают решение о CDP-проекте без глубокого понимания архитектуры — и потом удивляются, почему «простой» проект стоит 22 млн ₽.
Эта статья — практическое объяснение архитектуры CDP без жаргона. С аналогиями из мира банков и складов, в которых каждый компонент имеет понятный аналог.
Аналогия: CDP как умный складской комплекс
Чтобы понять архитектуру CDP, представим складской комплекс крупной компании:
- Приёмка — куда поставщики привозят товары (= ingestion: приём событий из источников)
- Склад — где товары хранятся, систематизированные по типам (= storage: хранение профилей и событий)
- Логистика — где товары обрабатываются, упаковываются, переставляются (= processing: обработка данных, создание сегментов)
- Отгрузка — куда едут готовые партии для клиентов (= activation: отправка коммуникаций, передача в маркетинговые сервисы)
- Охрана и управление — кто следит, чтобы всё работало по правилам (= governance: безопасность, аудит, compliance)
Каждый из этих слоёв в CDP — отдельная подсистема со своими технологиями.
Слой 1: Ingestion (приём данных)
Задача — получить данные из источников и привести в общий формат. Источники бывают:
- Real-time события — клики, просмотры, добавления в корзину (поступают мгновенно)
- Периодические выгрузки — выгрузки из 1С, ERP, бухгалтерии (раз в день или раз в час)
- Внешние API — данные от партнёров, рекламных систем
- Файловые загрузки — CSV, Excel-файлы из ручных операций
Технически реализуется через REST API, очереди (Kafka), CDC (Change Data Capture), ETL-пайплайны. Чем больше источников — тем сложнее этот слой.
Слой 2: Storage (хранение)
Задача — сохранить данные в формате, удобном для быстрого чтения и поиска. CDP использует несколько типов хранилищ:
- OLTP БД (PostgreSQL, MySQL) — для текущего состояния профилей, быстрого чтения по ID
- OLAP БД (ClickHouse, Vertica) — для аналитических запросов и сегментации
- Кэш (Redis, Memcached) — для часто запрашиваемых данных, сегментов клиента
- Event store (Kafka, EventStoreDB) — для журнала всех событий
- Архив (S3-совместимое хранилище) — для долговременного хранения
В крупных CDP-проектах используются все 5 типов параллельно. Каждое хранилище решает свою задачу.
Слой 3: Processing (обработка)
Задача — превратить «сырые» события в полезную информацию. Включает:
- Identity resolution — склейка разных профилей одного клиента в единый
- Сегментация — расчёт принадлежности к сегментам по правилам и ML-моделям
- Производные метрики — LTV, RFM, частота покупок, churn probability
- Триггерные сценарии — обнаружение событий, требующих коммуникации
- Real-time scoring — мгновенный расчёт скоров (cредний чек, склонность к покупке)
Обработка может быть batch (раз в день) или streaming (в реальном времени). Streaming сложнее технически, но даёт быструю реакцию на события клиента.
Слой 4: Activation (активация)
Задача — использовать обработанные данные для коммуникаций и персонализации. Каналы активации:
- Email — массовые и триггерные рассылки
- Push — мобильные уведомления
- SMS — критичные коммуникации (платежи, доставка)
- Мессенджеры — Telegram, WhatsApp
- Личный кабинет — персонализированный контент на сайте
- Контактный центр — данные для оператора при звонке клиента
- Реклама — передача сегментов в рекламные сети
Каждый канал требует своей интеграции и своих метрик качества доставки.
Слой 5: Governance (управление и контроль)
Задача — обеспечить соответствие законам, безопасность и качество данных. Включает:
- RBAC — разделение ролей, кто что видит и меняет
- Audit trail — журнал всех операций для compliance
- Согласия и право на забвение — управление 152-ФЗ
- Шифрование — защита данных at-rest и in-transit
- Backup и DR — резервное копирование и восстановление
- Мониторинг — наблюдение за работой всех слоёв
Как слои взаимодействуют
Стандартный поток данных в CDP:
- Клиент кликает на сайте → ingestion принимает событие
- Событие записывается в storage (event store + обновление профиля)
- Processing пересчитывает сегменты клиента и проверяет триггеры
- Если триггер сработал — activation отправляет коммуникацию
- На каждом этапе governance логирует операцию для аудита
Весь поток в production занимает 100мс - 5 секунд в зависимости от архитектуры. Real-time CDP — менее 1 секунды; batch-CDP — минуты или часы.
Сложность по объёму
| Объём базы | Сложность архитектуры | Команда DevOps |
|---|---|---|
| До 1 млн профилей | Простая (single-server) | 0.5 FTE |
| 1-5 млн профилей | Средняя (HA в одном ЦОД) | 1 FTE |
| 5-20 млн профилей | Сложная (HA + DR) | 1-2 FTE |
| 20+ млн профилей | Enterprise (sharding, DR, multi-region) | 2-4 FTE |
Как читать архитектурные диаграммы
Когда поставщик показывает архитектурную диаграмму CDP, обращайте внимание на:
- Какие компоненты в каждом слое — должны быть представлены все 5 слоёв
- Стрелки между компонентами — это интеграции, каждая стоит денег и требует поддержки
- Точки отказа — есть ли HA на каждом слое или один компонент может «уронить» систему
- Дубликаты и кэши — где данные хранятся в нескольких местах и как обеспечивается их синхронизация
- Внешние зависимости — какие сервисы требуются от провайдера или партнёров
FAQ об архитектуре CDP
Можно ли построить CDP на одной СУБД?
Технически — да, для базы до 1 млн профилей. На больших объёмах одна СУБД становится bottleneck'ом и появляется потребность в нескольких типах хранилищ. Это типовой путь развития: стартуем на PostgreSQL, добавляем ClickHouse для аналитики, потом Kafka для event-streaming.
Что важнее — производительность или гибкость архитектуры?
Гибкость в долгосрочной перспективе. Производительность можно улучшить через тюнинг и масштабирование, а архитектурные решения, принятые на старте, влияют на проект годами. Поэтому важно проектировать на 3-5 лет вперёд.
Сколько компонентов должно быть в CDP минимум?
4-5: ingestion gateway, основная БД, processing service, activation service, governance/admin. Меньше — это обычно монолит с проблемами масштабирования. Больше 15-20 — оверинжиниринг для большинства задач.
Можно ли использовать microservices с самого начала?
Не рекомендуется для проектов до 5 млн профилей. Microservices добавляют сложности эксплуатации без существенных выгод на малых объёмах. Лучше — модульный монолит, который при необходимости разбивается на сервисы.
Как меняется архитектура с ростом проекта?
Эволюционно: на старте — монолит с одной БД; через год-два — выделение processing-слоя; ещё через год — добавление event store; на enterprise-масштабе — переход на microservices с CQRS. Каждый шаг требует 3-6 месяцев работы.
Что в итоге
Архитектура CDP on-prem простыми словами — это 5 слоёв с понятными задачами и аналогиями из реального мира. Понимание этих слоёв помогает CIO принимать обоснованные решения по выбору поставщика, бюджету и срокам проекта.
Готовы провести архитектурную консультацию для вашего проекта и помочь спроектировать оптимальную CDP-архитектуру под ваш масштаб и compliance-требования.
Дополнение: типовые вопросы CIO на пресейле
Если вы только начинаете разбираться с темой и общаетесь с поставщиками, архитектура CDP on-prem простыми словами помогает задать правильные вопросы:
- Какие технологии используются на каждом из 5 слоёв вашего решения?
- Что произойдёт при отказе одного компонента — система продолжит работу или встанет?
- Сколько FTE требуется на эксплуатацию вашей архитектуры в нашем масштабе?
- Какие типы хранилищ используются и где будут размещены наши данные?
- Как реализован governance-слой — RBAC, аудит-след, шифрование?
- Какие интеграции уже готовы к нашему tech-stack?
- Как ваша архитектура справляется с высокими нагрузками в high-season?
Качественный поставщик отвечает на эти вопросы конкретными именами компонентов и цифрами SLA. Размытые ответы вроде «у нас всё гибко настраивается» — повод усомниться в зрелости решения. Архитектура CDP on-prem — это конкретные технологии и связи между ними, а не маркетинговые слайды.