Apache Paimon Hudi Iceberg 数据湖格式选型对比

选型的核心不在"哪个最好"，而在你的写入模式、查询引擎和实时性需求三者交汇处。Apache Paimon、Hudi、Iceberg 三种主流数据湖表格式各有明确的设计取舍，理解这些取舍才能做出不后悔的决定。

从底层存储结构说起

三种格式的分水岭在于数据更新的处理方式。

Paimon 采用类 LSM-Tree（Log-Structured Merge Tree）结构。数据先写入内存缓冲区，达到阈值后刷写为磁盘上的有序文件（Sorted Run），再由后台 Compaction 任务将多个 Sorted Run 合并。这种设计天然适合高频写入和更新场景——写入延迟低，不需要在写入时重写已有文件。Paimon 原生深度集成 Flink，CDC 数据可以直接流入 Paimon 表，无需额外的日志中间层。

Hudi 提供两种表类型：Copy-on-Write（CoW）和 Merge-on-Read（MoR）。CoW 表在写入更新时直接重写 Parquet 文件，查询时直接读取基文件，读性能优秀但写入代价高。MoR 表将增量数据追加到日志文件中，查询时需要合并基文件与日志文件，写入快但读取时有额外合并开销。Hudi 早期由 Uber 开发，后来贡献给 Apache 基金会，在 Flink 和 Spark 上都有良好支持。

Iceberg 采用快照（Snapshot）和清单（Manifest）两层元数据结构。每次提交生成新的快照，快照通过清单文件引用实际数据文件。这种设计使得 Schema 演进、分区演化和时间旅行查询都非常高效。Iceberg 最初由 Netflix 开发，目前拥有最广泛的引擎兼容性。

多引擎兼容性：选格式时最容易被低估的维度

如果你的团队只用 Flink，Paimon 是最自然的选择——写入路径和查询路径都是为 Flink 优化的。但如果同一张表需要同时被 Spark 批处理作业、Trino 即席查询和 Flink 流处理作业访问，情况就不同了。

Iceberg 在多引擎支持上做得最好。截至 2025 年，Spark、Flink、Trino、Dremio、StarRocks、DuckDB 等主流引擎都对 Iceberg 提供了读写支持。这意味着你可以用 Iceberg 作为统一存储层，让不同引擎各取所需。

Hudi 的引擎支持同样不错，Spark 和 Flink 都有成熟的读写集成。但在 Trino 和 DuckDB 等新兴 OLAP 引擎上，Iceberg 的生态适配速度更快。

Paimon 的 Spark 支持正在快速推进，但截至 2025 年，在 Spark 上的写入功能相比 Flink 仍有差距。如果你的核心场景是 Flink 流式写入加 Spark 离线查询，Paimon 的双向兼容需要仔细测试。

写入模式决定格式选择

高频 Upsert 场景（如订单状态更新、用户信息变更）：Paimon 的 LSM-Tree 结构在写入性能上有天然优势。写入时不需要重写已有文件，Compaction 可以异步执行，写入吞吐量高。如果你的 Flink CDC 链路需要将 MySQL 的实时变更同步到湖仓，Paimon 的 changelog-producer 机制可以直接生成 Changelog 供下游消费，省去了额外的去重逻辑。

批量覆盖写场景（如每天全量刷新维度表）：三种格式都能胜任，但 Hudi 的 CoW 表在这种场景下表现最简洁——每次覆盖写入自动完成文件合并，查询性能稳定。

以追加为主的日志分析场景：Iceberg 的隐式分区（Hidden Partitioning）特别适合——按时间分区时不需要在建表时显式指定分区列，引擎会根据查询模式自动裁剪分区，减少手动分区管理的负担。

Compaction 策略差异直接影响运维负担

Paimon 的 Compaction 是查询性能和写入性能平衡的关键。Sorted Run 数量过多会导致查询时需要合并更多文件，性能下降。Paimon 提供 Universal 和 Leveled 两种 Compaction 策略：Universal 策略合并频率低但查询时需要合并的文件多，Leveled 策略文件层级清晰但写放大较高。实际生产中，建议对写入量大的表启用异步 Compaction，避免 Compaction 阻塞写入任务。同一分区同一时刻只能有一个 Compaction 任务运行，否则会产生冲突。

Hudi 的 Compaction 主要针对 MoR 表——需要定期将日志文件合并到基文件中。CoW 表在写入时就完成了文件重写，不需要额外的 Compaction 过程。这意味着 CoW 表的运维更简单，但写入代价更高。

Iceberg 的 Compaction（也叫 rewrite data files）主要是合并小文件和优化文件布局。由于 Iceberg 的元数据层设计，Compaction 过程相对轻量。

Schema 演进与时间旅行

三种格式都支持 Schema 演进和时间旅行，但实现方式不同。

Paimon 的 Schema 演进支持字段添加、重命名和类型修改，通过快照机制实现时间旅行。每次提交的快照都可以作为历史版本被查询。

Hudi 的 Schema 演进在 CoW 和 MoR 表上都可用，时间旅行通过 commit 时间戳实现。Hudi 的增量查询（Incremental Query）是其独特优势——可以高效地查询两个时间点之间的数据变化。

Iceberg 的 Schema 演进最为成熟，支持列级的 Schema 变更而不需要重写数据文件。隐式分区（Partition Evolution）允许在不修改已有数据的情况下调整分区策略。时间旅行通过快照 ID 或时间戳查询，元数据层的优化使得历史快照查询非常高效。

选型决策路径

第一步：确认核心写入模式。如果你的场景以 Flink 流式写入和 CDC 入湖为主，优先评估 Paimon。如果需要在 Spark 生态中有最佳兼容性，优先看 Iceberg。如果以批量 Upsert 为主且已有 Hudi 技术积累，继续用 Hudi。

第二步：确认查询引擎组合。单一 Flink 引擎选 Paimon；多引擎混合读写选 Iceberg；Spark + Flink 为主选 Hudi 或 Iceberg。

第三步：评估运维复杂度。团队规模有限时，Compaction 策略越简单越好。CoW 模式的 Hudi 和 Iceberg 在运维上相对省心。Paimon 的 Compaction 需要更多调优经验。

第四步：考虑社区和生态趋势。截至 2025 年，Iceberg 的社区活跃度和企业采用率最高，是"默认不会出错"的选择。Paimon 增长最快，尤其在实时湖仓场景。Hudi 在特定场景（如 CDC 增量查询和 AWS 生态集成）仍然有独特优势。

没有银弹，但有最适合你场景的那个选择。关键是基于自身的技术栈、实时性要求和团队经验做出判断，而不是追逐社区热度。