Как организовать хранилище данных с учетом данных из нескольких источников: бэкенд базы, кликстрим, CRM и коммуникации

Что проверяют

Умеете ли вы спроектировать хранилище от источников до витрин, а не перечислить модные инструменты. Ключевые точки: загрузка из разнородных источников, склейка одного клиента во всех них и хранение истории. Следом просят набросать модель под конкретную метрику, например воронку от клика до сделки в CRM.

Как отвечать

Начните со слоёв: сырой (как пришли, для пересчёта), очищенный (типы, дедупликация, единые форматы), ядро (Data Vault или звёздная схема по Кимбаллу) и витрины под отчёты и модели. Трансформации удобно держать в dbt с тестами unique и not_null, оркестрацию в Airflow или Dagster.

По источникам:

• бэкенд-базы: CDC через Debezium и Kafka из WAL или binlog либо инкрементальная выгрузка по updated_at. Полная ночная перезаливка больших таблиц быстро перестаёт укладываться в окно;
• кликстрим: не «неструктурированные» данные, а поток полуструктурированных JSON-событий огромного объёма. Пишется только добавлением, партиционируется по дате события, хранится в ClickHouse или в объектном хранилище в Parquet. Учитывайте опоздавшие события и дубли от повторных отправок SDK;
• CRM: выгрузка по API с лимитами и инкрементом по дате изменения. Статусы сделок меняются, поэтому историю ведут как SCD2, иначе воронку за прошлый месяц не восстановить;
• коммуникации: письма, звонки, чаты. Метаданные идут в таблицы, тексты и записи в объектное хранилище, персональные данные маскируются и закрываются ролями.

Самое важное: сквозной идентификатор. В бэкенде есть user_id, в кликстриме анонимный device_id до входа в аккаунт, в CRM email и телефон. Нужна таблица соответствий, которая склеивает их по событиям логина и совпадению контактов. Без неё данные лежат рядом, но не связаны.

Где спотыкаются

Отвечают списком инструментов без слоёв и без зерна таблиц. Интервьюер спросит, где строка означает «один визит», а где «одна сделка», и ответа не окажется.

Забывают про историю и поздние данные: отчёт после пересчёта не совпадает с утренним, и никто не объяснит почему.

Не думают о персональных данных. Хранилище, где email и телефоны открыты всем аналитикам, создаёт прямой риск по 152-ФЗ.