数据湖Iceberg、Hudi和Paimon比较

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

土豆马铃薯

5129人浏览 · 2024-02-22 14:26:20

土豆马铃薯 · 2024-02-22 14:26:20 发布

1.社区发展现状

项目	Apache Iceberg	Apache Hudi	Apache Paimon
开源时间	2018/11/6	2019/1/17	2023/3/12
License	Apache-2.0	Apache-2.0	Apache-2.0
Github Watch	148	1.2k	70
Github Star	5.3k	4.9k	1.7k
Github Fork	1.9k	2.3k	702
Github issue(Open)	898	481	263
Github issue(closed)	2054	2410	488
Github Open PR(Open)	565	449	82
Github Open PR(Closed)	6240	7378	2049
Committers	454	436	131
Releases	17	16	3
Release Latest	Apache Iceberg 1.4.3	0.14.1 Release	Release 0.6

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

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

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

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

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

2.功能比较

对比项	Apache Iceberg	Apache Hudi	Apache Paimon
update/delete	YES	YES	YES
文件合并	Manually	Automatic	Automatic
历史数据清理	Manually	Automatic	Automatic
文件格式	parquet,avro,orc	parquet,avro	parquet,avro,orc
计算引擎	Hive/Spark/Presto/Flink/Impala /Trino等	Hive/Spark/Presto/Flink/Impala /Trino等	Hive/Spark/Presto/Flink /Trino
存储引擎	HDFS/S3	HDFS/S3/OBS/ALLUXIO/Azure	HDFS/S3/OSS
SQL DML	YES	YES	YES
ACID transaction	YES	YES	YES
索引	NO	YES	YES
可扩展的元数据存储	YES	YES	YES

3.ACID和隔离级别支持

对比项	Apache Iceberg	Apache Hudi	Apache Paimon
ACID Support	YES	YES	YES
Isolation Level	Write Serialization	Snapshot Isolation	Snapshot Isolation
Concurrent Multi-Writers	YES	YES	YES
Time travel	YES	YES	YES

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

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

4.Schema变更支持

对比项	Apache Iceberg	Apache Hudi	Apache Paimon
Schema Evolution	ALL	back-compatible	back-compatible
Self-defined schema object	YES	NO(spark-schema)	NO（我理解，不准确）

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.其它功能

对比项	Apache Iceberg	Apache Hudi	Apache Paimon
One line demo	Not Good	Medium	Good
Python Support	YES	NO	NO（不确定）
File Encryption	YES	NO	NO
Cli Command	NO	YES	YES

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

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) 数据的入湖。但是因为发展较晚，当前国内并没有主流的商业平台落地，对于批处理的性能也有待考量，仍需要一定的时间去完善和发展。以下为当前各版本支持情况：