1.社区发展现状

（以上数据为2024年2月21日）

可见Apache iceberg和Apache hudi不相伯仲，Apache Paimon成立时间较晚。

Uber的工程师分享了大量Hudi的技术细节和内部方案落地，研究官网的近10个PPT已经能较为轻松理解内部细节，此外国内的小伙伴们也在积极地推进社区建设，提供了官方的技术公众号和邮件列表周报。

Iceberg 相对会平静一些，社区的大部分讨论都在 Github 的 issues 和 pull request 上，邮件列表的讨论会少一点，不少有价值的技术文档要仔细跟踪 issues 和 PR 才能看到，这也许跟社区核心开发者的风格有关。

Paimon 项目的committers可以看出主要由国人发起和主导，具备更好的本地化支持。

2.功能比较

3.ACID和隔离级别支持

对于数据湖来说，三种隔离分别代表。

Serialization：所有的 reader 和 writer 都必须串行执行；
Write Serialization: 多个 writer 必须严格串行，reader 和 writer 之间则可以同时跑；
Snapshot Isolation: 如果多个 writer 写的数据无交集，则可以并发执行；否则只能串行。Reader 和 writer 可以同时跑。
综合起来看，Snapshot Isolation 隔离级别的并发性是相对比较好的。

4.Schema变更支持

Schema Evolution：指schema变更的支持情况，我的理解是hudi仅支持添加可选列和删除列这种向后兼容的DDL操作，而其他方案则没有这个限制。

Paimon支持有限的schema变更。目前，框架无法删除列，因此 DROP 的行为将被忽略，RENAME 将添加新列，列类型只支持从短到长或范围更广的类型。

Self-defined schema objec：指数据湖是否自定义schema接口，以期跟计算引擎的schema解耦。这里iceberg是做的比较好的，抽象了自己的schema，不绑定任何计算引擎层面的schema。

在Hudi 0.11.0版本中，针对Spark 3.1、Spark 3.2版本增加了schema功能的演进。如果启用 set hoodie.schema.on.read.enable=true以后，我们可以对表列和对表进行一系列的操作。列的变更（增加、删除、重命名、修改位置、修改属性），表的变更（重命名、修改属性） 等。

5.其它功能

One line demo：指的是，示例demo是否足够简单，体现了方案的易用性，Iceberg稍微复杂一点（我认为主要是Iceberg自己抽象出了schema，所以操作前需要定义好表的schema）。做得最好的其实是delta，因为它深度跟随spark易用性的脚步。

Python Support：Python支持，很多基于数据湖之上做机器学习的开发者会考虑的问题，Iceberg比较做的好。

 File Encryption：出于数据安全的考虑，Iceberg还提供了文件级别的加密解密功能，这是其他方案未曾考虑到的一个比较重要的点。

Cli Command：命令行

6.商业公司支持

Apache Iceberg

Iceberg 在国内的厂商非常多，腾讯一马当先，是贡献者数量最多的团队，国内的字节 、网易也紧随其后，相比腾讯 Iceberg 和 Hudi 通吃的战略，阿里在 Iceberg 的投入就少了非常多，国外的贡献者也非常多，包括 Netflix、Apple 等等

Apache Hudi

Hudi 在国内的应用很广，包括国内的大厂阿里巴巴、腾讯、字节跳动和华为，国外的话主要是 Uber 和 Amazon。

Apache Paimon

2023 年 3 月 12 日，Flink Table Store 项目顺利通过投票，正式进入 Apache 软件基金会 (ASF) 的孵化器，改名为 Apache Paimon (incubating)。进入孵化器后，Paimon 得到了众多的关注，包括 阿里云、字节跳动、Bilibili、汽车之家、蚂蚁 等多家公司参与到 Apache Paimon 的贡献，也得到了广大用户的使用。

7.性能比较

7.1 Iceberg和Hudi比较

Brooklyn Data在 2022 年 11 月发布 Delta 与 Iceberg 的基准测试结果：Setting the Table: Benchmarking Open Table Formats

Onehouse 添加了 Apache Hudi，并在Brooklyn Github 代码库中发布了代码：https://github.com/brooklyn-data/delta/pull/2

测试结果见上图所示，Delta 和 Hudi 不相上下，Iceberg 落后并且还有一定的差距。

注意：在运行 TPC-DS 基准比较 Hudi、Delta 和 Iceberg 时，需要记住的一个关键点是，默认情况下 Delta + Iceberg 是针对仅追加的工作负载进行优化的，而 Hudi 默认情况下是针对可变工作负载进行优化的。默认情况下，Hudi 使用 "upsert "写模式，与插入相比，这种写模式自然会产生写开销。benchmarks 这个东西还是要以实际的业务场景测试为好，benchmarks 只能作为参考。

7.2 Hudi和Paimin比较

(1) Flink中文社区对Hudi和Paimon进行了性能比较，详细过程见：构建 Streaming Lakehouse：使用 Paimon 和 Hudi 的性能对比

直接说结论：

在 upsert 场景，关闭 compaction 时，Paimon 读写性能均优于 Hudi，且 Hudi 对 TM 的内存要求更高。

在 upsert 场景，开启 compaction 时，Paimon 读写性能均优于 Hudi。对比前面的关闭 compaction 测试，Paimon 和 Hudi 的写性能均有所下降，但读性能得到提升。

在 append 场景，Paimon 读写性能优于 Hudi，且二者都对 TM 内存要求均不高。

(2) 同程也对Hudi和Paimon进行了性能测试，详细内容见：Apache Paimon 在同程旅行的实践进展

同程在实践过程中，发现在全量+增量写入的场景中，相对 Hudi，Paimon 在相同计算资源的情况下，摄入的速度要优于 Hudi MOR 的摄入，大概有 3 倍左右的差距。查询场景下会更明显，在同样数据量的情况下，Paimon 的查询速度要优于 Hudi，大概有 7 倍左右的差距。

(3) 同时，一些开发人员对Flink 官方测试结果产生疑问，自己对也Hudi和Paimon进行了性能测试，具体过程见：Paimon VS Hudi 写入效率大PK

发现Paimon 的写入效率跟写入效果(文件数量)，写入速度是 Hudi 的2倍多，而文件数量只有 Hudi数量的一半不到。对比Flink官方测试出来的，比 Hudi COW 表写入效率快12倍的结论，没有完全没有体现出来（测试的数据量不同）

实验测试结论为：Hudi 的MOR 表无论是写入速度，还是生成的文件数量，都要比 Paimon 优秀。而Hudi 的 COW 表，则正好相反，其无论写入速度，还是文件生成数量，则要比 Paimon 差，但这个差距，貌似在随着 checkpoint 时间的增大，逐渐在缩小。

8.总结

Apache Iceberg

Iceberg 社区基本盘还是在离线处理，它在国外的应用场景主要是离线取代 Hive，它也有强力的竞争对手 Delta，很难调整架构去适配 CDC 流更新。同时，Iceberg 扩展性强，对其它计算引擎也暴露的比较多的优化空间，但是这也导致后续的发展难以迅速，涉及到众多已经对接好的引擎。这并没有什么错，后面也证明了 Iceberg 主打离线数据湖和扩展性是有很大的优势，得到了众多国外厂商的支持。

Apache Hudi

Hudi 默认使用 Flink State 来保存 Key 到 FileGroup 的 Index，好处是全自动，想 Scale Up 只用调整并发就行了，坏处是性能差，直接让湖存储变成了实时点查，超过5亿条数据性能更是急剧下降。同时，存储成本也高，RocksDB State 保存所有索引。数据非常容易不一致，甚至再也不能有别的引擎来读写，因为一旦读写就破坏了 State 里面的 Index。

针对 Flink State Index 诸多问题，字节跳动的工程师们在 Hudi 社区提出了 Bucket Index 的方案，该解决方案好处是去除了 Index 带来了诸多性能问题。坏处是需要手动选取非常合适的 Bucket Number，多了小文件操作很多，少了性能不行。这套方案也是目前 Hudi 体量较大的用户的主流方案。

Hudi 当前存在的问题：

• Hudi 众多的模式让用户难以选择。
• 使用 Flink State 还是 Bucket Index？一个易用性好但是性能不行，一个难以使用。
• 使用 CopyOnWrite 还是 Merge On Read？一个写入吞吐很差，一个查询性能很差。
• 更新效率低，1-3 分钟 Checkpoint 容易反压，默认 5 次 Checkpoint 合并，一般业务可接受的查询是查询合并后的数据；全增量一体割裂，难以统一。
• 系统设计复杂，Bugs 难以收敛，工单层出不穷；各引擎之间的兼容性也非常差；参数众多。

Hudi 天然面向 Spark 批处理模式设计而诞生，不断在面向批处理的架构上进行细节改造，无法彻底适配流处理更新场景，在批处理架构上不断强行完善流处理更新能力，导致架构越来越复杂，可维护性越来越差。

Apache Paimon

Apache Paimon 最典型的场景是解决了 CDC (Change Data Capture) 数据的入湖。但是因为发展较晚，当前国内并没有主流的商业平台落地，对于批处理的性能也有待考量，仍需要一定的时间去完善和发展。以下为当前各版本支持情况：

最后，对于官方的性能测试结果，仅参考即可。实际业务场景中需要结果自身业务去测试验证，综合考虑场景、数据量、各组件版本等多个因素，根据业务需求选择适合自己的解决方案。

任何关于性能测试的结论，都必须建立在具体的场景之下才有意义！