Data Warehouse vs Data Lake vs Lakehouse¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Матрица — INFERENCE. Термины описывают architectural/storage choices; реальные продукты частично пересекаются. Схема и сценарии — HYPOTHETICAL.
Матрица выбора¶
| Критерий | Warehouse | Lake | Lakehouse |
|---|---|---|---|
| Основной contract | Управляемые analytical tables и SQL | Объекты/raw datasets с отдельными readers | Table semantics поверх lake storage |
| BI/reporting | Сильный типичный сценарий | Требует engines/modeling/governance | Требует compatible SQL engines/modeling |
| Raw/разнообразные inputs | Staging/external capabilities зависят от продукта | Естественное размещение original files | Raw coexistence + structured managed tables |
| ML/exploration | Зависит от integration/export | Гибкий доступ, но нужен контроль | Совместный доступ через table snapshots |
| Transaction semantics | Проверять конкретный engine и scope | Plain files не дают table ACID | Проверять table format, catalog и writers |
| Maintenance | Query/workload/cost management | Schemas, files, catalog и lifecycle | Дополнительно compaction/snapshots/concurrency |
| Replay | Из сохранённой source history | При сохранённой полноте raw | В пределах history/snapshot retention |
| Главный risk | Неучтённые workload/cost ограничения | Data swamp и частичные datasets | Несовместимые engines и ложное multi-table ACID |
Lakehouse может сочетаться с warehouse и lake, а medallion может быть реализован в любом достаточно управляемом analytical store. Наличие Gold layer не определяет формат storage.
Выбор по бизнес-сценарию¶
Закрываемая FinTech отчётность: если команда умеет SQL, входы структурированы, а governance и managed serving важнее универсального file access, warehouse — сильная отправная точка. Нужны report versions и source reconciliation независимо от продукта.
Оригиналы bank statements и odds archive: lake удобен для исходных файлов и длинной истории. Требуются completeness manifest, access control и schema/provenance. Разложить файлы по датам недостаточно для доказательства полноты.
Общие history tables для BI и ML: lakehouse полезен при согласованном table/catalog contract и нескольких engines. До внедрения проверить write/read compatibility, maintenance и recovery catalog. Нельзя сравнить два продукта по vendor benchmark без одинакового workload.
Небольшая платформа: возможна одна SQL-база для analytical marts плюс object archive. Migration в сложный lakehouse должна окупить эксплуатацию.
Возможный hybrid¶
flowchart LR
S["Источники"] --> O["Original files в lake"]
O --> T["Managed lakehouse history"]
T --> M["ML / exploration"]
T --> W["Warehouse marts, если нужны"]
W --> B["Регламентная BI"]Любая дополнительная copy создаёт delivery/retention boundary. Для отчёта фиксировать input table versions, cutoff, dimension versions и rule version; «все прочитали latest» не означает согласованный период.
Ограничения и источники¶
FACT: CIDR 2021 paper обосновывает lakehouse; это исследовательская позиция авторов с vendor affiliation. Paper. FACT: Iceberg reliability и Delta concurrency docs описывают table-level protocols. Iceberg, Delta. Эти источники не подтверждают общую transaction между произвольными tables/stores.
FACT: Monzo описал BigQuery/dbt в 2021 году, FedEx — Medallion platform в 2025. Monzo, FedEx. Выбор этих компаний не является универсальным ответом для других нагрузок.
Типичные ошибки проектирования¶
Выбирать по storage price; назвать Parquet directory транзакционной таблицей; не backup-ить catalog; считать time travel бессрочным audit; объединять разные engines без compatibility testing.
Вопросы на собеседовании¶
Нужен ли lakehouse всем BI-командам? Нет; определить workloads, governance, skills и стоимость эксплуатации.
Что проверять при disaster recovery? Metadata/catalog, data files, permissions и корректность queries на восстановленном consistent snapshot.
Практические упражнения¶
Для payout reporting задайте source cutoff и воспроизводимый dataset release в warehouse и lakehouse вариантах. Покажите, что случится, если одна dimension обновится между двумя queries. Ожидается явный contract согласованности, а не ссылка на слово ACID.