Десятилетие организации держали две отдельные системы: data lake, дёшево хранивший сырые данные, и структурированный data warehouse для быстрого SQL. Данные обычно копировались дважды, управлялись дважды и порождали две правды. Архитектура lakehouse претендует покончить с этой двойственностью: она соединяет дешевизну объектного хранилища и надёжность warehouse в одном слое.
Проблема: пропасть между lake и warehouse
В классической архитектуре поток был такой: источники → data lake (Parquet/CSV, дёшево, но без ACID) → ETL → data warehouse (быстро, ACID, но дорого и закрыто). Итог: задержка, двойная стоимость, разрыв lineage и спор 'какая копия верна'.
Открытые табличные форматы
Технология, делающая lakehouse возможным, — открытые табличные форматы: Apache Iceberg, Delta Lake и Apache Hudi. Они добавляют слой метаданных поверх Parquet-файлов в объектном хранилище и приносят:
- ACID-транзакции: согласованность при конкурентных чтениях/записях.
- Time-travel: запрос к прошлой версии таблицы (критично для аудита и исправления ошибок).
- Schema evolution: добавление/изменение колонок без перезаписи таблицы.
- Partition evolution: смена стратегии партиционирования без потери производительности.
Medallion-архитектура
В lakehouse данные обычно проходят три слоя качества:
- Bronze: сырые данные из источника, почти нетронутые.
- Silver: очищенные, дедуплицированные, объединённые данные.
- Gold: готовые для бизнеса агрегатные и метрик-таблицы (BI и ML питаются отсюда).
Каждый слой лежит в одном открытом формате; нет отдельной системы, только разный уровень зрелости.
Разделение compute и storage
Экономическое преимущество lakehouse — независимое масштабирование compute и storage. Данные дёшево лежат в S3/ADLS/GCS; в момент запроса движки вроде Spark, Trino, Dremio или Databricks временно поднимают compute. Если ночью никто не запрашивает, стоимость compute падает до нуля; исчезает стоимость 'всегда включённого кластера' warehouse.
Warehouse совсем умирает?
Нет. Для нагрузок BI с очень низкой задержкой и высокой конкурентностью управляемые warehouse вроде Snowflake/BigQuery всё ещё дают более предсказуемую производительность. Многие идут гибридом: lakehouse для raw + silver + ML, warehouse как gold/BI-слой обслуживания. То, что форматы вроде Iceberg читаются и Snowflake, и Spark, упрощает гибрид.
План миграции
Типичная миграция с существующих lake + warehouse на lakehouse:
- Выберите открытый формат (Iceberg или Delta в зависимости от экосистемы).
- Перенесите слои bronze/silver из lake в формат lakehouse.
- Определите gold-слой через dbt или Spark; привяжите метрики к семантическому слою.
- Сначала направьте BI-инструменты на gold-таблицы, затем постепенно выведите warehouse.
- Интегрируйте time-travel и lineage в аудит-процессы.
Заключение
Lakehouse снимает десятилетний выбор между 'дешёвым, но беспорядочным lake' и 'быстрым, но дорогим warehouse' через открытые табличные форматы. Благодаря ACID, time-travel и schema evolution одна копия данных питает и ML, и BI. При правильной постройке исчезают двойная стоимость, двойная копия и спор 'какой верный'.
