数据湖三剑客：Hudi vs Delta Lake vs Iceberg

前言

随着 Lakehouse 的日益普及，人们对分析和比较作为该数据架构核心的开源项目的兴趣日益浓厚：Apache Hudi、Delta Lake 和 Apache Iceberg。

目前发表的大多数比较文章似乎仅将这些项目评估为传统的仅附加工作负载的表/文件格式，而忽略了一些对现代数据湖平台至关重要的品质和特性，这些平台需要通过连续的表管理来支持更新繁重的工作负载。

特性比较

首先让我们看一个整体的功能比较。在您阅读时，请注意 Hudi 社区如何在湖存储格式之上投入巨资开发综合平台服务。虽然格式对于标准化和互操作性至关重要，但表/平台服务为您提供了一个强大的工具包，可以轻松开发和管理您的数据湖部署。 

特性亮点

当然构建数据湖平台不仅仅是功能可用性的复选框。让我们选择上面的一些差异化功能，用简单的英语深入研究用例和真正的好处。

增量管道

大多数数据工程师都觉得他们必须在流式处理和老式批处理 ETL 管道之间做出选择。Apache Hudi 开创了一种称为增量管道的新范例。开箱即用，Hudi 跟踪所有更改（追加、更新、删除）并将它们公开为更改流。使用记录级索引，您可以更有效地利用这些更改流来避免重新计算数据并仅以增量方式处理更改。虽然其他数据湖平台可能会提供一种增量消费更改的方式，但 Hudi 的设计初衷是为了有效地实现增量化，从而以更低的延迟实现具有成本效益的 ETL 管道。 

Databricks 最近开发了一个类似的功能，他们称之为Change Data Feed，他们一直持有该功能，直到最终在 Delta Lake 2.0 中开源。Iceberg 有增量读取，但它只允许您读取增量附加，没有更新/删除，这对于真正的变更数据捕获和事务数据至关重要。

并发控制

ACID 事务和并发控制是 Lakehouse 的关键特征，但与现实世界的工作负载相比，当前的设计实际上是如何叠加的？Hudi、Delta 和 Iceberg 都支持乐观并发控制(OCC)。在乐观并发控制中，编写者检查他们是否有重叠的文件，如果存在冲突，他们就会使操作失败并重试。以 Delta Lake 为例，这只是一个 Apache Spark 驱动程序节点上的 JVM 级别锁，这意味着直到最近，您在单个集群之外还没有 OCC 。

虽然这可能适用于仅附加的不可变数据集，但乐观并发控制在现实世界场景中遇到困难，由于数据加载模式或重组数据以提高查询性能，因此需要频繁更新和删除。通常，让编写器离线以进行表管理以确保表的健康和高性能是不切实际的。Apache Hudi 并发控制比其他数据湖平台（文件级别）更精细，并且针对多个小更新/删除进行了优化的设计，在大多数现实世界的情况下，冲突的可能性可以大大降低到可以忽略不计。您可以在此博客中阅读更多详细信息，如何在多写入器场景中使用异步表服务进行操作，而无需暂停写入器。这非常接近标准数据库支持的并发级别。

Merge on Read

任何好的数据库系统都需要权衡写入和查询之间的性能。Hudi 社区在为整个行业的数据湖存储定义这些概念方面做出了一些开创性的贡献。Hudi、Delta 和 Iceberg 都将数据写入和存储在 parquet 文件中。发生更新时，这些 parquet 文件会进行版本控制和重写。这种写模式模式就是业界现在所说的写时复制 (CoW)。此模型非常适合优化查询性能，但可能会限制写入性能和数据新鲜度。除了 COW，Apache Hudi 还支持另一种表存储布局，称为Merge On Read（铁道部）。MOR 使用列式 parquet 文件和基于行的 Avro 日志文件的组合来存储数据。更新可以在日志文件中批量处理，以后可以同步或异步压缩到新的 parquet 文件中，以平衡最大查询性能和降低写入放大。 

因此，对于近乎实时的流式工作负载，Hudi 可以使用更高效的面向行的格式，而对于批处理工作负载，hudi 格式使用可矢量化的面向列的格式，并在需要时无缝合并两种格式。许多用户转向 Apache Hudi，因为它是唯一具有此功能的项目，可让他们实现无与伦比的写入性能和 E2E 数据管道延迟。

分区演进

Apache Iceberg 经常强调的一个特性是隐藏分区，它解锁了所谓的分区演化。基本思想是当您的数据开始演变，或者您只是没有从当前分区方案中获得所需的性能价值时，分区演变允许您更新分区以获取新数据而无需重写数据。当你进化你的分区时，旧数据会留在旧的分区方案中，只有新数据会随着你的进化而分区。如果用户不了解演化历史，则以多种方式分区的表会将复杂性推给用户，并且无法保证一致的性能。

Apache Hudi 采用不同的方法来解决随着数据随着集群的发展而调整数据布局的问题。您可以选择粗粒度的分区策略，甚至不分区，并在每个分区内使用更细粒度的集群策略。集群可以同步或异步运行，并且可以在不重写任何数据的情况下进行演进。这种方法可以与Snowflake的微分区和集群策略相媲美。

多模式索引

索引是数据库和数据仓库不可或缺的组成部分，但在数据湖中基本上不存在。在最近的版本中，Apache Hudi 为 Lakehouse 创建了首创的高性能索引子系统，我们称之为Hudi 多模式索引。Apache Hudi 提供了一种异步索引机制，允许您在不影响写入延迟的情况下构建和更改索引。这种索引机制具有可扩展性和可扩展性，可以支持任何流行的索引技术，例如 Bloom、Hash、Bitmap、R-tree 等。

这些索引存储在Hudi 元数据表中，该表存储在数据旁边的云存储中。在这个新版本中，元数据以优化的索引文件格式编写，与 Delta 或 Iceberg 通用文件格式相比，点查找的性能提高了 10-100 倍。在测试真实世界的工作负载时，这个新的索引子系统可将整体查询性能提高 10-30 倍。

摄取工具 

数据平台与数据格式的不同之处在于可用的运营服务。Apache Hudi 的一个与众不同之处是名为DeltaStreamer的强大摄取实用程序。DeltaStreamer 经过实战测试并在生产中使用，以构建当今地球上一些最大的数据湖。DeltaStreamer 是一个独立的实用程序，它允许您从各种来源（如 DFS、Kafka、数据库更改日志、S3 事件、JDBC 等）增量摄取上游更改。

Iceberg 没有托管摄取实用程序的解决方案，而 Delta Autoloader 仍然是 Databricks 的专有功能，仅支持 S3 等云存储源。

来自社区的案例

功能比较和基准测试可以帮助新手确定可用的技术选择，但更重要的是评估您的个人用例和工作负载，以找到适合您的数据架构的合适方式。所有这三种技术，Hudi、Delta、Iceberg，对于某些用例都有不同的起源故事和优势。Iceberg 诞生于 Netflix，旨在解决文件列表等云存储规模问题。Delta 诞生于 Databricks，它在使用 Databricks Spark 运行时具有深度集成和加速功能。Hudi 诞生于 Uber，旨在为近乎实时的 PB 级数据湖提供支持，并提供无痛的表管理。

经过多年在社区中参与现实世界的比较评估，当您拥有超越简单的仅附加插入的成熟工作负载时，Apache Hudi 通常具有技术优势。一旦您开始处理许多更新、开始添加真正的并发性或尝试减少管道的 E2E 延迟，Apache Hudi 就会在性能和功能集方面成为行业领导者。

以下是来自社区的几个示例和故事，他们独立评估并决定使用 Apache Hudi：

亚马逊Package Delivery System

“ATS 面临的最大挑战之一是处理 PB 级数据，需要以最小的时间延迟进行持续的插入、更新和删除，这反映了真实的业务场景和数据包向下游数据消费者的移动。”

“在这篇文章中，我们展示了我们如何以每小时数百 GB 的速度实时摄取数据，并使用使用 AWS Glue Spark 作业和其他方法加载的Apache Hudi表在 PB 级数据湖上运行插入、更新和删除操作。AWS 无服务器服务，包括 AWS Lambda、Amazon Kinesis Data Firehose 和 Amazon DynamoDB”

字节跳动/抖音  

“在我们的场景中，性能挑战是巨大的。单表最大数据量达到400PB+，日增量为PB级，总数据量达到EB级。”

“吞吐量比较大。单表吞吐量超过100GB/s，单表需要PB级存储。数据模式很复杂。数据是高维和稀疏的。表格列的数量范围从 1,000 到 10,000+。而且有很多复杂的数据类型。”

“在决定引擎时，我们检查了三个最流行的数据湖引擎，Hudi、Iceberg 和 DeltaLake。这三者在我们的场景中各有优缺点。最终选择Hudi作为存储引擎是基于Hudi对上下游生态的开放性、对全局索引的支持，以及针对某些存储逻辑的定制化开发接口。”

Zendesk

“数据湖管道将 Zendesk 高度分布式数据库中的数据整合到数据湖中进行分析。

Zendesk 使用 Amazon Database Migration Service (AWS DMS) 从 8 个 AWS 区域的 1,800 多个 Amazon Aurora MySQL 数据库中捕获变更数据 (CDC)。它使用 Amazon EMR 和Hudi检测事务更改并将其应用到数据湖。

Zendesk 票证数据包含超过 100 亿个事件和 PB 级数据。Amazon S3 中的数据湖文件以Apache Hudi格式进行转换和存储，并在 AWS Glue 目录中注册，可用作数据湖表，用于通过 Amazon Athena 进行分析查询和使用。”

最后，鉴于 Lakehouse 技术的发展速度有多快，重要的是要考虑该领域的开源创新来自何处。以下是一些起源于 Hudi 的基本思想和功能，现在正在被其他项目采用。