Lakehouse¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Уровень: организация аналитического хранения и доступа. Проверка источников: 2026-11-02.

1. Назначение и решаемая проблема¶

Эти подходы определяют, где хранить историю, как публиковать структуру данных и какие вычисления доступны потребителям. Выбор начинается с workloads: регламентная SQL-отчётность, исследование raw events, ML feature preparation, интерактивная аналитика.

Это не три взаимоисключающих продукта. Компания может держать raw archive в lake, контролируемые marts в warehouse и часть таблиц lakehouse для совместной SQL/ML работы.

2. Принцип работы¶

Warehouse организует управляемые аналитические таблицы и модели; data lake сохраняет разные данные в доступном storage с отдельными engines и governance; lakehouse добавляет к lake управляемые table semantics, metadata, snapshots и совместимое чтение.

Практическое различие проявляется в commit protocol и access contract. Папка Parquet не становится транзакционной таблицей от подключения SQL engine. И warehouse может иметь отделённые compute/storage и читать external tables: нельзя сводить сравнение к «новый cloud против старого appliance».

3. Архитектурная схема¶

flowchart TB
    S["Operational sources"] --> I["Ingestion и contracts"]
    I --> W["Warehouse: managed tables"]
    I --> O["Lake: raw objects"]
    O --> T["Lakehouse: table metadata и catalog"]
    W --> B["Governed BI"]
    T --> B
    O --> M["Exploration и ML compute"]
    T --> M

4. Walkthrough движения данных¶

Operational source экспортирует согласованный snapshot или CDC; ingestion регистрирует scope и schema.
Warehouse-вариант преобразует input в управляемые таблицы, моделирует facts/dimensions и публикует бизнес-marts.
Lake-вариант сохраняет original objects. Для безопасного потребления нужны schema discovery, ACL, catalog, lifecycle и способ отличить complete dataset от незавершённого upload.
Lakehouse-вариант пишет data files в staging, затем публикует table snapshot через поддержанный catalog/transaction protocol. Читатель видит committed snapshot.
BI выбирает зафиксированный report release; ML читает разрешённые исторические данные. Один физический storage не делает два расчёта семантически одинаковыми.
Сверка сравнивает source coverage и analytical outputs, а не только число файлов.

5. Технологии реализации¶

Warehouse: BigQuery, Snowflake, Redshift, PostgreSQL/ClickHouse для определённых аналитических workloads. Lake: S3/MinIO/ADLS, Parquet/Avro, catalog и SQL/compute engines. Lakehouse: Iceberg/Delta/Hudi плюс поддерживающие engines и catalog.

FACT: CIDR 2021 paper формулирует Lakehouse как сочетание открытых форматов с warehouse-подобными возможностями. Это авторская исследовательская позиция создателей решения, а не доказательство превосходства всех lakehouse над всеми warehouse. Paper.

6. Консистентность и гарантии обработки¶

Гарантии задаются на уровне конкретной операции и реализации. Iceberg/Delta table snapshots не означают общую транзакцию всех витрин и внешнего payment API. Raw objects без commit manifest могут дать читателю частичный набор.

Для согласованного закрытия периода фиксировать source cutoff, table versions, dimension versions и расчётную логику. Текущая аналитическая проекция обычно eventual относительно OLTP. Ни один из трёх терминов не является гарантией low-latency authoritative balance.

7. Отказы и восстановление¶

Сбой	Recovery	Остаточный риск
Upload остановился	Убрать incomplete objects либо не публиковать manifest	Читатели plain directory могли увидеть часть
Table commit не подтверждён	Проверить commit identity/catalog state перед retry	Повторная загрузка без dedup создаёт duplicate
Catalog недоступен	Восстановить catalog и metadata, проверить ссылки на files	Одних data files может быть недостаточно
Удалён старый snapshot	Restore из backup либо source	Time travel ограничен фактическим retention

Backup нужен и для metadata, и для данных. Проверка recovery должна включать запросы и контрольные суммы, не только наличие bucket.

8. Масштабирование и узкие места¶

Warehouse расходует ресурсы на concurrent queries, joins и ingestion. Lake сталкивается со small files, listing/metadata overhead и неуправляемыми schemas. Lakehouse добавляет maintenance: compaction, snapshot expiration и конфликтующие writers.

Сравнивать стоимость владения с учётом operators, governance и backfill. Object storage дешевле на единицу хранения не гарантирует меньшую стоимость всей платформы. Разделение workloads и admission control нужны во всех вариантах.

9. Преимущества и недостатки¶

Warehouse удобен для управляемой SQL-отчётности, но может ограничивать разнообразие доступа. Lake гибок для raw/ML и archive, но требует организации данных. Lakehouse объединяет ряд сценариев, но предъявляет требования к совместимости writers, catalog и query engines.

Универсальный вывод «lakehouse заменяет warehouse» без workload и migration cost неверен. Hybrid сохраняет гибкость ценой нескольких copies и reconciliation.

10. Альтернативные решения¶

Medallion определяет quality layers поверх выбранного хранения. Polyglot Persistence допускает специализированные stores. Для небольшого объёма может хватить read replica и отдельных SQL marts.

Подробная матрица выбора сравнивает report workload, archive, ML и table maintenance.

11. Реальные примеры и границы подтверждения¶

FACT: Monzo в публикации 2021 года описывает аналитическую платформу на BigQuery и dbt. Это пример warehouse-oriented analytics, не описание основного банковского ledger. Monzo.

FACT: FedEx описывает Enterprise Data Platform с Medallion и Databricks. Это пример управляемой аналитической платформы; механика multi-table consistency в тексте раскрыта не полностью. FedEx.

Реальные deployment details и неизвестное остаются привязаны к дате каждого материала.

12. Применение в FinTech и iGaming¶

FinTech: warehouse marts для закрываемых отчётов, lake для оригинальных bank files, lakehouse для длинной transactional history и feature preparation. Financial ledger остаётся отдельной операционной системой.

iGaming: raw odds/activity archive, аналитические таблицы для player history и exposure analysis. Поддержка corrections важнее labels: нужно знать, какие consumers увидят обновлённый settlement и с какой задержкой.

13. Типичные ошибки проектирования¶

Называть любой bucket lakehouse.
Предполагать общий ACID между всеми таблицами и engines.
Проводить сравнение по одному storage price.
Удалять historical files, на которые ещё ссылаются snapshots.
Читать latest dimensions в отчёте, который должен быть воспроизводимым.

14. Вопросы технического интервью с ответами¶

Чем lakehouse отличается от lake с SQL? Нужны управляемые table semantics и совместимый commit/metadata protocol, а не только возможность выполнить SELECT.

Нужна ли миграция из warehouse ради ML? Не обязательно: оценить connectors, export, стоимость копий и требования model training.

Почему backup bucket недостаточен? Catalog и snapshot metadata определяют, какие файлы составляют корректную таблицу; без них восстановление не гарантировано.

15. Практическое упражнение¶

HYPOTHETICAL: требуется хранить оригинальные settlement files, строить закрываемый SQL-отчёт и обучать модель на bet history. Спроектируйте один hybrid и один lakehouse-вариант.

Для каждого перечислите authoritative inputs, commit boundary, dataset versions, disaster recovery и права доступа. Критерий: отчёт повторяется после изменения справочника, а пропавший catalog не считается автоматически восстановленным из набора Parquet. Синтетические performance numbers не требуются.

Дополнительные источники¶

CIDR 2021 Lakehouse paper; Iceberg reliability; Delta concurrency.