| 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.总结
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新