Lakehouse: ACID на object storage

В прошлых уроках мы разобрались с двумя крайностями:

• Data warehouse — структурированный, быстрый, дорогой, негибкий.
• Data lake — гибкий, дешёвый, любые форматы, но без ACID и схемы.

В 2018-2020 годах появился третий путь: lakehouse — концепт, объединяющий лучшее от обоих миров. Он принёс ACID-транзакции, schema enforcement, time travel и SQL прямо поверх дешёвого object storage. Без переноса данных в дорогой DWH.

К 2026 году lakehouse — основная архитектура для крупных компаний. Snowflake, Databricks, Iceberg-сообщество, BigQuery — все вкладываются в эту модель.

Object storage как foundation

Прежде чем говорить про lakehouse, договоримся о фундаменте, на котором всё это построено. Любой современный data lake (и любой lakehouse) живёт не на классической файловой системе, а на object storage — Amazon S3, Google Cloud Storage, Azure Blob, или их S3-совместимых аналогах (MinIO, Cloudflare R2, Backblaze B2).

Object storage — это key/value хранилище: ключ — это путь к объекту (my-bucket/raw/orders/2026/05/17/data.parquet), значение — байты файла, плюс набор метаданных (размер, дата, теги). Никаких папок физически нет — это всего лишь префиксы в ключах. Запись, чтение и удаление идут через HTTP-API (PUT/GET/DELETE). Цена — копейки за гигабайт: примерно 2-3 цента в месяц на S3 Standard, и в десятки раз меньше на холодных уровнях (Glacier Deep Archive).

Два важных нюанса, которые всплывают на собеседованиях. Во-первых, eventual consistency исторически: до 2020 года S3 не гарантировал, что после PUT следующий GET увидит новые данные сразу — отсюда боли Hadoop-эпохи и “S3-консистентный слой” типа EMRFS. С декабря 2020 S3 даёт strong read-after-write consistency, но в архитектуре lakehouse всё равно закладываются механизмы атомарных коммитов (snapshot-указатель в одном объекте). Во-вторых, intelligent tiering: lifecycle-политики автоматически переносят редко читаемые объекты на более дешёвые уровни (Standard, Standard-IA, Glacier, Deep Archive), снижая стоимость хранения архивов в 10-20 раз без участия инженера.

Проблемы голого data lake

Чтобы понять, зачем нужен lakehouse, вспомни боли обычного data lake:

Эти проблемы решали по-разному. Hadoop-сообщество использовало Hive Metastore, но он не давал ACID. Spark-сообщество жило с “eventual consistency” в S3. Все мечтали о DWH-фичах поверх дешёвых файлов.

Решение пришло в виде open table formats: Apache Iceberg, Delta Lake, Apache Hudi. Они добавляют слой метаданных поверх Parquet-файлов в object storage. Этот слой и реализует ACID, time travel и прочие фичи.

Что такое lakehouse концептуально

Lakehouse — это архитектура, где на одном дешёвом storage слое (S3/GCS/Azure) живут одновременно:

• Сырые файлы (CSV, JSON, изображения) — как обычный lake.
• Open table format (Iceberg/Delta/Hudi) с ACID, time travel, схемой.
• SQL движки (Trino, Spark SQL, Athena, Snowflake) читают и пишут эти таблицы.

Магия в том, что storage и compute разделены полностью. Один lake -> много движков читают параллельно. Никакого vendor lock-in.

Что добавляют lakehouse-форматы

1. ACID-транзакции

Когда пишешь данные в таблицу Iceberg/Delta, всё происходит атомарно. Либо все строки добавились, либо ни одной. Промежуточных состояний нет.

Как это работает технически: новые Parquet-файлы пишутся в storage, и только последним шагом обновляется snapshot (метаданные таблицы), указывающий на новые файлы. Если запись упала — старый snapshot всё ещё валиден, читатели видят старое консистентное состояние.

2. Schema enforcement

В Iceberg/Delta таблице задана схема: имена колонок, типы, опциональность. Если попробуешь записать данные с несовпадающей схемой — операция упадёт. Никаких “случайно прокинули int вместо string”.

3. Schema evolution

При этом схему можно развивать: добавить колонку, переименовать (Iceberg умеет, Delta — частично), изменить тип на совместимый. Старые snapshot’ы остаются читаемыми со старой схемой.

4. Time travel

Можно прочитать таблицу на момент времени в прошлом:

-- Iceberg
SELECT * FROM orders FOR TIMESTAMP AS OF '2026-05-15 10:00:00';

-- Delta
SELECT * FROM orders TIMESTAMP AS OF '2026-05-15';
SELECT * FROM orders VERSION AS OF 42;

Все snapshot’ы сохраняются (с лимитами retention). Это даёт аудит, восстановление после ошибок, воспроизводимость ML-экспериментов.

5. UPDATE / DELETE / MERGE

Голый lake — append-only. В Iceberg/Delta можно делать UPDATE и DELETE:

DELETE FROM orders WHERE customer_id IN (SELECT id FROM customers_to_delete);

UPDATE orders SET status = 'cancelled' WHERE created_at < '2024-01-01' AND status = 'pending';

Под капотом форматы делают это эффективно через “merge-on-read” или “copy-on-write” стратегии (без переписывания всего файла). Это критично для GDPR/CCPA — компании обязаны удалять данные клиентов.

6. Hidden partitioning (Iceberg-specific)

В Hive-style партициях ты пишешь year=2026/month=05/day=17/. Чтобы это работало, в запросе нужно явно фильтровать по year, month, day.

В Iceberg партициинирование “скрытое”: ты пишешь PARTITIONED BY (days(created_at)), а запрашиваешь обычный WHERE created_at >= '2026-05-17'. Iceberg сам поймёт, какие партиции нужны. Это огромный комфорт для аналитиков.

Bronze / Silver / Gold (medallion)

Вернёмся к medallion architecture из первого урока модуля и теперь применим в lakehouse-контексте:

Bronze layer — сырые таблицы, обычно append-only Iceberg/Delta поверх raw-файлов. ETL-инструменты (Fivetran/Airbyte) пишут сюда напрямую.

Silver layer — очищенные, типизированные таблицы. Обычно это:

• удаление дубликатов
• приведение типов и форматов
• базовая валидация
• джойн с reference-данными (страны, валюты)

Gold layer — витрины для конкретного use case. Например:

• daily_revenue_by_country для дашбордов
• customer_features для ML
• cohort_retention для аналитики

В bronze -> silver -> gold обычно используют dbt или Spark. dbt отлично работает с Iceberg/Delta поверх Trino/Databricks/Snowflake.

Преимущества lakehouse

1. Одно хранилище для всех use cases. BI и ML работают с одним lake, не нужно дублировать данные.

2. Дёшево. Цена storage — как у lake. Цена compute — оплачивается отдельно, только за то, что используется.

3. ACID без DWH. Не нужно тащить данные в Snowflake, чтобы получить надёжные транзакции.

4. Open formats. Нет vendor lock-in. Поменять Databricks на Trino — миграция метаданных, файлы остаются.

5. Time travel. Восстановление после ошибочного UPDATE/DELETE — простая операция.

6. GDPR-friendly. UPDATE/DELETE возможен, в отличие от голого lake.

Недостатки

1. Производительность. DWH вроде Snowflake часто быстрее на интерактивных запросах из-за встроенной оптимизации, кэширования, micro-partitions.

2. Сложность. Нужно знать форматы (Iceberg/Delta), каталоги (AWS Glue/Hive Metastore/Unity Catalog), движки (Trino/Spark/Databricks). DWH проще: одна платформа, одно API.

3. Метаданные нужно где-то хранить. Каталог — отдельный компонент, его нужно настраивать.

4. Concurrent writers — bottleneck. Несколько одновременных writers могут конфликтовать на snapshot обновлениях. Iceberg-сообщество работает над этим, но это не infinite scale.

Кто использует lakehouse в продакшене

• Netflix — основной пользователь и спонсор Apache Iceberg. Их lake — петабайты Iceberg-таблиц.
• Apple — мигрировали с Hive на Iceberg.
• Adobe — Iceberg + Spark + Trino.
• Stripe — Iceberg для финансовых данных, в том числе compliance.
• Databricks customers — все используют Delta Lake.
• LinkedIn — переход на Iceberg в продакшене.

В 2026 году большинство Fortune 500 компаний уже либо используют, либо мигрируют на lakehouse.

SQL-движки для lakehouse

Чем читать lakehouse-таблицы:

• Apache Spark — самый универсальный, читает все форматы.
• Trino (PrestoDB fork) — интерактивные ad-hoc запросы.
• AWS Athena — managed Trino от Amazon.
• Databricks SQL — Databricks-движок для Delta Lake.
• Snowflake — с 2023 поддерживает Iceberg как external table.
• DuckDB — для локальной аналитики.
• ClickHouse — недавно добавил Iceberg-чтение.

Попробуй сам

Поставь Docker и запусти MinIO (S3-совместимый локальный storage). Установи Apache Iceberg через pip install pyiceberg. Создай первую Iceberg-таблицу в MinIO, сделай несколько INSERT, попробуй UPDATE, DELETE, time travel через for_snapshot(). Это даёт прочувствовать lakehouse без AWS-аккаунта. Альтернатива — бесплатный Databricks Community Edition: попробуй Delta Lake в их notebook’е.