Table Services и экосистема

В предыдущих уроках мы разобрали внутреннюю архитектуру Hudi: timeline, COW vs MOR, индексы, concurrency control, запросы. Этот урок завершает модуль двумя темами: Table Services — фоновые операции обслуживания таблицы, и экосистема — интеграции с движками, форматами и инструментами.

Table Services — это то, что делает Hudi self-managing: вместо ручного запуска OPTIMIZE/VACUUM (как в Delta Lake), Hudi может выполнять cleaning, compaction и clustering автоматически, в фоновом режиме, параллельно с ingestion.

Три Table Service

Hudi предлагает три основных сервиса обслуживания таблицы, каждый решает свою проблему:

Compaction (MOR)

Compaction — критический сервис для MOR-таблиц. Без compaction, log files накапливаются и snapshot query замедляется, потому что каждый FileSlice требует merge всё большего количества log файлов.

Стратегии compaction

Inline vs Async compaction

# Inline compaction (внутри writer процесса)
hoodie.compact.inline=true
hoodie.compact.inline.max.delta.commits=5
# Compaction запускается каждые 5 deltacommits
# Простота: один процесс. Минус: замедляет ingestion.

# Async compaction (отдельный процесс)
hoodie.compact.inline=false
# Compaction запускается отдельным Spark/Flink job
# Параллельно с ingestion. Требует multi-writer (OCC/NBCC).

Cleaning

Cleaning удаляет устаревшие FileSlice, которые больше не нужны reader’ам. Это аналог VACUUM в Delta Lake:

Cleaning policies

# Сколько commit'ов сохранять (по умолчанию: 10)
hoodie.cleaner.commits.retained=10

# Policy: KEEP_LATEST_COMMITS — хранить N последних commit'ов
hoodie.cleaner.policy=KEEP_LATEST_COMMITS

# Policy: KEEP_LATEST_FILE_VERSIONS — хранить N версий каждого файла
hoodie.cleaner.policy=KEEP_LATEST_FILE_VERSIONS
hoodie.cleaner.fileversions.retained=3

# Inline cleaning (каждый commit)
hoodie.clean.automatic=true

# Async cleaning (отдельный процесс)
hoodie.clean.automatic=false

Clustering

Clustering реорганизует physical layout данных для оптимизации read performance. Это аналог OPTIMIZE + Z-ORDER в Delta Lake:

Parquet Binary Copy: 10-15x ускорение

В Hudi 1.0 появилась оптимизация Parquet Binary Copy для clustering и compaction:

XTable: Multi-Format Interop

Apache XTable (incubating) — проект, позволяющий конвертировать метаданные между Hudi, Delta Lake и Iceberg без копирования данных:

XTable работает in-place: не копирует данные, а генерирует дополнительные метаданные рядом с существующими. Одни и те же Parquet файлы читаются через Hudi connector, Delta connector или Iceberg connector — в зависимости от метаданных, которые видит движок.

# XTable CLI: sync Hudi → Delta + Iceberg
java -jar xtable-utilities.jar \
 --source-format HUDI \
 --target-formats DELTA,ICEBERG \
 --table-base-path s3://bucket/hudi_table/ \
 --sync-mode INCREMENTAL

Интеграция с движками

Hudi поддерживает Spark, Flink, Presto и Trino как основные движки. Начиная с версии 1.0, все четыре движка — равноправные:

Hudi 1.0 Feature Matrix

Hudi 1.0 (GA декабрь 2024) — крупнейший релиз в истории проекта. Ключевые новые features:

Сравнение с Delta Lake и Iceberg

Ключевое отличие Hudi

Hudi — единственный из трёх форматов, где table services встроены в runtime как первоклассные операции. Delta Lake и Iceberg рассматривают compaction/vacuum как отдельные команды, запускаемые пользователем. Hudi рассматривает их как автоматические сервисы, координируемые с ingestion через timeline.

Практические рекомендации

Итоги

• Table Services — compaction (MOR: merge logs → base), cleaning (удаление старых FileSlice), clustering (реорганизация layout). Hudi — единственный формат с встроенным async scheduling.
• Parquet Binary Copy (1.0): 10-15x ускорение compaction/clustering за счёт бинарного копирования row groups без десериализации.
• XTable (incubating): конвертация метаданных Hudi ↔ Delta ↔ Iceberg без копирования данных. Аналог UniForm, но внешний и двунаправленный.
• Движки: Spark (полная поддержка), Flink (streaming-first), Presto/Trino (read-only), hudi-rs (Python read-only).
• Hudi 1.0: NBCC, secondary indexes, partial updates, LSM timeline, record index, binary copy — крупнейший релиз, выравнивающий Hudi с Delta Lake и Iceberg по feature parity.
• Hudi сильнее всего в инкрементальной обработке (5 типов запросов, checkpoint ETL) и self-managing (async table services). Слабее в Python-экосистеме (read-only hudi-rs vs read+write deltalake/pyiceberg).