开源数据湖方案选型：Hudi、Delta、Iceberg深度对比

文章目录

• 前言： 共同点
• 一、Databricks 和 Delta
• • 1.1、Delta的意图,解决的疼点
  • 1、没有 Delta 数据湖之前存在的问题 :
• 二、Uber和Apache Hudi
• 三、Netflix和Apache Iceberg
• 四、痛点小结
• • 4.1、七大维度对比
  • • 4.1.1、ACID和隔离级别支持
    • 4.1.2、Schema 变动支持和设计
    • 4.1.3、流批接口支持
    • 4.1.4、接口抽象程度和插件化
    • 4.1.5、查询性能优化
    • 4.1.6、其余功能
    • 4.1.7、 区现状
• 五、总结

这篇文章主要向大家介绍开源数据湖方案选型：Hudi、Delta、Iceberg深度对比,主要内容包括基础应用、实用技巧、原理机制等方面，希望对大家有所帮助。

目前市面上流行的三大开源数据湖方案分别为： delta、Apache Iceberg和Apache Hudi。

其中，因为 Apache Spark 在商业化上取得巨大成功，因此由其背后商业公司 Databricks 推出的 delta 也显得格外亮眼。

是由 的工程师为其内部数据分析的需求而设计的数据湖项目，它提供的 以及等功能能够说是精准命中广大人民群众的痛点，加上项目各成员积极地 区建设，包括技术细节分享、国内 区推广等等，也在逐步地吸引潜在用户的目光。

Apache Iceberg 目前看则会显得相对平庸一些，简单说 区关注度暂时比不上 delta，功能也不如 Hudi 丰富，但倒是一个野心勃勃的项目，由于它具备高度抽象和很是优雅的设计，为成为一个通用的数据湖方案奠基了良好基础。

前言： 共同点

??定性上讲，三者均为 的数据存储中间层，其数据管理的功能均是基于一系列的 meta 文件。 文件的角色类似于数据库的 ，起到 管理、事务管理和数据管理的功能。与数据库不同的是，这些 meta 文件是与数据文件一起存放在存储引擎中的，用户可以直接看到。这种做法直接继承了大数据分析中数据对用户可见的传统，但是无形中也增加了数据被不小心破坏的风险。一旦某个用户不小心删了 meta 目录，表就被破坏了，想要恢复难度非常大。

?? 文件包含有表的 信息。因此系统可以自己掌握 的变动，提供 演化的支持。Meta 文件也有 的功能（需要文件系统有原子性和一致性的支持）。所有对表的变更都会生成一份新的 文件，于是系统就有了 和多版本的支持，同时可以提供访问历史的功能。在这些方面，三者是相同的。

??不少用户会想，看着三大项目奇光异彩，到底应该在什么样的场景下，选择合适数据湖方案呢天咱们就来解构数据湖的核心需求，深度对比三大产品，帮助用户更好地针对自身场景来作数据湖方案选型。

??首先，咱们来逐一分析为什么各技术公司要推出他们的开源数据湖解决方案，他们碰到的问题是什么，提出的方案又是如何解决问题的。咱们但愿客观地分析业务场景，来理性判断到底哪些功能才是客户的痛点和刚需。

一、Databricks 和 Delta

1.1、Delta的意图,解决的疼点

??以 Databricks 推出的 delta 为例，它要解决的核心问题基本上集中在下图 ：

??事实上, Databricks 在设计 delta 时，但愿作到流批做业在数据层面作到进一步的统一(以下图)。业务数据通过Kafka导入到统一的数据湖中（不管批处理，仍是流处理），上层业务能够借助各类分析引擎作进一步的商业 表分析、流式计算以及AI分析等等。

二、Uber和Apache Hudi

如上图所示，ETL 任务每隔30分钟按期地把增量更新数据同步到分析表中，所有改写已存在的全量旧数据文件，致使数据延迟和资源消耗都很高。

此外，在数据湖的下游，还存在流式做业会增量地消费新写入的数据，数据湖的流式消费对他们来讲也是必备的功能。因此，他们就但愿设计一种合适的数据湖方案，在解决通用数据湖需求的前提下，还能实现快速的 upsert 以及流式增量消费。

三、Netflix和Apache Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷以后，开始转为自研Iceberg，并最终演化成Apache下一个高度抽象通用的开源数据湖方案。

Netflix用内部的一个时序数据业务的案例来讲明Hive的这些问题，采用Hive时按照时间字段作partition，他们发现仅一个月会产生2688个partition和270万个数据文件。他们执行一个简单的select查询，发现仅在分区裁剪阶段就耗费数十分钟。

四、痛点小结

咱们能够把上述三个项目针对的痛点，放到一张图上来看。能够发现标红的功能点，基本上是一个好的数据湖方案应该去作到的功能点：

这里主要解释下，对数据湖来讲三种隔离分别表明的含义：

• Serialization 是说全部的reader和writer都必须串行执行；

• Write Serialization: 是说多个writer必须严格串行，reader和writer之间则能够同时跑；

• Snapshot Isolation: 是说若是多个writer写的数据无交集，则能够并发执行；不然只能串行。Reader和writer能够同时跑。

综合起来看，Snapshot Isolation 隔离级别的并发性是相对比较好的。

4.1.2、Schema 变动支持和设计

目前 Iceberg 和 Hive 暂时不支持流式消费，不过 Iceberg 区正在issue 179上开发支持。

4.1.4、接口抽象程度和插件化

4.1.6、其余功能

这里须要说明的是，Delta和Hudi两个项目在开源 区的建设和推进方面，做的比较好。Delta 的开源版和商业版本，提供了详细的内部设计文档，用户很是容易理解这个方案的内部设计和核心功能，同时Databricks还提供了大量对外分享的技术视频和演讲，甚至邀请了他们的企业用户来分享Delta的线上经验。

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

五、总结

咱们把三个产品（其中 delta 分为 databricks 的开源版和商业版）总结成以下图：

Delta的房子底座相对结实，功能楼层也建得相对比较高，但这个房子其实能够说是databricks的，本质上是为了更好地壮大Spark生态，在delta上其余的计算引擎难以替换Spark的位置，尤为是写入路径层面。

Iceberg的建筑基础很是扎实，扩展到新的计算引擎或者文件系统都很是的方便，可是如今功能楼层相对低一点，目前最缺的功能就是 upsert 和 compaction 两个，Iceberg 区正在以最高优先级推进这两个功能的实现。

Hudi 的状况要相对不同，它的建筑基础设计不如 iceberg 结实，举个例子，若是要接入 Flink 做为 Sink 的话，须要把整个房子从底向上翻一遍，把接口抽象出来，同时还要考虑不影响其余功能，固然 Hudi 的功能楼层仍是比较完善的，提供的 upsert 和compaction 功能直接命中广大群众的痛点。

Hive的房子，看起来是一栋豪宅，绝大部分功能都有，把它作为数据湖有点像靠着豪宅的一堵墙建房子，显得相对重量级一点，另外正如 Netflix 上述的分析，细看这个豪宅的墙面是实际上是有一些问题的。

参考：
https://www.shangmayuan.com/a/a1b9f3ce84db45a6ab0e35d1.html
https://blog.csdn.net/u011598442/article/details/104403990
https://www.cnblogs.com/huaweiyun/p/13896955.html

http://hudi.apache.org/
http://iceberg.apache.org/#