Hudi 与 Iceberg 小文件合并策略对比与调优

数据湖表频繁写入会导致小文件膨胀，严重影响查询性能。Hudi 和 Iceberg 提供了不同的文件管理机制，选择合适的合并策略是湖仓治理的关键。

Hudi 的 Compaction 机制

Hudi 采用 Copy-on-Write（COW）和 Merge-on-Read（MOR）两种表类型，文件管理策略完全不同。

COW 表：每次写入都生成新的数据文件，通过 compaction 将小文件合并为大文件。Compaction 过程会重写整个文件，适合写入频率低、查询性能要求高的场景。

MOR 表：写入时只生成增量日志文件（log file），查询时实时合并基础文件和日志文件。通过 compaction 将日志文件合并到基础文件中，适合写入频率高、需要实时可见的场景。

Compaction 调优参数：

• hoodie.compact.inline.max.delta.commits：触发自动 compaction 的最大增量提交数（默认 5）
• hoodie.compaction.target.io：compaction 的目标 IO（字节/秒），控制 compaction 速度
• hoodie.parquet.max.file.size：目标文件大小（默认 120MB），根据查询模式调整

最佳实践：COW 表在写入量大时 compaction 开销高，建议设置合理的文件大小阈值。MOR 表的 compaction 可以异步执行，不影响写入性能，但需要定期触发以避免查询时合并开销过大。

Iceberg 的 Rewrite Files 机制

Iceberg 不区分 COW 和 MOR，通过快照机制管理文件变更。小文件合并通过 rewrite_files 操作实现，可以将多个小文件重写为大文件，同时保持快照的原子性。

Rewrite Files 的特点：

• 原子性：重写操作是原子的，要么全部成功要么全部回滚
• 并发安全：多个 rewrite 操作不会产生冲突
• 快照隔离：查询始终看到一致的快照，不受 rewrite 影响

调优参数：

• write.target-file-size-bytes：目标文件大小（默认 512MB）
• write.parquet.page-size-bytes：Parquet 页面大小
• 分区策略：按时间分区的表需要考虑跨分区合并的开销

最佳实践：Iceberg 的 rewrite 操作可以通过 Spark 作业触发，建议在低峰期执行。对于高频写入场景，设置合理的目标文件大小可以减少 rewrite 的频率。

两种机制的核心差异

文件管理方式：Hudi 通过 compaction 在写入过程中管理文件，Iceberg 通过独立的 rewrite 操作管理文件。

写入性能影响：Hudi 的 COW 表 compaction 会阻塞写入，MOR 表异步 compaction 影响较小。Iceberg 的 rewrite 完全独立于写入，不影响写入性能。

查询性能：Hudi COW 表查询性能最好（文件已合并），MOR 表查询时需要合并日志文件。Iceberg 查询始终读取已合并的文件，性能稳定。

运维复杂度：Hudi 需要关注 compaction 任务的调度和资源占用。Iceberg 的 rewrite 可以通过 Spark 作业灵活调度。

按写入模式选择策略

低频批量写入（每天几次）：COW 表或 Iceberg 均可。COW 表查询性能最优，Iceberg 的 rewrite 开销最低。

高频实时写入（每秒数百次）：Hudi MOR 表或 Iceberg。避免 COW 表的频繁 compaction 开销。

混合读写（读多写少）：Hudi COW 表。查询性能和写入效率的平衡点。

CDC 同步场景：Hudi MOR 表支持 Upsert 语义，Iceberg 通过 row-level delete 支持更新。两者都可以，但 Hudi 的 CDC 集成更成熟。

大规模历史数据回填：Iceberg 的 rewrite 可以并行处理多个分区，适合大规模数据重写。Hudi 的 compaction 需要更多资源管理。

无论选择哪种湖格式，定期监控文件数量和大小、设置合理的 compaction/rewrite 策略、在低峰期执行合并操作，是保证湖仓查询性能的三个关键原则。