Перейти к содержанию
Learning Platform
Глоссарий Troubleshooting
Урок 18.03 · 35 мин
Продвинутый
Delta LakeIcebergHudiPaimonTable FormatSelectionEcosystemStreamingEngine Compatibility

Выбор Table Format: Delta Lake vs Iceberg vs Hudi vs Paimon

Все четыре table format’а обеспечивают ACID-транзакции, time travel и schema evolution поверх Parquet-файлов. На уровне feature matrix — они почти одинаковы. Различия — в архитектурных решениях, которые делают каждый формат оптимальным для определённого контекста.

В модулях 11 (Delta Lake), 12 (Iceberg), 13 (Hudi) и 14 (Paimon) мы детально разобрали архитектуру каждого. Здесь — синтез: когда что выбирать и почему.

NOTE

Этот урок — не пересказ фичей (это есть в модулях 11–14). Мы сравниваем по критериям выбора: экосистемная зрелость, engine-совместимость, стриминг-поддержка, стоимость обслуживания, vendor lock-in, community momentum.

Критерий 1: Engine Compatibility

Самый жёсткий фильтр — какие query engines поддерживают формат в production, а не на уровне “experimental connector”.

Engine Compatibility Matrix (production-grade)
EngineQuery engines с production-grade поддержкой формата. 'Production-grade' = полная поддержка read/write/merge, используется в production крупными компаниями, активно поддерживается.
Delta LakeDelta Lake: начинался как Spark-only. С Delta Lake 3.x + UniForm: совместимость с Iceberg readers. delta-rs: Rust-native библиотека для Python/Rust без Spark.
IcebergIceberg: изначально engine-neutral. Широчайшая поддержка engines. Каталог-центричная архитектура делает интеграцию проще.
HudiHudi: Spark + Flink + Presto/Trino. Менее широкая поддержка, чем Iceberg, но глубокая интеграция с Spark и Flink для streaming use cases.
PaimonPaimon: Flink-first. Spark и Trino read support есть, но write — преимущественно через Flink. Самый молодой из четырёх.
SparkApache Spark — доминирующий batch engine для data lakehouse. Поддержка формата в Spark — must-have для большинства data teams.
Нативная интеграция: Delta Lake создан Databricks для Spark. Photon engine в Databricks — оптимизирован под Delta. OSS Spark: полная поддержка через delta-spark. Best-in-class.
Полная поддержка через spark-iceberg runtime. Read, write, merge, schema evolution, hidden partitioning. Production-ready на Spark 3.3+.
Полная поддержка через hudi-spark-bundle. Read, write, upsert, incremental pulls. COW и MOR. Production-ready на Spark 3.3+.
Read + Write поддержка через paimon-spark. Менее зрелая, чем Flink интеграция: некоторые features (changelog, bucket) доступны только через Flink.
FlinkApache Flink — доминирующий stream processing engine. Streaming write в lakehouse — ключевой use case.
Поддержка через delta-flink connector. Менее зрелая, чем Spark. Streaming write: работает, но не first-class citizen.
Полная поддержка через flink-iceberg. Streaming write, upsert mode. Production-ready. Netflix, Apple используют Flink→Iceberg в production.
Полная поддержка: Flink streaming write с upsert, incremental read. Hudi Flink engine — second-class vs Spark, но production-ready.
Нативная интеграция: Paimon создан командой Flink (бывший Flink Table Store). Streaming write, changelog, bucket — всё доступно. Best-in-class.
Trino/PrestoTrino (бывший PrestoSQL) — interactive query engine. Быстрые ad-hoc запросы на lakehouse.
Trino Delta connector: read-only до недавнего времени, write support добавлен в Trino 420+. Ограниченная merge поддержка.
Полная поддержка: Trino Iceberg connector — first-class. Read, write, merge, time travel, hidden partitioning. Один из лучших коннекторов в Trino.
Read support через Hudi connector. Write — ограниченная. Merge — через Spark/Flink.
Read support через Paimon Trino connector. Write — только через Flink. Ранняя стадия.
DuckDBDuckDB — embedded analytical database. Растущая популярность для локальной аналитики, BI, data science.
delta-rs интеграция: read support через PyArrow/DuckDB. Write: через delta-rs Python. Полноценная работа из Python notebook.
iceberg-python + PyArrow: read support. DuckDB Iceberg extension — experimental. Менее зрелая, чем Delta через delta-rs.
Через PyArrow + hudi-python. Базовая read поддержка. Менее удобная, чем Delta/Iceberg.
Минимальная: через экспорт в Parquet. Нет нативного Paimon коннектора для DuckDB.

Практический вывод по engine compatibility

Рекомендация по engine
Spark-firstЕсли Spark — основной engine: Delta Lake (если Databricks) или Iceberg (если OSS Spark/EMR/Dataproc). Оба формата — first-class citizens в Spark. Delta Lake чуть лучше на Databricks (Photon оптимизации), Iceberg — vendor-neutral.
Flink-firstЕсли Flink — основной engine для streaming: Paimon (Flink-native) или Iceberg (широкая экосистема). Paimon — лучшая Flink-интеграция, но экосистема уже. Iceberg — шире, но streaming write менее оптимизирован.
Multi-engineНесколько engines (Spark + Trino + DuckDB + Flink): Iceberg — наибольшая совместимость. Каталог-центричная архитектура делает multi-engine доступ проще: один REST catalog, все engines подключаются.

Критерий 2: Streaming Support

Для стриминг-workload’ов (CDC, event streams) — не все table format’ы одинаково эффективны:

Streaming: архитектурные различия
Hudi MORMerge-on-Read: мгновенная запись в log files (Avro), merge при чтении. Record-level index: O(log N) upsert по ключу. Timeline: incremental queries — downstream читает только изменения с последнего checkpoint. Подробнее: Модуль 13, уроки 02 и 05.
PaimonLSM-tree хранение: memtable → flush → merge. Changelog producer: downstream получает поток изменений (INSERT/UPDATE/DELETE). Bucket partitioning: параллелизм записи. Flink-native: checkpoint integration. Подробнее: Модуль 14.
Delta LakeStructured Streaming: micro-batch write через Spark Structured Streaming. MERGE: batch upsert (не streaming-native). Change Data Feed (CDF): читать изменения как таблицу. Менее оптимизирован для row-level streaming upsert, чем Hudi/Paimon.
IcebergFlink Iceberg Sink: streaming write. Row-level deletes: position deletes + equality deletes (v2). Incremental scan: через snapshot-based filtering. Нет нативного changelog — downstream строит diff по snapshots.
TIP

Для CDC с высокочастотным upsert (> 10K upserts/s): Hudi MOR (record-level index) или Paimon (LSM-tree). Delta Lake MERGE и Iceberg row-level deletes работают, но дороже: Delta сканирует файлы для поиска строк, Iceberg создаёт delete files. Подробнее о стоимости MERGE: Delta Lake, урок 02, Iceberg, урок 05.

Критерий 3: Maintenance Overhead

Table format — не “поставил и забыл”. Каждый требует фоновых операций обслуживания:

Maintenance: что каждый формат требует
ОперацияФоновые операции, необходимые для поддержания производительности и управления storage.
DeltaDelta Lake: VACUUM + OPTIMIZE + ANALYZE. На Databricks: авто-оптимизация. На OSS Spark: ручной scheduling.
IcebergIceberg: expire_snapshots + rewrite_data_files + rewrite_manifests. Maintenance procedures через SQL или API.
HudiHudi: compaction (MOR) + clustering + cleaning. Table services — автоматизация. Но настройка — нетривиальна.
PaimonPaimon: compaction (LSM-tree) + snapshot expiration + partition expiration. Compaction в Flink — автоматически при checkpoint.
CompactionОбъединение мелких файлов в крупные. Без compaction: тысячи мелких файлов → metadata overhead, медленный scan (file-open overhead). Частота: ежечасно или ежедневно, зависит от write volume.
OPTIMIZE: перезаписывает мелкие файлы в крупные. Auto-compaction на Databricks. OSS: ручной запуск через spark.sql('OPTIMIZE table'). Liquid Clustering (Delta 3.x): автоматическая кластеризация.
rewrite_data_files: bin-packing или sort-based compaction. Ручной запуск через SQL: CALL catalog.system.rewrite_data_files(table). Автоматизация: через Airflow/cron.
MOR compaction: merge log files в base files. Inline (при записи) или async (фоновый процесс). Clustering: пересортировка данных. Table services: автоматизация через Hudi config.
LSM-tree compaction: автоматическая при Flink checkpoint. Не требует ручного scheduling — Flink управляет. Для batch: ручной запуск compact action.
CleanupУдаление устаревших файлов (после time travel retention). Без cleanup: storage растёт бесконечно (старые версии файлов не удаляются).
VACUUM: удаляет файлы старше retention period (default 7 дней). spark.sql('VACUUM table RETAIN 168 HOURS'). Обязательно: без VACUUM storage растёт линейно с количеством writes.
expire_snapshots: удаляет старые snapshots + orphaned files. remove_orphan_files: удаляет файлы без ссылок. Два отдельных maintenance action'а.
Hudi Cleaner: автоматическая очистка по hoodie.cleaner.policy (KEEP_LATEST_COMMITS / KEEP_LATEST_FILE_VERSIONS). Настраивается — работает при каждом commit.
Snapshot expiration: автоматическая (настройка retention). Partition expiration: TTL для партиций.
СложностьСубъективная оценка операционной сложности: сколько усилий требует поддержание формата в healthy state.
Низкая на Databricks (авто-оптимизация). Средняя на OSS Spark (нужен scheduling OPTIMIZE + VACUUM). Liquid Clustering упрощает — но требует Delta Lake 3.x.
Средняя: 3-4 maintenance procedures нужно scheduling через Airflow/cron. Нет встроенной авто-оптимизации (кроме Tabular managed). Зато — предсказуемое поведение.
Высокая: compaction + clustering + cleaning — три вида maintenance. Множество настроек (hoodie.compact.inline.max.delta.commits, hoodie.clustering.plan.strategy). Мощная автоматизация, но сложная настройка.
Низкая при Flink: compaction и cleanup — автоматические. Средняя без Flink: нужен ручной запуск compact/expire actions.

Критерий 4: Vendor Lock-in

Vendor Lock-in: спектр зависимости
IcebergМинимальный lock-in: Apache Foundation проект, не привязан к одному вендору. REST Catalog — открытый стандарт, поддерживается AWS (Glue), GCP (BigLake), Snowflake, Databricks, Tabular, Dremio. Переход между вендорами: замена catalog, данные остаются.
Delta LakeСредний lock-in: open-source (Linux Foundation), но Databricks — основной contributor и бенефициар. UniForm (Delta 3.x): генерация Iceberg-совместимых metadata — снижает lock-in. delta-rs: Rust-native, без Spark зависимости. Но premium features — на Databricks.
HudiСредний lock-in: Apache Foundation проект. Uber — основной contributor, но AWS (EMR, Glue) и Alibaba активно вкладываются. Специфичные Hudi concepts (Timeline, FileGroup, MOR/COW) требуют Hudi-specific tooling. Менее универсальный, чем Iceberg.
PaimonВысокий lock-in в экосистему Flink: Paimon = бывший Flink Table Store. Без Flink — значительно ограниченная функциональность. Apache Foundation, но community меньше, чем у Iceberg/Delta/Hudi.

Критерий 5: Community и Momentum

Размер community — прокси для скорости развития, качества документации, доступности помощи и долгосрочной жизнеспособности.

Community Momentum (2024–2025)
МетрикаМетрики здоровья open-source проекта. GitHub stars — популярность. Contributors — активность разработки. Releases — частота обновлений. Adoption — крупные компании в production.
DeltaDelta Lake: backed by Databricks. Стабильный рост, особенно после open-sourcing UniForm и Liquid Clustering.
IcebergIceberg: самый быстрый рост adoption 2023-2025. Apple, Netflix, Airbnb, LinkedIn — в production. Snowflake Iceberg Tables, Databricks UniForm.
HudiHudi: стабильное community. Uber, AWS, ByteDance в production. Рост замедлился относительно Iceberg, но CDC use case — сильная ниша.
PaimonPaimon: молодой проект (graduated Apache 2024). Быстрый рост в Flink ecosystem, особенно в China (Alibaba, ByteDance).
ТрендНаправление momentum: растёт, стабильно, или снижается.
Стабильный рост. UniForm снимает lock-in опасения. Delta Kernel — embeddable library без Spark.
Самый быстрый рост: стал де-факто стандартом для multi-engine lakehouse. Snowflake, Databricks, AWS, GCP — все поддержали.
Стабильно: сильная ниша в CDC/streaming. AWS EMR — default for Hudi. Но Iceberg забирает часть mindshare.
Быстрый рост в China/Flink ecosystem. Меньше traction в Western market. Потенциал: если Flink adoption растёт, Paimon растёт вместе.
AdoptionКрупные компании, публично использующие формат в production.
Databricks (очевидно), Microsoft (Fabric), Starbucks, Comcast, Conde Nast. Любой клиент Databricks — де-факто Delta Lake user.
Apple (крупнейший deployment), Netflix, Airbnb, LinkedIn, Expedia, Adobe. Snowflake Iceberg Tables — massive adoption driver.
Uber (создатель), AWS (EMR default), ByteDance, Robinhood, Disney+. Сильный в CDC-тяжёлых workload'ах.
Alibaba (создатель — Flink team), ByteDance, Bilibili. Преимущественно Chinese tech companies + Flink users.

Decision Tree: выбор table format

Decision Tree: какой table format выбрать

Какой основной query engine?

Первый вопрос: какой ваш основной query engine? Это самый жёсткий фильтр — engine compatibility определяет, какие форматы вообще рассматривать.
DatabricksDatabricks = Delta Lake. Photon engine оптимизирован под Delta. Auto-optimize, Liquid Clustering, UniForm — premium features. Переход на Iceberg возможен через UniForm, но нет причин, если основной engine = Databricks.

Delta Lake (+ UniForm для multi-engine)

Delta Lake — очевидный выбор. UniForm обеспечивает совместимость с Iceberg readers для multi-engine сценариев.
Flink (streaming)Flink — основной engine для streaming pipeline: CDC, event processing, real-time aggregations.

Multi-engine нужен?

Нужна ли интеграция с другими engines (Spark, Trino) для аналитики? Если Flink-only — Paimon. Если multi-engine — Iceberg или Hudi.
Flink-onlyPaimon: LSM-tree, changelog producer, bucket partitioning — всё оптимизировано для Flink.
Multi-engineIceberg: Flink write + Spark/Trino read. Или Hudi: Flink write + Spark read (CDC-оптимизированный).
Multi-engineSpark + Trino + DuckDB + Flink — несколько engines. Vendor-neutral требование: нет Databricks.

OLAP или CDC?

Доминирующий workload: аналитика (scan-heavy) или CDC (upsert-heavy)?
OLAPIceberg: максимальная engine совместимость, vendor-neutral, сильнейшая community momentum. REST Catalog — единый каталог для всех engines.
CDC-heavyHudi: record-level index, MOR для low-latency upsert. Если CDC — доминирующий workload и Spark — primary engine.

Конвергенция форматов

Форматы конвергируют: каждый новый релиз добавляет фичи, которые были уникальными для конкурентов.

Конвергенция: заимствование фичей
Delta → IcebergUniForm (Delta 3.x): Delta Lake генерирует Iceberg-совместимые metadata. Данные хранятся в Delta формате, но Iceberg readers могут читать через сгенерированные Iceberg snapshots/manifests. Де-факто: Delta становится superset.
Iceberg → Delta/HudiIceberg v2: row-level deletes (ранее — только Hudi MOR). Puffin files: statistics (ранее — Delta file statistics). REST Catalog: открытый стандарт, который Delta и Hudi могут использовать.
Hudi → другиеRecord-level index и MOR — уникальные преимущества Hudi. Другие форматы добавляют аналоги: Delta Liquid Clustering, Iceberg position deletes. Hudi 1.x: упрощение API, table management.
ТрендЧерез 2-3 года: feature parity по основным capabilities. Differentiators сместятся на: ecosystem, tooling, managed services, performance на конкретных engines. Выбор формата станет = выбор экосистемы.
NOTE

Конвергенция означает: если вы выбираете формат сегодня для нового проекта, через 3 года миграция на другой будет проще, чем кажется сейчас. Delta UniForm уже читается Iceberg readers. Iceberg REST Catalog — открытый стандарт. Не ставьте выбор формата как необратимое решение.

Итоги

Краткая рекомендация по table format
IcebergDefault choice для новых проектов в 2025. Максимальная engine совместимость, vendor-neutral, самое быстрое community growth. REST Catalog — открытый стандарт. Если нет специфических требований — Iceberg.
Delta LakeЕсли Databricks — основная платформа. Premium оптимизации (Photon, Liquid Clustering, Auto-optimize). UniForm снимает lock-in. delta-rs — для Python/Rust без Spark.
HudiЕсли CDC — доминирующий workload. Record-level index + MOR = лучшая latency для high-frequency upsert. Сложнее в обслуживании, но мощнее для CDC.
PaimonЕсли Flink — единственный/основной engine. LSM-tree + changelog producer + Flink-native интеграция. Не рекомендуется без Flink.

В следующем уроке — стратегии миграции между форматами: CSV→Parquet, Hive→Iceberg/Delta, Parquet→Lance.

Lakehouse architecture — system design view REST catalogs — критическая часть выбора

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок

Прогресс модуля
0 из 5