Iceberg / Delta Lake / Hudi: lakehouse table formats

Зачем

Parquet на S3 — это compression и predicate pushdown, но НЕ: ACID, snapshot isolation, schema evolution, time-travel, эффективные UPDATE/DELETE, координация параллельных writer-ов, статистика для query-планировщика. Без всего этого "data lake" — это свалка файлов: два job-а одновременно пишут в dt=2026-05-14/, reader видит partial state; добавил колонку — старые файлы её не имеют, query падает; "покажи как было вчера" — нет такой кнопки; обновить одну строку — переписать весь parquet.

Table formats (Apache Iceberg, Delta Lake, Hudi) добавляют metadata layer поверх Parquet/ORC на object storage. Появляются ACID-транзакции через optimistic concurrency, snapshot isolation, schema/partition evolution, time-travel, statistics, row-level updates. Получается lakehouse: object storage за $0.023/GB + warehouse-семантика.

Экономический эффект огромный. Snowflake/Redshift на 1 PB — $100K-500K/год. Lakehouse (Iceberg на S3 + Trino/Spark/Athena) — в 5-10x дешевле по storage + pay-per-query compute. Netflix, Apple, Adobe, Stripe сэкономили миллионы, переехав с warehouse на lakehouse. И выбор формата — архитектурный: от него зависит, какими engine-ами ты сможешь читать, как обрабатывать streaming upserts, какой governance.

Mental model

Table format = metadata layer над Parquet/ORC на object storage, добавляющий ACID, snapshot isolation, schema/partition evolution, time-travel, row-level updates. Превращает S3 в transactional warehouse-like table.

Три ключевые идеи:

1. Иммутабельные snapshot-ы. Каждый commit создаёт новый snapshot; старые не трогаются. Time-travel и rollback бесплатны.
2. Optimistic concurrency через CAS на catalog. Writer читает текущий metadata pointer, пишет файлы и manifest, делает atomic compare-and-swap. Проиграл гонку — ребейзит и ретраит.
3. Manifest с column stats. Reader не сканирует parquet, чтобы узнать что в них — он читает manifest (Avro со min/max/null_count), прунит файлы по predicate и читает 1 файл из 1000. Это и есть магия lakehouse.

Что на диаграмме

Writers (Spark batch + Flink streaming) — два разных профиля: Spark делает большие коммиты редко, Flink — частые микро-batch-и (streaming ingest).

Iceberg Catalog (REST/Polaris/Glue/Nessie) — единственный источник правды о том, какой snapshot "текущий". Здесь происходит атомарный CAS commit. Без catalog-а каждый engine считал бы себя главным — race conditions и потеря данных.

S3 с двумя группами:

• metadata/ — v*.metadata.json (table-level: schema, partition spec, current snapshot ptr), snap-*.avro (manifest list для snapshot), manifest-*.avro (списки data files + column stats).
• data/ — parquet файлы с spec_id (с каким partition layout записан этот файл) и опционально log-*.avro для Merge-on-Read delta-логов.

Readers (Trino, Snowflake, DuckDB, Athena/Spark SQL) — все ходят через catalog, читают свой snapshot, никто никого не блокирует.

Maintenance (Compactor + Snapshot expirer) — отдельные scheduled job-ы для гигиены: compact мелких файлов, expire старых snapshot-ов, удаление orphan-ов после failed commits. Без них lakehouse деградирует за дни/недели.

Сценарии

7 сценариев. Каждый — критический аспект работы table format-а.

• write — атомарный commit. GET current metadata → PUT parquet → PUT manifest + snap list → PUT new metadata.json → CAS commit к catalog. Snapshot isolation: reader до CAS видит старый snapshot, после — новый.

• concurrent — конкурентные writer-ы. Два читают одну base, оба пишут свои файлы, один выигрывает CAS, второй получает CommitFailedException (Iceberg) / ConcurrentAppendException (Delta), читает новый snapshot, ребейзит (файлы уже на S3, не переписываем!) и ретраит. Это и есть ACID over object storage. Glue throttle при >100 ops/sec — лечится REST catalog (Polaris/Tabular) или DynamoDB lock.

• time-travel — FOR TIMESTAMP AS OF. Catalog резолвит timestamp в snapshot_id, reader читает старые metadata + manifest

  • parquet. Use cases: regression debug, ML reproducibility, audit, мгновенный rollback. Trade-off с retention — большое окно дороже по storage.

• mor-vs-cow — Copy-on-Write vs Merge-on-Read. Streaming CDC 10K UPSERT/sec: CoW переписывает 50MB parquet на каждый upsert (write amp x50000). MoR пишет ~100B delta record в log — write throughput высокий, но read деградирует (5x через 30 min, 100x через 24h). Лечение — compactor каждые 30 min.

• schema-evo — evolution без rewrite. Killer feature Iceberg: ADD/DROP/RENAME COLUMN, ADD PARTITION FIELD — meta-only, ZERO data rewrites. Schema resolution по field_id, а не по имени. Старые файлы pruning по date only, новые — по date+bucket. Один SQL — Iceberg сам резолвит layout per file. В Hive это месяцы миграции PB-таблицы.

• read-path — почему запрос быстрый. 4 round trip-а (catalog ~10ms, metadata.json ~5ms, snap-list ~20ms, manifests parallel ~50ms), три фазы pruning (partition → column stats → bucketing) — из 1000 файлов остаётся 1, читаем ~50ms. Итого ~135ms. Без column stats — 50 секунд. Manifest stats == lakehouse magic.

• maintenance — compact + expire + orphan cleanup. Streaming пишет 1800 файлов по 1MB за 30 мин — query 54 сек. rewrite_data_files → 14 файлов по 128MB — 420ms (100x speedup). expire_snapshots удаляет старые snapshot-ы (retention 7-30 dev, 30-90 prod). remove_orphan_files чистит мусор от failed commits — DESTRUCTIVE, safety window 24h, чтобы не снести in-flight uploads.

Trade-offs (ADR)

Скрипт несёт два архитектурных решения на узле catalog-svc.

ADR-001: Iceberg vs Delta Lake vs Hudi — что выбрать в 2026

Контекст. Все три решают одну задачу — ACID + snapshot isolation

• time-travel + schema evolution над Parquet. Все три — Apache. Но оптимизированы под разное:

• Iceberg (Netflix, 2017) — самая универсальная engine support (Spark, Flink, Trino, Snowflake, DuckDB, Athena, BigQuery read), лучшая schema evolution (по field_id), hidden partitioning, partition spec evolution, branching/tagging как в git, vendor-neutral. Snowflake купил Polaris (Iceberg REST catalog) — сигнал индустрии.
• Delta Lake (Databricks, 2019) — Spark-first. MERGE/UPDATE/DELETE первоклассны. Liquid Clustering (2024). Change Data Feed — built-in CDC. Но Spark-centric, Databricks-led.
• Hudi (Uber, 2017) — лучший для streaming upserts (MoR таблицы), built-in DeltaStreamer. Менее universal engines, сложнее операционно.

Решение. Default 2026: Iceberg для нового greenfield lakehouse — широкая engine support (не лочишься на вендора), зрелая schema evolution, Polaris/Tabular ecosystem набирает массу. Delta Lake — если ты уже всецело на Databricks (95% workload в Spark, MERGE-heavy ETL, Unity Catalog). Hudi — узкая ниша: high-frequency CDC-upserts (>10K/sec). Mixed strategy в крупных компаниях — норма (Iceberg для BI, Hudi для realtime CDC, Delta где legacy Spark). Interop: Apache XTable (UniForm) — таблица читается как любой формат.

ADR-002: Copy-on-Write vs Merge-on-Read

Контекст. Два режима update с экстремальными trade-off:

• CoW — UPDATE/DELETE переписывает весь parquet с этой строкой. Read = просто чтение, max performance. Write amp огромный (1KB update → 50MB write при 1M строк в файле). На high-frequency CDC — катастрофа.
• MoR — UPDATE как row-level delete + new data (Iceberg v2) или delta record в Avro log (Hudi). Write дешёвый, read дороже (merge base + logs), без compaction деградирует за дни.

Решение. CoW — для 95% batch analytics (load nightly, query целый день, UPDATE/DELETE редки). Read остаётся быстрым. MoR — только high-frequency upsert сценарии: CDC из OLTP, IoT telemetry, SCD-таблицы. Обязательно настроить compaction (Hudi async every 10-30 min; Iceberg scheduled rewrite_data_files). Без compaction MoR read деградирует 10-100x за дни.

Реальные системы

• Netflix — Iceberg создан здесь, основной формат для всех data warehouses. Multi-PB. Apache donation в 2018.
• Apple — Iceberg для всей analytics platform (replaced Hive). Тысячи jobs, петабайты.
• Adobe, Stripe, Pinterest, Bloomberg, LinkedIn — Iceberg для core analytics и financial reporting.
• Databricks customers — Delta Lake (~thousands), от Comcast до H&M; основной формат для финансов и retail.
• Uber — Hudi (создатели), real-time CDC pipelines.
• Robinhood — Hudi для trading data (низкий upsert latency для пост-trade reconciliation).
• ByteDance — Hudi + Iceberg для рекомендательных систем.
• Airbnb — мигрирует historical Hive на Iceberg.
• Snowflake — купил Tabular (Iceberg vendor) за $1B+ в 2024, поддерживает Iceberg нативно через Polaris.

Anti-patterns

• Streaming без compaction. Тысячи мелких файлов → query медленный (S3 latency × N: 1800 × 30ms = 54s на count(*)). Решение: rewrite_data_files / OPTIMIZE каждые 1-6 часов.
• expire_snapshots не настроен. Storage растёт линейно с retention — через год двойной storage от живых данных. Retention 7-30 дней dev, 30-90 prod; отдельные TAG для critical snapshots.
• Слишком много snapshot-ов для time-travel. Pipeline каждые 5 минут → 100K+ snapshots/year, manifest list slow. Expire агрессивно, не ломая SLA.
• Нет centralized catalog. Без Glue/REST/Nessie каждый engine сам читает metadata — race conditions, потеря данных.
• Schema evolution без плана. DROP+ADD COLUMN с тем же именем в Iceberg даёт новый field_id (хорошо); в Hive данные перепутаются. Не полагайтесь на имена.
• Hudi MoR без compaction service. Read деградирует за дни. Compaction обязателен и мониторится (lag alert).
• OPTIMIZE слишком частый. Compaction перезаписывает гигабайты → S3 PUT cost ($$$). Балансируйте latency vs write cost.
• remove_orphan_files без safety window. Может снести in-flight uploads. Retention 24h минимум.
• Concurrent writes на Glue без proper retry. Glue throttle 100 ops/s — CAS conflict, retry падает, data loss. Лечение: DynamoDB lock или REST catalog с serializability.
• Time-travel для compliance без retention policy. Регулятор требует 7 лет, expire_snapshots сносит через 30 дней — отдельные TAG для audit snapshots, они НЕ expire.
• Mixing форматов (Parquet + ORC в одной таблице) — engines путаются.

Когда НЕ использовать lakehouse

• OLTP workload. Iceberg/Delta/Hudi — analytics формат, оптимизированный под bulk read. Никакой row-level latency, transactional semantics только snapshot-level. Для OLTP — Postgres/MySQL/Spanner.
• Sub-second query SLA на крошечных таблицах. Catalog round-trip
  • metadata.json + snap-list + manifests — это 50-150ms overhead ДО чтения данных. Для маленькой таблицы (100MB) проще DuckDB напрямую на parquet или Postgres.
• Real-time serving (rec systems, fraud). Lakehouse не для feature serving с латентностью <10ms. Используйте Redis/DynamoDB/Cassandra.
• Команда без data engineering. Lakehouse требует операционной дисциплины: compaction, expire, orphan cleanup, catalog reliability. Без выделенного DE — будет деградировать. Маленьким командам проще managed warehouse (Snowflake, BigQuery).
• Очень frequent schema changes (десятки в день). Хотя Iceberg metadata-only, manifest list растёт и query planning замедляется. Лучше versioned API + переход на schema-on-read для нестабильных частей.
• High-frequency точечные UPDATE / single-row lookups. Даже MoR не для этого — append-only stream нескольких строк в logs, но read всегда сканирует minimum 1 file (даже с pruning). Для point lookup — KV-store.

Дальше читать

• Iceberg docs — iceberg.apache.org — spec, format internals, partition spec evolution.
• Delta Lake docs — delta.io — transaction log, Liquid Clustering, Change Data Feed.
• Hudi docs — hudi.apache.org — CoW/MoR internals, compaction, indexing.
• «Apache Iceberg: The Definitive Guide» — Tomer Shiran, Jason Hughes (O'Reilly, 2024). Must-read для production Iceberg.
• Netflix Tech Blog — iceberg tag — reasoning за дизайном Iceberg, реальные failure cases.
• Databricks engineering blog — Delta Lake 3.0, Liquid Clustering deep-dive.
• Uber Engineering — Hudi архитектура, CDC pipelines на петабайтах.
• Onehouse blog — Iceberg vs Delta vs Hudi feature comparison — лучшее cross-format сравнение.
• Apache XTable — xtable.apache.org — interop, одна таблица читается как Iceberg/Delta/Hudi.
• System Design Space — Iceberg architecture.