Data Lake 三剑客—Delta、Hudi、Iceberg 对比分析

本文来源于云栖社区：https://yq.aliyun.com/article...
做者：xy_xin

共同点

定性上讲，三者均为 Data Lake 的数据存储中间层，其数据管理的功能均是基于一系列的 meta 文件。meta 文件的角色相似于数据库的 catalog/wal，起到 schema 管理、事务管理和数据管理的功能。与数据库不一样的是，这些 meta 文件是与数据文件一块儿存放在存储引擎中的，用户能够直接看到。这种作法直接继承了大数据分析中数据对用户可见的传统，可是无形中也增长了数据被不当心破坏的风险。一旦某个用户不当心删了 meta 目录，表就被破坏了，想要恢复难度很是大。

Meta 文件包含有表的 schema 信息。所以系统能够本身掌握 Schema 的变更，提供 Schema 演化的支持。Meta 文件也有 transaction log 的功能（须要文件系统有原子性和一致性的支持）。全部对表的变动都会生成一份新的 meta 文件，因而系统就有了 ACID 和多版本的支持，同时能够提供访问历史的功能。在这些方面，三者是相同的。

下面来谈一下三者的不一样。

Hudi

先说 Hudi。Hudi 的设计目标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要支持 Upserts、Deletes 和 Incremental 数据处理，其主要提供的写入工具是 Spark HudiDataSource API 和自身提供的 DeltaStreamer，均支持三种数据写入方式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的支持也是经过写入时指定必定的选项支持的，并不支持纯粹的 delete 接口。

其典型用法是将上游数据经过 Kafka 或者 Sqoop，经由 DeltaStreamer 写入 Hudi。DeltaStreamer 是一个常驻服务，不断地从上游拉取数据，并写入 hudi。写入是分批次的，而且能够设置批次之间的调度间隔。默认间隔为 0，相似于 Spark Streaming 的 As-soon-as-possible 策略。随着数据不断写入，会有小文件产生。对于这些小文件，DeltaStreamer 能够自动地触发小文件合并的任务。

在查询方面，Hudi 支持 Hive、Spark、Presto。

在性能方面，Hudi 设计了 HoodieKey，一个相似于主键的东西。HoodieKey有 Min/Max 统计，BloomFilter，用于快速定位 Record 所在的文件。在具体作 Upserts 时，若是 HoodieKey 不存在于 BloomFilter，则执行插入，不然，确认 HoodieKey 是否真正存在，若是真正存在，则执行 update。这种基于 HoodieKey + BloomFilter 的 upserts 方法是比较高效的，不然，须要作全表的 Join 才能实现 upserts。对于查询性能，通常需求是根据查询谓词生成过滤条件下推至 datasource。Hudi 这方面没怎么作工做，其性能彻底基于引擎自带的谓词下推和 partition prune 功能。

Hudi 的另外一大特点是支持 Copy On Write 和 Merge On Read。前者在写入时作数据的 merge，写入性能略差，可是读性能更高一些。后者读的时候作 merge，读性能查，可是写入数据会比较及时，于是后者能够提供近实时的数据分析能力。

最后，Hudi 提供了一个名为 run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了一个命令行工具用于管理 Hudi 表。

hudiimage

Iceberg

Iceberg 没有相似的 HoodieKey 设计，其不强调主键。上文已经说到，没有主键，作 update/delete/merge 等操做就要经过 Join 来实现，而 Join 须要有一个 相似 SQL 的执行引擎。Iceberg 并不绑定某个引擎，也没有本身的引擎，因此 Iceberg 并不支持 update/delete/merge。若是用户须要 update 数据，最好的方法就是找出哪些 partition 须要更新，而后经过 overwrite 的方式重写数据。Iceberg 官网提供的 quickstart 以及 Spark 的接口均只是提到了使用 Spark dataframe API 向 Iceberg 写数据的方式，没有说起别的数据摄入方法。至于使用 Spark Streaming 写入，代码中是实现了相应的 StreamWriteSupport，应该是支持流式写入，可是貌似官网并未明确说起这一点。支持流式写入意味着有小文件问题，对于怎么合并小文件，官网也未说起。我怀疑对于流式写入和小文件合并，可能 Iceberg 尚未很好的生产 ready，于是没有说起（纯属我的猜想）。

在查询方面，Iceberg 支持 Spark、Presto。

Iceberg 在查询性能方面作了大量的工做。值得一提的是它的 hidden partition 功能。Hidden partition 意思是说，对于用户输入的数据，用户能够选取其中某些列作适当的变换（Transform）造成一个新的列做为 partition 列。这个 partition 列仅仅为了将数据进行分区，并不直接体如今表的 schema 中。例如，用户有 timestamp 列，那么能够经过 hour(timestamp) 生成一个 timestamp_hour 的新分区列。timestamp_hour 对用户不可见，仅仅用于组织数据。Partition 列有 partition 列的统计，如该 partition 包含的数据范围。当用户查询时，能够根据 partition 的统计信息作 partition prune。

除了 hidden partition，Iceberg 也对普通的 column 列作了信息收集。这些统计信息很是全，包括列的 size，列的 value count，null value count，以及列的最大最小值等等。这些信息均可以用来在查询时过滤数据。

Iceberg 提供了建表的 API，用户可使用该 API 指定代表、schema、partition 信息等，而后在 Hive catalog 中完成建表。

Delta

咱们最后来讲 Delta。Delta 的定位是流批一体的 Data Lake 存储层，支持 update/delete/merge。因为出自 Databricks，spark 的全部数据写入方式，包括基于 dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是支持的（开源的 SQL 写暂不支持，EMR 作了支持）。与 Iceberg 相似，Delta 不强调主键，所以其 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。这样的话为什么不都在 SparkSQL 里搞定呢？这是一个很是蛋疼的设计。为此，EMR 在这方面作了改进，支持了 DeltaInputFormat，用户能够直接使用 Presto 查询 Delta 数据，而没必要事先启动一个 Spark 任务。

在查询性能方面，开源的 Delta 几乎没有任何优化。Iceberg 的 hidden partition 且不说，普通的 column 的统计信息也没有。Databricks 对他们引觉得傲的 Data Skipping 技术作了保留。不得不说这对于推广 Delta 来讲不是件好事。EMR 团队在这方面正在作一些工做，但愿能弥补这方面能力的缺失。

Delta 在数据 merge 方面性能不如 Hudi，在查询方面性能不如 Iceberg，是否是意味着 Delta 一无可取了呢？其实否则。Delta 的一大优势就是与 Spark 的整合能力（虽然目前仍不是很完善，但 Spark-3.0 以后会好不少），尤为是其流批一体的设计，配合 multi-hop 的 data pipeline，能够支持分析、Machine learning、CDC 等多种场景。使用灵活、场景支持完善是它相比 Hudi 和 Iceberg 的最大优势。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版，无需关心流批，无需关心架构。这一点上 Hudi 和 Iceberg 是力所不及的。

deltaimage

总结

经过上面的分析可以看到，三个引擎的初衷场景并不彻底相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于高性能的分析与可靠的数据管理，Delta 定位于流批一体的数据处理。这种场景的不一样也形成了三者在设计上的差异。尤为是 Hudi，其设计与另外两个相比差异更为明显。随着时间的发展，三者都在不断补齐本身缺失的能力，可能在未来会彼此趋同，互相侵入对方的领地。固然也有可能各自关注本身专长的场景，筑起本身的优点壁垒，所以最终谁赢谁输仍是未知之数。

关注个人公众号，后台回复【JAVAPDF】获取200页面试题！
5万人关注的大数据成神之路，不来了解一下吗？
5万人关注的大数据成神之路，真的不来了解一下吗？
5万人关注的大数据成神之路，肯定真的不来了解一下吗？

欢迎您关注《大数据成神之路》