Data Warehouse обеспечивает согласованную бизнес-аналитику, Data Lake — гибкое хранение исходных данных, а Lakehouse добавляет управляемые таблицы поверх озера для BI и ML. Выбор архитектуры должен опираться на требования к свежести, качеству и стоимости, а не на моду. В гайде разобраны ключевые компоненты, три популярных стека (Snowflake, Databricks, S3+Iceberg+Trino) и пошаговый план внедрения от пилота до эксплуатации.
Что такое Data Warehouse, Data Lake и Lakehouse
Data Warehouse: данные, согласованные для аналитики
Data Warehouse (DWH) — аналитическое хранилище, в котором данные из CRM, ERP, биллинга, приложений и других источников приводят к согласованной модели. Его задача — не просто собрать таблицы, а обеспечить одинаковое понимание выручки, клиента, заказа и других бизнес-сущностей.
В отличие от операционной базы, обслуживающей отдельные транзакции, DWH рассчитан прежде всего на аналитические запросы: сканирование больших наборов данных, объединения, агрегаты и анализ истории.
Типичные сценарии:
- управленческая и финансовая отчётность;
- аналитика продаж, маркетинга, запасов и операций;
- расчёт согласованных KPI для разных подразделений;
- исторический анализ изменений клиентов, продуктов и договоров.
DWH часто связывают с принципом schema-on-write: структура и правила данных определены до публикации для потребителей. Но это не означает, что всё обязательно очищается до первой загрузки: при ELT исходные данные сначала загружают в staging-слой, а затем преобразуют внутри платформы.
Data Lake: исходные данные и гибкость использования
Data Lake — архитектура хранения разнородных данных, обычно на базе объектного хранилища: Amazon S3, Azure Data Lake Storage, Google Cloud Storage или совместимых решений.
В озере могут находиться выгрузки таблиц, события приложений, JSON, логи, документы, изображения и другие объекты. Оно полезно, когда требуется сохранять исходные данные для повторной обработки, исследовательской аналитики и ML.
Принцип schema-on-read означает, что структуру можно интерпретировать при чтении. Это не отменяет необходимости описывать данные: без каталога, владельцев, контроля доступа и сроков хранения озеро становится набором плохо понятных файлов.
Lakehouse: управляемые таблицы поверх озера
Data Lakehouse объединяет объектное хранение с табличным слоем, поддерживающим согласованные изменения, управление схемой и версии данных. Примеры табличных форматов — Apache Iceberg, Delta Lake и Apache Hudi; их возможности и поддержка в движках различаются.
Здесь важно различать три уровня:
- Parquet — формат файлов, в котором физически хранятся данные;
- Iceberg или Delta Lake — табличный формат, описывающий состав таблицы, её состояние и изменения;
- Trino или Spark — движок, который читает и обрабатывает таблицы.
Наличие файлов Parquet в S3 само по себе ещё не создаёт lakehouse. Нужны согласованная работа с метаданными, каталог, совместимые движки и эксплуатационные процедуры.
Lakehouse помогает сократить часть дублирования между BI и ML, но не гарантирует «единственную физическую копию»: витрины, кеши, резервные копии и специализированные представления всё равно могут понадобиться.
Какой подход подходит под задачу
| Критерий | DWH | Data Lake | Lakehouse |
| Основное назначение | Согласованная SQL-аналитика и отчётность | Хранение исходных разнородных данных | Табличная аналитика и обработка на базе озера |
| Типичные данные | Моделированные таблицы и витрины | Таблицы, события, логи, документы, медиа | Управляемые таблицы; рядом могут храниться нетабличные объекты |
| Основные потребители | Аналитики и BI | Инженеры данных, исследователи, ML-команды | Аналитики, инженеры данных и ML-команды |
| Главная инженерная задача | Единая модель и стабильное обслуживание запросов | Обнаружимость, качество и управление доступом | Совместимость движков, обслуживание таблиц и изоляция нагрузок |
| Когда начинать с него | Преобладают регулярные отчёты и SQL | Нужен архив исходных данных и гибкая обработка | BI и обработка данных должны работать на общем табличном слое |
Эти подходы не исключают друг друга. Рабочая архитектура может включать озеро исходных данных, lakehouse-слой для обработки и отдельный DWH для критичных отчётов. Но каждый дополнительный слой должен иметь понятную задачу: иначе он увеличивает число копий, задержки и стоимость сопровождения.
Ключевые составляющие платформы
1. Загрузка: batch, CDC и streaming
Batch — периодические выгрузки, например раз в час или сутки. Это разумный старт, если бизнес не требует немедленного обновления данных.
CDC (Change Data Capture) — передача изменений из операционных баз: вставок, обновлений и удалений. Примеры инструментов — Debezium и коннекторы специализированных платформ загрузки.
Streaming — непрерывная обработка событий через Kafka и вычислительные системы вроде Flink или Spark Structured Streaming.
Airbyte и Fivetran помогают подключать готовые источники, но возможности конкретных коннекторов необходимо проверять: поддержка удалений, история изменений, ограничения API и восстановление после сбоя различаются.
Критически важны идемпотентность, обработка повторов, запоздавших событий и изменений схемы. Повторный запуск загрузки не должен удваивать выручку в отчёте.
2. Слои данных: от сырья к витринам
Удобная модель — Raw → Clean → Marts, также известная в lakehouse-проектах как Bronze → Silver → Gold:
- Raw / Bronze: данные, максимально близкие к источнику, с временем загрузки и техническими идентификаторами.
- Clean / Silver: исправленные типы, дедупликация, согласованные ключи, справочники и правила обработки изменений.
- Marts / Gold: факты, измерения, агрегаты и наборы данных для конкретных бизнес-задач.
Названия слоёв вторичны. Главное — понимать, какие гарантии получает потребитель на каждом из них.
Для BI часто удобна звезда: таблица фактов, например позиции заказов, и связанные измерения — клиент, продукт, дата. Исторические изменения атрибутов можно хранить через SCD, например SCD Type 2. Data Vault имеет смысл рассматривать при сложной интеграции и требованиях к истории, а не использовать автоматически в любом проекте.
3. Хранение и вычисления
Объектное хранилище отвечает за файлы, но не заменяет движок запросов, каталог и управление данными.
MPP-СУБД распределяют аналитическую обработку между узлами. Примеры — Greenplum и другие системы этого класса. Для самостоятельно развёртываемого решения необходимо отдельно оценивать поддержку выбранного дистрибутива, обновления, отказоустойчивость и компетенции команды.
Примеры инструментов для разных задач:
- Spark — распределённая обработка данных и сложные преобразования.
- Trino — SQL-запросы к озеру и объединение данных из разных источников.
- ClickHouse — аналитическое хранение и обслуживание запросов для событийной аналитики, оперативных дашбордов и приложений.
Пересечение ролей и совместное использование. ClickHouse и Trino можно рассматривать как альтернативные движки для части SQL-запросов к озеру, но не как взаимозаменяемые платформы целиком. Они могут использоваться и совместно: Trino — для доступа к разным источникам и полной истории, ClickHouse — для выбранных интерактивных витрин. Состав определяется нагрузкой; использовать оба инструмента необязательно.
4. Роль Trino: SQL поверх распределённых данных
Trino — распределённый SQL-движок, а не самостоятельное хранилище. Через коннекторы он обращается к lakehouse-таблицам и внешним системам, позволяя объединять данные из разных каталогов в одном запросе.
В стеке S3 + Iceberg + Trino роли распределены так:
- S3 хранит файлы;
- Iceberg описывает таблицы и их снимки;
- каталог предоставляет доступ к актуальным метаданным;
- Trino выполняет запросы;
- BI-инструмент показывает результат пользователю.
При этом Trino умеет не только читать: Iceberg-коннектор поддерживает и операции записи. Конкретный набор операций необходимо проверять для выбранного коннектора и версии.
Федерация удобна для исследования и объединения источников, но не бесплатна: скорость зависит от сети, исходных систем и возможности передать им часть вычислений. Тяжёлый запрос к production PostgreSQL может мешать приложению. Для критичной отчётности часто надёжнее заранее загружать данные и строить управляемые витрины.
5. Трансформации и оркестрация
dbt помогает описывать SQL-модели, зависимости, тесты и документацию. Airflow и Dagster координируют процессы: загрузить источник, дождаться готовности, выполнить преобразования, проверить качество и обновить витрину.
Не нужно одновременно вводить несколько оркестраторов без необходимости. Для небольшой платформы достаточно одного понятного механизма запуска и контроля зависимостей.
6. Каталог, качество и безопасность
Следует различать технический каталог таблиц, необходимый движкам, и каталог данных для людей, где находятся описания, владельцы и lineage — связи происхождения данных. Например, Iceberg REST catalog или Hive Metastore решают технические задачи, а DataHub и OpenMetadata помогают искать и понимать данные. Некоторые платформы объединяют несколько функций.
Минимальный набор управления:
- владелец каждого критичного набора данных;
- описание бизнес-метрик и уровня детализации таблиц;
- проверки полноты, уникальности, связности и свежести;
- права по принципу минимально необходимого доступа;
- маскирование чувствительных полей и аудит;
- сроки хранения, удаления и восстановления.
ACID не означает, что данные верны по смыслу. Таблица может быть транзакционно согласованной, но содержать ошибочный курс валют или дважды учтённый заказ.
Три популярных варианта стека
Ниже — три показательных варианта для разных условий, а не рейтинг по доле рынка или универсальной производительности. У облачных продуктов необходимо заранее проверять доступность сервиса, регионов, договора и оплаты для конкретной организации.
1. Warehouse-first: Snowflake + dbt + BI
Состав: коннекторы загрузки → Snowflake → dbt → Power BI, Tableau или другой BI-инструмент.
Подходит команде, у которой основная задача — SQL-аналитика и бизнес-отчётность, а ресурсов на эксплуатацию собственной инфраструктуры немного.
Snowflake также поддерживает Iceberg, поэтому граница между warehouse-first и lakehouse не жёсткая. Однако для Iceberg важно проверять вариант каталога и хранения: доступные функции и ответственность за обслуживание различаются.
На что обратить внимание: стоимость вычислений, простои ресурсов, тяжёлые запросы, межрегиональная передача данных и зависимость от платформенных возможностей.
2. Managed Lakehouse: Databricks + Delta Lake + Unity Catalog
Состав: объектное хранилище → Databricks / Delta Lake → Unity Catalog → Spark и SQL-вычисления → BI и ML.
Подходит, когда аналитика сочетается с инженерными преобразованиями, потоковой обработкой и ML. В этой архитектуре Delta Lake обеспечивает табличный слой, а Unity Catalog — централизованное управление доступом и происхождением данных.
На что обратить внимание: выбор вычислительных ресурсов, разделение интерактивных и пакетных задач, контроль расходов и особенности платформенных функций. Открытый формат таблиц облегчает переносимость данных, но не делает переносимыми автоматически все задания, политики и сервисы.
3. Сборный Lakehouse: S3 + Iceberg + Trino + dbt
Состав: S3 или проверенное совместимое хранилище → Iceberg → совместимый каталог, например Apache Polaris или AWS Glue → Trino → dbt → BI. Airflow или Dagster управляет запусками; Spark можно добавить для задач, которым он действительно нужен.
Подходит команде, которой важны контроль инфраструктуры, открытые форматы и возможность использовать разные движки. Для on-premises требуется собственное объектное хранилище и проверенная совместимость всех компонентов.
На что обратить внимание: отказоустойчивость каталога и вычислений, управление доступом, обновления, наблюдаемость, compaction и очистка устаревших снимков. Отсутствие платы за лицензию отдельных компонентов не означает низкую совокупную стоимость владения.
Таблица сравнения
| Критерий | Snowflake + dbt | Databricks + Delta Lake | S3 + Iceberg + Trino |
| Основной фокус | SQL, BI, согласованные витрины | Инженерия данных, SQL и ML | SQL поверх открытого lakehouse и федерация |
| Модель эксплуатации | Управляемая платформа | Управляемая платформа с настройкой вычислений и заданий | Самостоятельная сборка либо услуги провайдера |
| Главные компетенции | SQL, моделирование, контроль расходов | SQL, Spark/Python, инженерия данных | SQL, распределённые системы, object storage, эксплуатация |
| Открытые таблицы | Iceberg; возможности зависят от конфигурации | Delta Lake; дополнительные форматы и режимы проверяются отдельно | Iceberg; совместимость зависит от каталога и версий движков |
| Подключение внешних источников | Загрузки и интеграции платформы | Загрузки и интеграции платформы | Федерация через коннекторы Trino |
| Основной риск | Расходы и зависимость от сервисов платформы | Сложность заданий, вычислений и контроля затрат | Стоимость собственной эксплуатации и интеграции |
| Предпочтительный сценарий | Нужен управляемый старт для BI | BI и ML развиваются вместе | Нужны контроль, открытый стек и гибкость движков |
Другие решения и гибридные варианты
ClickHouse — колоночная аналитическая СУБД для продуктовой и событийной аналитики, оперативных дашбордов и аналитических функций приложений. Она может быть основным аналитическим хранилищем или слоем быстрых витрин поверх DWH/lakehouse. Например, полная история хранится в озере, а востребованные данные передаются в ClickHouse для интерактивных запросов.
Greenplum и другие MPP-СУБД — варианты для корпоративной SQL-аналитики, в том числе при требованиях к размещению в собственной инфраструктуре. Их стоит оценивать вместе с доступностью поддержки и готовностью команды эксплуатировать платформу.
BigQuery, Redshift и Microsoft Fabric — другие варианты облачной платформы. Если компания уже работает в GCP, AWS или экосистеме Microsoft, их стоит включить в короткий список: существующие компетенции, безопасность и интеграции могут оказаться важнее отдельных функций конкурентов.
Пример дорожной карты типового проекта разработки системы корпоративного хранилища данных
Шаг 1. Зафиксировать требования и критерии успеха
Выберите один бизнес-процесс — например, аналитику заказов и оплат. Определите источники, владельцев, необходимую глубину истории и допустимую задержку обновления.
Примеры критериев для согласования, а не универсальные нормативы: витрина готова к 08:00, данные отстают не более чем на час, расхождения с учётной системой объяснимы, типовой дашборд укладывается в согласованное время ответа.
Шаг 2. Построить один сквозной поток
Начальная цепочка может выглядеть так:
CRM / заказы / оплаты
→ batch или CDC
→ Raw
→ очистка и согласование ключей
→ витрина продаж
→ BI-дашборд
На этом этапе важнее получить проверяемую цифру, чем подключить все источники компании.
Шаг 3. Продумать историю и повторную обработку
Нужно определить, как обрабатываются возвраты, отмены, поздние оплаты, удаления и изменения справочников. Добавьте техническое время загрузки и бизнес-время события; согласуйте часовые пояса и правила пересчёта прошлых периодов.
Проверьте backfill — загрузку исторического периода — и повторный запуск после сбоя. Результат должен оставаться корректным, а нагрузка не должна останавливать текущие обновления.
Шаг 4. Добавить эксплуатационные гарантии
До масштабирования необходимы:
- код моделей и инфраструктуры в системе контроля версий;
- раздельные среды разработки и production;
- тесты и контролируемый выпуск изменений;
- мониторинг задержек, ошибок и стоимости;
- инструкции по восстановлению и ответственные за инциденты;
- резервирование и проверка восстановления, включая каталог и конфигурацию.
Time travel полезен, но не заменяет независимую стратегию восстановления после потери доступа, ошибочного удаления или отказа инфраструктуры.
Шаг 5. Провести нагрузочный и финансовый пилот
Тестируйте не один эффектный запрос, а смесь реальных задач: обновление витрин, одновременную работу дашбордов, тяжёлую аналитику, backfill и восстановление после сбоя.
Считайте совокупные расходы: хранение, вычисления, загрузку, сетевой трафик, лицензии, поддержку и время команды. Универсального обещания «lakehouse дешевле на 60–80%» нет: результат зависит от нагрузки и эксплуатации.
Что чаще всего ломает проект
- Сначала выбирают продукт, потом выясняют бизнес-задачу. Платформа появляется, а полезных витрин нет.
- Откладывают моделирование и владельцев данных. Инструменты не разрешают спор о том, что считать выручкой.
- Вводят streaming без требования к свежести. Сложность растёт без заметной пользы.
- Превращают федерацию в замену всех загрузок. Отчёты начинают зависеть от доступности и нагрузки операционных систем.
- Не обслуживают lakehouse-таблицы. Маленькие файлы и накопленные метаданные ухудшают работу; compaction и retention должны быть частью регламента.
- Принимают открытый формат за полную совместимость. Необходимо проверять типы данных, операции записи, эволюцию схемы и правила конкурентного изменения таблиц всеми движками.
- Выдают доступ только через BI, оставляя открытым хранилище. Прямой доступ к файлам может обойти ограничения SQL-слоя.
Выводы и рекомендации
- Начинайте с потребителей и требований. Для регулярной SQL-отчётности управляемый DWH часто проще; для совместных BI- и ML-процессов стоит оценить lakehouse.
- Не стройте Data Lake как склад файлов без ответственности. Каталог, владельцы, качество и контроль доступа нужны с первого полезного набора данных.
- Разделяйте хранение, табличный формат и вычисления. S3, Iceberg и Trino решают разные задачи; ни один из них по отдельности не является всей платформой.
- Используйте Trino там, где нужны SQL-доступ к озеру и федерация. Для критичных отчётов заранее проверяйте производительность, согласованность данных и влияние на источники.
- Сравнивайте стеки на своём пилоте. Скорость запроса и цена хранения сами по себе не показывают стоимость платформы в эксплуатации.
- Масштабируйте после первого проверенного результата. Один надёжный поток от источника до бизнес-метрики полезнее десятков подключений без понятного потребителя.
- Добавляйте специализированные компоненты по необходимости. Отдельный движок для быстрых витрин, потоковая обработка или ML-платформа оправданы, когда решают конкретную задачу и дают пользу, соразмерную сложности сопровождения.
Хорошая платформа данных — это не максимальное количество компонентов. Это воспроизводимый путь от исходной записи до показателя, которому бизнес может доверять.