Data lakehouse: чем он отличается от data lake и data warehouse

Прямой ответ

Data lakehouse — архитектура, в которой транзакционные свойства хранилища данных (ACID, схема, управление версиями) реализованы поверх дешёвого объектного хранилища с открытыми форматами файлов. Смысл: убрать дублирование данных между «озером» и «складом», оставив одну копию, пригодную и для ML, и для BI.

Сравнение трёх подходов:

Что обеспечивает табличный слой (Iceberg, Delta Lake, Hudi):

1. Манифесты и снапшоты. Каждая фиксация создаёт новый снапшот со списком файлов. Читатели видят согласованное состояние, писатели не мешают друг другу — реализуется оптимистичный контроль с повтором при конфликте.
2. Скрытое партиционирование. Правила партиционирования хранятся в метаданных, поэтому запрос WHERE ts > ... отсекает файлы без явного указания колонок партиций.
3. Эволюция схемы. Добавление, переименование и удаление колонок без перезаписи данных; совместимость изменений важна так же, как в потоковых схемах — см. schema registry.
4. Time travel и откат. Можно читать состояние на момент снапшота и откатывать ошибочную фиксацию.

Ограничения, о которых стоит знать заранее:

• Мелкие файлы. Частые мелкие записи создают тысячи файлов и замедляют планирование; нужна регулярная компакция.
• Метаданные растут. Без обслуживания (expire_snapshots, remove_orphan_files) каталог раздувается, а время планирования запроса растёт.
• Транзакции «между таблицами» отсутствуют. ACID действует в пределах таблицы, поэтому согласованность пайплайна обеспечивают оркестрацией.

Практика: работа с Iceberg на примере

-- создание таблицы с скрытым партиционированием по дню
CREATE TABLE warehouse.events (
  event_id  STRING,
  user_id   BIGINT,
  ts        TIMESTAMP,
  payload   STRING
) USING iceberg
PARTITIONED BY (days(ts));

-- атомарная дозапись
INSERT INTO warehouse.events VALUES ('e1', 42, TIMESTAMP '2026-10-21 10:00:00', '{}');

-- история и откат
CALL system.snapshots('warehouse.events');
CALL system.rollback_to_snapshot('warehouse.events', 1234567890);

-- обслуживание
CALL system.rewrite_data_files('warehouse.events');
CALL system.expire_snapshots('warehouse.events', TIMESTAMP '2026-10-14 00:00:00');

Практические рекомендации:

1. Разделите слои по назначению. Raw (копия источника), curated (очищенные и типизированные данные), marts (витрины). Это упрощает проверки качества и понимание происхождения данных.
2. Компакция — обязательная задача. Настройте rewrite_data_files по расписанию: цель — файлы по 128–512 МБ. Без этого запросы к «свежим» партициям деградируют.
3. Управляйте жизненным циклом снапшотов. Держите историю, достаточную для отката и аудита (обычно дни, не месяцы), и удаляйте устаревшие снапшоты — иначе каталог растёт неограниченно.
4. Выбирайте движок под задачу. Тяжёлые трансформации — Spark; интерактивные SQL-запросы — Trino/Starrocks; потоковая дозапись — Flink или Kafka Connect.
5. Проверяйте производительность на реальных запросах. Скрытое партиционирование не отменяет необходимости понимать, какие файлы читаются; у Iceberg это видно в плане сканирования.

Практический сценарий: пайплайн пишет мелкими файлами и тормозит BI

Контекст: потоковая дозапись событий каждые 5 минут; через месяц дашборд открывается 90 секунд.

1. Диагностика. В метаданных таблицы — 180 тысяч файлов, средний размер 3 МБ. Планирование запроса занимает больше времени, чем само сканирование.
2. Причина. Каждый микропакет создаёт новые файлы в каждой партиции; компакция не настроена, снапшоты не истекают.
3. Исправление. (а) Включаем регулярную компакцию rewrite_data_files с целевым размером 256 МБ; (б) задаём expire_snapshots с удержанием 7 дней и remove_orphan_files; (в) для потоковой записи увеличиваем интервал коммита, чтобы уменьшить число файлов на входе.
4. Проверка. Число файлов сокращается до 4 тысяч, время открытия дашборда — до 6 секунд; проверяем, что time travel за удерживаемый период по-прежнему работает.
5. Профилактика. Добавляем метрики «число файлов на партицию» и «возраст последнего снапшота» в мониторинг; обслуживание включаем в DAG оркестратора, а не в ручные операции.

Результат: производительность восстановлена без миграции данных. Вывод: lakehouse переносит часть обязанностей администратора СУБД на инженера данных — компакция и управление метаданными становятся обязательной рутиной.

Разделение обязанностей в lakehouse. Инженер данных отвечает за табличный слой: компакцию, срок жизни снапшотов, эволюцию схемы и стоимость хранения. Аналитик отвечает за витрины и определения метрик. Граница проходит по табличному формату: если аналитик вынужден вручную запускать обслуживание таблицы, слой спроектирован неверно — обслуживание должно быть частью расписания, а не реакцией на жалобы.

FAQ

Нужен ли lakehouse, если уже есть warehouse? Если все данные уже в warehouse и объёмы управляемы — нет. Lakehouse оправдан, когда большие объёмы живут в объектном хранилище для ML, а копия в warehouse создаётся только для BI: тогда дублирование и расхождения между копиями дороже, чем эксплуатация табличного слоя.

Что выбрать: Iceberg, Delta Lake или Hudi? Все три решают одну задачу. Практические критерии: поддержка нужных движков, зрелость каталога (Hive Metastore, REST, Glue), требования к upsert-нагрузке и к стриминговой дозаписи. Важнее последовательность: выбрать один формат и не смешивать форматы в одном слое.

Даёт ли lakehouse ACID как обычная БД? Даёт ACID в пределах таблицы: атомарные фиксации, изоляцию через снапшоты, согласованность схемы. Транзакций между таблицами нет, поэтому инварианты, охватывающие несколько таблиц, обеспечиваются логикой пайплайна и проверками.

Как в lakehouse попадают изменения из OLTP-баз? Через CDC-поток: изменения из журнала базы публикуются в топики и дозаписываются в таблицы lakehouse. Механика захвата изменений описана в статье про CDC.

Источники: Apache Iceberg docs, Delta Lake, Lakehouse paper (VLDB 2021) — ссылки в шапке.