Архитектура data platform: DWH, Lakehouse, BI и AI-слой
Современная data platform — это не выбор между DWH и data lake, а слоистая архитектура с разделением сырых данных, обработанных моделей, BI-витрин и AI/ML-слоя. Эта статья разбирает компоненты, типичные ошибки построения и подход к зрелой data platform для банка, оператора или промышленного предприятия.
Обсудить задачуЭта архитектурная статья разбирает современную data platform как слоистую архитектуру с DWH, data lake, BI и AI/ML — без выбора «или то, или другое», с фазовым roadmap и реалистичными ожиданиями.
В чём архитектурный вызов
Большинство крупных организаций региона имеют DWH, построенный 5-10 лет назад на основе классических OLAP-инструментов. Параллельно появляются data lake-решения, AI/ML-проекты, отдельные BI-инструменты у каждого бизнес-блока. Без архитектурного видения это превращается в хаос параллельных инициатив с дублированием данных, противоречивыми отчётами и невозможностью масштабировать AI/ML. Современная data platform решает задачу через слоистую архитектуру с явным разделением ответственности слоёв.
Какие системы, потоки и команды вовлечены
- Источники данных — операционные системы (АБС, BSS, CRM, ERP)
- Слой ингестии — стриминг (Kafka, Kinesis) и пакетные процессы (ETL/ELT)
- Хранилище сырых данных (raw layer) — data lake на объектном хранилище
- Слой обработки и моделирования (refined layer) — преобразованные данные с бизнес-логикой
- Аналитический слой (curated layer) — витрины для BI и аналитиков
- AI/ML слой — feature store, обучение моделей, инференс
- Слой управления — каталог данных, lineage, контроль качества, безопасность
Типичные архитектурные ошибки
- Выбор «или DWH, или data lake» — современный подход требует обоих, как разных слоёв одной платформы
- Отсутствие единой модели данных — каждый бизнес-блок строит свои витрины с противоречивой бизнес-логикой
- ETL без контроля качества — данные приходят в DWH с ошибками, отчёты теряют доверие
- AI/ML на данных, недоступных аналитикам — модели работают на одних данных, отчётность на других
- Отсутствие feature store — каждая ML-команда заново строит фичи, дублирование работы и противоречия
- BI-инструменты у каждого бизнес-блока без общего слоя — расходятся метрики, расходятся определения
Возможные подходы
- Lakehouse — единая платформа на основе объектного хранилища с поддержкой ACID-транзакций (Databricks, Snowflake, Apache Iceberg). Современный подход, объединяющий DWH и data lake
- Классический DWH + Data Lake — отдельные системы для разных задач. Зрелый подход для крупных организаций с устоявшимися процессами
- Cloud-native data platform — managed services облака (BigQuery, Redshift, Synapse). Быстрое внедрение, операционная нагрузка ниже
- Hybrid — DWH для регулируемых данных и отчётности, data lake для аналитики и AI/ML
Как обойтись без замены ядра
Data platform строится поверх существующих операционных систем, не заменяет их. АБС, BSS, ERP остаются источниками истины — data platform потребляет события и снимки. При устаревании одной из источников её можно заменить без переделки платформы. Замена существующего DWH на новую платформу — отдельная задача, обычно идущая параллельно с переделкой моделей и витрин.
Риски, зависимости, ограничения
- Качество данных в источниках — платформа не исправит мусор, но сделает его более видимым
- Каталог данных и lineage — без них пользователи не могут найти и понять данные
- Безопасность и контроль доступа — особенно критично для банков и государственных организаций
- Зависимость от облачного провайдера при выборе cloud-native — миграция дорого, выбор требует осознанности
- Кадры аналитиков, инженеров данных, ML-специалистов — конкуренция с крупными технокомпаниями
Как выглядит фазовый путь
- Месяцы 1-4: дизайн целевой архитектуры, выбор технологий, формирование команды
- Месяцы 5-12: построение слоёв ингестии, raw, refined для приоритетных доменов (обычно клиенты + продукты + операции)
- Месяцы 13-18: BI-слой с едиными определениями метрик, миграция критичных дашбордов
- Месяцы 19-24: AI/ML слой с feature store, первые ML-модели в продакшене
- После 24 месяцев — расширение по доменам, постепенная миграция legacy DWH/витрин
Что ещё стоит изучить
Темы из этой же области, которые часто разбираем вместе с этой
CRM
Не коробочный CRM, а правильно выстроенный контур управления клиентами — от первого контакта до лояльности.
→РешениеBI
Аналитика — не красивые графики на стене. Это ответ на вопрос 'почему?' до того, как проблема станет убытком.
→РешениеКонтакт-центр
Контакт-центр — не телефонная станция, а точка, где клиент решает: остаться с вами или уйти. Вопрос в том, как он устроен внутри.
→РешениеОнбординг
Онбординг — первое впечатление клиента о вашей компании. Если оно занимает 5 дней и 12 бумажных форм, второго впечатления не будет.
→Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.
Обсудить применение →Готовы обсудить вашу задачу?
Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.
Обычно отвечаю в течение нескольких часов