常见的三⼤数据湖技术Delta、Hudi、Iceberg对⽐
⼀、Delta、Hudi、Iceberg对⽐概览
由于Apache Spark在商业化上取得巨⼤成功，所以由其背后商业公司Databricks推出的Delta lake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户⼀般会采⽤经典的lambda架构来构建他们的流批处理场景。
Apache Hudi是由Uber的⼯程师为满⾜其内部数据分析的需求⽽设计的数据湖项⽬，它提供的fast upsert/delete以及compaction等功能可以说是精准命中⼴⼤⼈民众的痛点，加上项⽬各成员积极地社区建设，包括技术细节分享、国内社区推⼴等等，也在逐步地吸引潜在⽤户的⽬光。
Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为⾃研Iceberg，并最终演化成Apache下⼀个⾼度抽象通⽤的开源数据湖⽅案。
meta大裁员Apache Iceberg⽬前看则会显得相对平庸⼀些，简单说社区关注度暂时⽐不上delta，功能也不如Hudi丰富，但却是⼀个野⼼勃勃的项⽬，因为它具有⾼度抽象和⾮常优雅的设计，为成为⼀个通⽤的数据湖⽅案奠定了良好基础。
⼆、共同点
三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于⼀系列的meta⽂件。Meta⽂件的⾓⾊类似于数据库的catalog\wal，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta⽂件是与数据⽂件⼀起存放在存储引擎中的，⽤户可以直接看到。这个做法直接继承了⼤数据分析中数据对⽤户可见的传统，但是⽆形中也增加了数据被不⼩⼼破坏的风险。⼀旦删了meta⽬录，表就被破坏了，恢复难度很⼤。
Meta包含有表的schema信息。因此系统可以⾃⼰掌握schema的变动，提供schema演化的⽀持。Meta⽂件也有transaction log的功能（需要⽂件系统有原⼦性和⼀致性的⽀持）。所有对表的变更都会⽣成⼀份新的meta⽂件，于是系统就有了ACID和多版本的⽀持，同时可以提供访问历史的功能。在这些⽅⾯，三者是相同的。
三、关于Hudi
Hudi 的设计⽬标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要⽀持Upserts、Deletes 和 Incremental 数据处理，其主要提供的写⼊⼯具是 Spark HudiDataSource API 和⾃⾝提供的 HoodieDeltaStreamer，均⽀持三种数据写⼊⽅式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的⽀持也是通过写⼊时指定⼀定的选项⽀持的，并不⽀持纯粹的 delete 接⼝。
在查询⽅⾯，Hudi ⽀持 Hive、Spark、Presto。
在性能⽅⾯，Hudi 设计了  HoodieKey ，⼀个类似于主键的东西。对于查询性能，⼀般需求是根据查询谓词⽣成过滤条件下推⾄datasource。Hudi 这⽅⾯没怎么做⼯作，其性能完全基于引擎⾃带的谓词下推和 partition prune 功能。
Hudi 的另⼀⼤特⾊是⽀持 Copy On Write 和 Merge On Read。前者在写⼊时做数据的 merge，写⼊性能略差，但是读性能更⾼⼀些。后者读的时候做 merge，读性能差，但是写⼊数据会⽐较及时，因⽽后者可以提供近实时的数据分析能⼒。最后，Hudi 提供了⼀个名为
run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了⼀个命令⾏⼯具⽤于管理 Hudi 表。
四、关于Iceberg
Iceberg 没有类似的  HoodieKey  设计，其不强调主键。上⽂已经说到，没有主键，做 update/delete/merge 等操作就要通过 Join 来实现，⽽ Join 需要有⼀个类似 SQL 的执⾏引擎。
在查询⽅⾯，Iceberg ⽀持hive、 Spark、Presto。
Iceberg 在查询性能⽅⾯做了⼤量的⼯作。值得⼀提的是它的 hidden partition 功能。Hidden partition 意思是说，对于⽤户输⼊的数据，⽤户可以选取其中某些列做适当的变换（Transform）形成⼀个新的列作为 partition 列。这个 partition 列仅仅为了将数据进⾏分区，并不直接体现在表的 schema 中。
除了 hidden partition，Iceberg 也对普通的 column 列做了信息收集。这些统计信息⾮常全，包括列的 size，列的 value count，null value count，以及列的最⼤最⼩值等等。这些信息都可以⽤来在查询时
过滤数据。
Iceberg 提供了建表的 API，⽤户可以使⽤该 API 指定表名、schema、partition 信息等，然后在 Hive catalog 中完成建表。
五、关于Delta
Delta 的定位是流批⼀体的 Data Lake 存储层，⽀持 update/delete/merge。由于出⾃ Databricks，spark 的所有数据写⼊⽅式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是⽀持的（开源的 SQL 写暂不⽀持，EMR 做了⽀持）。不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写⼊⽅⾯，Delta 与 Spark 是强绑定的，这⼀点 Hudi 是不同的：Hudi 的数据写⼊不绑定 Spark（可以⽤ Spark，也可以使⽤ Hudi ⾃⼰的写⼊⼯具写⼊）。
在查询⽅⾯，开源 Delta ⽬前⽀持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要⽤到 Spark。这意味着如果要⽤ Presto 查询 Delta，查询时还要跑⼀个 Spark 作业。更为蛋疼的是，Presto 查询是基于  SymlinkTextInputFormat 。在查询之前，要运⾏ Spark 作业⽣成这么个 Symlink ⽂件。如果表数据是实时更新的，意味着每次在查询之前先要跑⼀个 SparkSQL，再跑 Presto。为此，EMR 在这⽅⾯做了改进可以不必事先启动⼀个 Spark 任务。
在查询性能⽅⾯，开源的 Delta ⼏乎没有任何优化。
Delta 在数据 merge ⽅⾯性能不如 Hudi，在查询⽅⾯性能不如 Iceberg，是不是意味着 Delta ⼀⽆是处了呢？其实不然。Delta 的⼀⼤优点就是与 Spark 的整合能⼒，尤其是其流批⼀体的设计，配合 multi-hop 的 data pipeline，可以⽀持分析、Machine learning、CDC 等多种场景。使⽤灵活、场景⽀持完善是它相⽐ Hudi 和 Iceberg 的最⼤优点。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版，⽆需关⼼流批，⽆需关⼼架构。这⼀点上 Hudi 和 Iceberg 是⼒所不及的。
六、总结
三个引擎的初衷场景并不完全相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于⾼性能的分析与可靠的数据管理，
Delta 定位于流批⼀体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是 Hudi，其设计与另外两个相⽐差别
更为明显。因此后⾯是趋同还筑起各⾃专长优势壁垒未可知。
Delta、Hudi、Iceberg三个开源项⽬中，Delta和Hudi跟Spark的代码深度绑定，尤其是写⼊路径。这两个项⽬设计之初，
都基本上把Spark作为他们的默认计算引擎了。⽽Apache Iceberg的⽅向⾮常坚定，宗旨就是要做⼀个通⽤化设计的Table Format。
它完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和⽂件格式，很好的完成了数据湖架构中的Table Format
这⼀层的实现，因此也更容易成为Table Format层的开源事实标准。
另⼀⽅⾯，Apache Iceberg也在朝着流批⼀体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction
的变更，⾮常⽅便批处理和增量计算。并且，Apache Flink已经是⼀个流批⼀体的计算引擎，⼆都可以完美匹配，合⼒打造
流批⼀体的数据湖架构。
最后，Apache Iceberg这个项⽬背后的社区资源⾮常丰富。在国外，Netflix、Apple、Linkedin、Adobe等公司都有PB级别的
⽣产数据运⾏在Apache Iceberg上；在国内，腾讯这样的巨头也有⾮常庞⼤的数据跑在Apache Iceberg之上，最⼤的业务每天有
⼏⼗T的增量数据写⼊。社区成员同样⾮常资源和多样化，拥有来⾃其他项⽬的7位ApachePMC ， 1为VP。体现在代码和设计
的review上，就变得⾮常苛刻，⼀个稍微⼤⼀点的PR涉及100+的comment很常见。这些都使得Apache Iceberg的设计+代码质量⽐较⾼。      Apache Iceberg 0.10.0 版本的发布，已经拉开集成 Flink 和 Iceberg 的序幕。
基于以上，个⼈⽐较推荐选择Apache Iceberg，并且建议和Apark Flink搭配。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。