category
简介
随着数据湖的日益普及，人们对分析和比较作为此数据架构核心的三个开源项目的兴趣也与日俱增：Apache Hudi、Delta Lake 和 Apache Iceberg。
目前发布的大多数比较文章似乎仅将这些项目评估为传统追加工作负载的表/文件格式，而忽略了一些对于需要通过持续表管理支持更新密集型工作负载的现代数据湖平台至关重要的特性和功能。（有关文件/表格式和完整数据湖实现之间的更多区别，请参阅我们的相关博客文章《开放表格式和开放数据湖》，观点）。本文将更深入地探讨功能比较，并全面介绍基准和社区统计数据。
如果在分析比较时，您发现很难选择要使用的格式，请查看我们的新项目：Apache XTable（孵化中）。XTable 提供 Hudi、Delta 和 Iceberg 之间的无缝互操作性。您不再需要在格式之间进行选择，也不必局限于一种格式。XTable（最初称为 Onetable）由微软、谷歌和 Onehouse 联合推出开源版本，VentureBeat 对此进行了报道。XTable 已捐赠给 Apache 软件基金会。
功能比较
首先，让我们看一下整体功能比较。阅读时，请注意 Hudi 社区如何在湖存储格式的基础上投入大量资金来提供全面的平台服务。虽然格式对于标准化和互操作性至关重要，但表/平台服务为您提供了强大的工具包，可轻松开发和管理数据湖部署。
|
As of v0.12.2 |
As of v2.2.0 |
As of v1.1.0 |
|
Read/write features |
||
|
ACID Transactions |
|
|
|
Copy-On-Write
(Can I version and rewrite columnar files?) |
|
|
|
Merge-On-Read
(Can I efficiently amortize updates without rewriting the whole file?)
|
|
|
|
Efficient Bulk Load
|
|
|
|
Efficient merge writes with record-level indices
|
Over 4 types of Indexing |
|
|
Bootstrap |
|
|
|
Incremental Query |
|
|
|
Time travel
|
|
|
|
Managed Ingestion
|
|
|
|
Concurrency
|
|
|
|
Primary Keys
|
|
|
|
Column Statistics and Data Skipping
|
|
|
|
Data Skipping based on built-in functions
(Can queries perform data skipping based on functions defined on column values, in addition to literal column values?) |
|
Logical predicates on a source or a Generated column will prune files during query execution |
|
Partition Evolution
|
Hudi takes a different approach with coarse-grained partitions and fine-grained Clustering which can be evolved async without rewriting data. |
Delta Lake also considers more complex partitioning as an anti-pattern |
|
Data deduplication (can I insert data without introducing duplicates?) |
|
Merge Only |
|
Table Services |
||
|
File Sizing
|
|
OPTIMIZE cmd open sourced in 2.0, but automation still proprietary |
|
Compaction
|
|
File sizing only. No MoR, so no compaction of deletes/changes |
|
Cleaning
|
|
VACUUM is manual operation for data and managed for the transaction log |
|
Index management |
|
|
|
Linear Clustering |
Automated Clustering that can be evolved for perf tuning, user defined partitioners |
|
|
Multidimensional Z-Order/Space Curve Clustering
(Can I sort high cardinality data with space curves for performance?) |
Z-Order + Hilbert Curves with auto async clustering |
Z-Order through manual maintenance |
|
Schema Evolution
|
Schema evolution for add, reorder, drop, rename, update (Spark only) |
Schema evolution for add, reorder, drop, rename, update |
|
Scalable Metadata (Can the table metadata scale with my data sizes) |
Hudi MoR based metadata table w/ HFile formats for 100x faster lookups, self managed like any Hudi Table |
|
|
Platform Support |
||
|
CLI (Can I manage my tables with a CLI) |
|
|
|
Data Quality Validation (Can I define quality conditions to be checked and enforced?) |
|
|
|
Pre-commit Transformers (Can I transform data before commit while I write?) |
|
|
|
Commit Notifications (Can I get a callback notification on successful commit?) |
|
|
|
Failed Commit Safeguards (How am I protected from partial and failed write operations?) |
|
|
|
Monitoring (Can I get metrics and monitoring out of the box?) |
MetricsReporter for automated monitoring |
|
|
Savepoint and Restore (Can I save a snapshot of the data and then restore the table back to this form?) |
Savepoint command to save specific versions.
|
Restore command with time travel versions
Have to preserve all versions in vacuum retention (eg. If you want to restore to 6mon ago, you have to retain 6mon of versions or DIY) |
|
Ecosystem Support |
||
|
Apache Spark |
||
|
Apache Flink |
||
|
Presto |
||
|
Trino |
||
|
Hive |
||
|
DBT |
||
|
Kafka Connect |
|
|
|
Kafka |
||
|
Pulsar |
||
|
Debezium |
||
|
Kyuubi |
|
|
|
ClickHouse |
||
|
Apache Impala |
|
|
|
AWS Athena |
||
|
AWS EMR |
||
|
AWS Redshift |
||
|
AWS Glue |
||
|
Google BigQuery |
|
|
|
Google DataProc |
||
|
Azure Synapse |
||
|
Azure HDInsight |
||
|
Databricks |
||
|
Snowflake |
|
|
|
Vertica |
||
|
Apache Doris |
|
|
|
Starrocks |
||
|
Dremio |
|
|
社区发展势头
社区与开源项目的功能和能力同样重要。社区可以成就或毁掉开发势头、生态系统采用或平台的实用性。以下是 Hudi、Delta 和 Iceberg 在社区方面的比较。
Github Stars：
Github 星星是一个虚荣指标，它代表受欢迎程度而不是贡献。Delta Lake 在知名度和受欢迎程度方面处于领先地位。
Github Watchers and Forks
A closer indication of engagement/usage of the project is the number of watchers a project has on Github and the number of times it has been forked.
Github Contributors
In December 2022, Apache Hudi had almost 90 unique authors contribute to the project - more than double the number for Iceberg and triple the number for Delta Lake.
Github PRs and Issues
In December 2022 Hudi and Iceberg merged about the same # of pull requests (PRs), while the number of PRs opened was double in Hudi.
Contribution Diversity
Apache Hudi and Apache Iceberg have strong diversity as to the breadth of the community that contributes to the project.
Apache Hudi
Apache Iceberg
Delta Lake
TPC-DS 性能基准
标准性能基准很少能代表实际工作负载，我们强烈鼓励社区根据自己的数据进行自己的分析。尽管如此，这些基准可以作为一个有趣的数据点，当您开始自己研究选择 Lakehouse 平台时。以下是相关基准的参考。
Databeans 和 Onehouse
Databeans 与 Databricks 合作发布了 2022 年 6 月 Data+AI 峰会主题演讲中使用的基准，但他们错误配置了一个明显的开箱即用设置。Onehouse 在此处更正了基准：
https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-transparent-tpc-ds-lakehouse-performance-benchmarks
Brooklyn Data 和 Onehouse
Databricks 要求 Brooklyn Data 在 2022 年 11 月发布 Delta 与 Iceberg 的基准测试：
https://brooklyndata.co/blog/benchmarking-open-table-formats
Onehouse 添加了 Apache Hudi 并在 Brooklyn Github repo 中发布了代码：
https://github.com/brooklyn-data/delta/pull/2
从这些基准测试中可以得出一个清晰的模式：Delta 和 Hudi 相当，而 Apache Iceberg 始终落后，是所有项目中速度最慢的。性能并不是您应该考虑的唯一因素，但性能确实可以转化为整个管道的成本节省。
关于运行 TPC-DS 基准测试的说明：
在运行比较 Hudi、Delta 和 Iceberg 的 TPC-DS 基准测试时，需要记住的一个关键点是，默认情况下，Delta 和 Iceberg 针对仅追加工作负载进行了优化。相比之下，Hudi 的默认设置针对可变工作负载进行了优化。默认情况下，Hudi 使用“upsert”写入模式，与插入相比，这自然会产生写入开销。如果没有这些知识，您可能会将苹果与橘子进行比较。将这个开箱即用的配置更改为“bulk-insert”以获得公平的评估：
https://hudi.apache.org/docs/write_operations/
功能亮点
构建数据湖平台不仅仅需要检查列出功能可用性的复选框。让我们挑选上面的几个差异化功能，深入探讨用例和实际好处。
增量管道
如今，大多数数据工程师都觉得他们必须在流数据和老式批量 ETL 管道之间做出选择。Apache Hudi 开创了一种称为增量管道的新范式。Hudi 开箱即用，可跟踪所有更改（附加、更新、删除）并将它们公开为更改流。借助记录级索引，您可以更有效地利用这些更改流，以避免重新计算数据，而只需使用增量更新来处理更改。虽然其他数据湖平台可能支持以增量方式使用更改，但 Hudi 的设计从一开始就旨在高效地实现增量化，从而实现具有成本效益且延迟更低的 ETL 管道。
Databricks 最近开发了一项类似的功能，他们称之为更改数据馈送，他们将其视为专有技术，直到它最终在 Delta Lake 2.0 中开源。Iceberg 具有增量读取功能，但它只允许您读取增量附加，而不能读取更新和删除 - 这对于真正的变更数据捕获 (CDC) 和数据湖中的事务数据至关重要。
并发控制
ACID 事务和并发控制是数据湖的关键特征，但与实际工作负载相比，当前的设计实际上如何？Hudi、Delta 和 Iceberg 都支持乐观并发控制 (OCC)。在乐观并发控制中，写入器检查它们是否有重叠文件；如果存在冲突，它们将使操作失败并重试。以 Delta Lake 为例，这只是在单个 Apache Spark 驱动程序节点上持有的 Java 虚拟机 (JVM) 级锁 - 这意味着直到最近，您在单个集群之外都没有 OCC。
虽然这可能适用于仅附加的不可变数据集，但乐观并发控制在实际场景中会遇到困难，这需要频繁更新和删除 - 要么是因为数据加载模式，要么是因为需要重新组织数据以获得更好的查询性能。
通常，将写入器脱机进行表管理以确保表健康且性能良好是不切实际的。 Apache Hudi 并发控制比其他数据湖平台（文件级）更细粒度，并且通过针对多个小更新/删除进行优化的设计，在大多数实际用例中，冲突可能性可以大大降低到可以忽略不计。
您可以在此博客中阅读更多详细信息，了解如何在多写入器场景中使用异步表服务，而无需暂停写入器。这实现了非常接近标准数据库支持的并发级别。
读取时合并
任何好的数据库系统都支持写入性能和查询性能之间的不同权衡。Hudi 社区在为整个行业的数据湖存储定义这些概念方面做出了一些开创性的贡献。Hudi、Delta 和 Iceberg 都在 Apache Parquet 文件中写入和存储数据。发生更新时，这些 Parquet 文件会被版本化并重写。这种写入模式就是业界现在所说的写时复制 (CoW)。此模型非常适合优化查询性能，但可能会限制写入性能和数据新鲜度。
除了 CoW 之外，Apache Hudi 还支持另一种称为读取时合并 (MoR) 的表存储布局。读取时合并使用列式 Parquet 文件和基于行的 Apache Avro 日志文件的组合来存储数据。更新可以在日志文件中分批进行，然后可以同步或异步压缩到新的 Parquet 文件中，以平衡最大查询性能和较低的写入放大。
因此，对于近乎实时的流式工作负载，Hudi 可以使用更高效的面向行的格式，而对于批处理工作负载，Hudi 使用可矢量化的面向列的格式，并在需要时无缝合并这两种格式。许多用户转向 Apache Hudi，因为它是唯一具有此功能的项目，这使他们能够实现无与伦比的写入性能和端到端数据管道延迟。
分区演进
Apache Iceberg 数据湖项目经常强调的一个功能是隐藏分区，它解锁了所谓的分区演进。基本思想是，当您的数据开始演进时，或者当您无法从当前分区方案中获得所需的性能时，分区演进允许您更新分区以适应新数据，而无需重写数据。
当您演进分区时，旧数据将保留在旧分区方案中，只有新数据会随您的演进进行分区。但是，如果用户不知道或者根本没有考虑到演变历史，那么以多种方式分区的表会给用户带来复杂性，并且无法保证一致的性能。
Apache Hudi 采用不同的方法来解决随着数据随聚类而演变而调整数据布局的问题。您可以选择粗粒度分区策略，甚至可以让数据保持未分区状态，并使用更细粒度的无分区聚类策略。使用 Apache Hudi，聚类可以同步或异步运行，并且可以在不重写任何数据的情况下进行演变。这种方法与 Snowflake 使用的微分区和聚类策略相当。
多模态索引
索引是数据库和数据仓库不可或缺的功能，但在数据湖中却基本缺失。在最近的版本中，Apache Hudi 为数据湖创建了首创的高性能索引子系统，我们称之为 Hudi 多模态索引。Apache Hudi 提供了一种异步索引机制，允许您构建和更改索引而不影响写入延迟。此索引机制可扩展且可扩展，可支持任何流行的索引技术，例如 Bloom、哈希、位图、R 树等。
这些索引存储在 Hudi 元数据表中，该表存储在云存储中您的数据旁边。在此新版本中，元数据以优化的索引文件格式编写，与 Delta 或 Iceberg 通用文件格式相比，点查找的性能提高了 10-100 倍。在测试实际工作负载时，这个新的索引子系统可将整体查询性能提高 10-30 倍。
提取工具
数据平台与数据格式的区别在于可用的运营服务。 Apache Hudi 的差异化因素是强大的数据提取实用程序 DeltaStreamer。（“Delta” 指的是对数据的更改，而不是对特定数据湖项目的更改。）DeltaStreamer 经过实战测试，并在生产中用于构建当今地球上一些最大的数据湖。DeltaStreamer 是一个独立的实用程序，它允许您从各种来源（例如 DFS、Kafka、数据库更改日志、S3 事件、JDBC 等）逐步提取上游更改。
Iceberg 没有针对托管提取实用程序的解决方案，而 Delta Autoloader 仍然是 Databricks 专有的功能，仅支持 S3 等云存储源。
用例 - 来自社区的示例
功能比较和基准测试可以帮助新手了解可用的技术选择，但更重要的是评估您自己的用例和工作负载，以找到适合您的数据架构的方案。 Hudi、Delta 和 Iceberg 这三种技术都有不同的起源故事，并且针对特定用例具有不同的优势。Hudi 是最初的数据湖库项目，诞生于 Uber，旨在近乎实时地为 PB 级数据湖提供支持，并提供轻松的表管理。Iceberg 诞生于 Netflix，旨在克服文件列表等云存储规模问题。Delta 诞生于 Databricks，在使用 Databricks Spark 运行时时具有深度集成和加速。
从多年来在社区中参与实际比较评估的经验来看，当您拥有成熟的工作负载，并且超出简单的追加插入时，Apache Hudi 通常具有技术优势。一旦您开始处理许多更新、开始添加真正的并发性或尝试减少管道的端到端延迟，Apache Hudi 就会在性能和功能集方面脱颖而出，成为行业领导者。
以下是社区成员独立评估并决定使用 Apache Hudi 的一些示例和故事。
亚马逊包裹递送系统
这个故事描述了亚马逊运输服务 (ATS) 如何实施基于 Apache Hudi 的数据湖，以应对大规模数据提取挑战和高度可变的工作负载。
“ATS 面临的最大挑战之一是处理 PB 级数据，需要不断插入、更新和删除，同时尽量缩短时间延迟，这反映了真实的业务场景和向下游数据消费者的包裹移动。”
“在这篇文章中，我们展示了如何以每小时数百 GB 的量级实时提取数据，并使用通过 AWS Glue Spark 作业和其他 AWS 无服务器服务（包括 AWS Lambda、Amazon Kinesis Data Firehose 和 Amazon DynamoDB）加载的 Apache Hudi 表在 PB 级数据湖上运行插入、更新和删除。”
ByteDance/Tiktok
这个 ByteDance/Tiktok 场景涉及更大的数据集，并表明在仔细考虑了所有三个数据湖项目后选择了 Hudi。
“在我们的场景中，性能挑战是巨大的。单表数据量最高达到400PB+，日增量PB级别，总数据量达到EB级别。”
“吞吐量比较大，单表吞吐量超过100GB/s，单表需要PB级存储，数据模式复杂，数据高维稀疏，表列数从1000到10000+不等，数据类型复杂度很高。”
“在引擎选择上，我们考察了三个最流行的数据湖引擎Hudi、Iceberg、DeltaLake，这三个在我们的场景中各有优缺点，最终基于Hudi对上下游生态的开放性、对全局索引的支持、以及针对某些存储逻辑的定制化开发接口等因素，选择了Hudi作为存储引擎。”
沃尔玛
沃尔玛在全球拥有约 11,000 家门店，平均每家门店每周的销售额超过 100 万美元，处理着大规模和关键性的数据。
来自视频转录：
“好吧，那么是什么让我们能够做到这一点，为什么我们真的喜欢 Hudi 的功能，这些功能在其他用例中已经解锁了这一点？我们喜欢可用的乐观并发或 MVCC 控件。我们在异步压缩方面做了很多工作。我们正在研究在读取表合并时进行异步压缩而不是内联压缩。
我们还希望减少延迟，因此我们利用读取表合并，这非常重要，因为这使我们能够更快地附加数据。我们也喜欢对删除的本机支持。这是我们为 CCPA 和 GDPR 等构建的自定义框架，有人会提交服务台票证，我们必须构建自动化流程来从 HDFS 中删除记录；现在这对我们来说是开箱即用的。
行版本控制确实很关键；显然，我们的许多管道都有无序数据，我们需要显示最新记录，因此我们将版本密钥作为所有插入 Hudi 表的框架的一部分。
客户可以选择要保留多少行的版本，以便能够提供快照查询并获得增量更新（例如过去五个小时内更新的内容），这对很多用户来说非常强大。”
Robinhood
投资网站 Robinhood 广泛使用 Kafka 流式传输的变更数据捕获 (CDC) 来最大限度地提高数据湖中的数据新鲜度。
“Robinhood 确实需要保持数据湖的数据新鲜度较低。许多过去在市场营业时间前后按每日节奏运行的批处理管道必须以每小时或更高的频率运行，以支持不断变化的用例。很明显，我们需要一个更快的提取管道来将在线数据库复制到数据湖。”
“我们正在使用 Apache Hudi 以增量方式从 Kafka 提取更改日志以创建数据湖表。 Apache Hudi 是一个统一的数据湖平台，用于在数据湖上执行批处理和流处理。Apache Hudi 配备了一个功能齐全的开箱即用的基于 Spark 的摄取系统 Deltastreamer，具有一流的 Kafka 集成和一次性写入功能。与不可变数据不同，我们的 CDC 数据有相当大比例的更新和删除。 Hudi Deltastreamer 利用其可插入的记录级索引在数据湖表上执行快速高效的更新插入。”
Zendesk
基于云的客户服务提供商 Zendesk 也在 Amazon 上的 Hudi Lakehouse 中广泛使用 CDC。
“数据湖管道将来自 Zendesk 高度分布式数据库的数据整合到数据湖中进行分析。
Zendesk 使用 Amazon Database Migration Service (AWS DMS) 从八个 AWS 区域中的 1,800 多个 Amazon Aurora MySQL 数据库中进行变更数据捕获 (CDC)。它检测事务更改并使用 Amazon EMR 和 Hudi 将其应用于数据湖。
Zendesk 票证数据包含超过 100 亿个事件和 PB 级数据。Amazon S3 中的数据湖文件以 Apache Hudi 格式转换和存储，并在 AWS Glue 目录中注册，以作为数据湖表提供，以便通过 Amazon Athena 进行分析查询和使用。”
GE Aviation
GE Aviation 还使用 Apache Hudi 来管理 CDC 管道，从而实现规模的快速增长。
“在 AWS 中引入更无缝的 Apache Hudi 体验对我们的团队来说是一个巨大的胜利。我们一直忙于将 Hudi 整合到我们的 CDC 交易管道中，并对结果感到非常兴奋。我们能够花更少的时间来编写代码来管理数据存储，而花更多的时间专注于系统的可靠性。这对我们的扩展能力至关重要。随着我们即将进行另一次重大生产切换，我们的开发管道已超过 10,000 个表和 150 多个源系统。”
创新社区
最后，考虑到数据湖技术的发展速度如此之快，重要的是要考虑该领域的开源创新来自何处。以下是一些源自 Hudi 的基础思想和功能，现在已被其他项目采用。
| Hudi OSS Community Innovation | Equivalent Feature |
| Transactional updates (March 2017) | Delta OSS (April 2019) |
| Merge On Read (Oct 2017) | Iceberg (Aug 2021, v2 format approval) |
| Incremental Queries (March 2017) | Delta Change Feed OSS 2.x (June 2022) |
| Z-order/Hilbert Space Curves (Dec 2021) | Delta OSS 2.x (June 2022) |
事实上，除了表元数据（文件列表、列统计信息）支持之外，Hudi 社区还率先推出了构成当今数据湖的大多数关键功能。在过去四年中，社区已经支持了 1500 多个用户问题和 5500 多个 Slack 支持线程，并且正在迅速壮大，并拥有雄心勃勃的愿景。用户可以将此创新记录视为未来的领先指标。
结论
在为您的数据湖选择技术时，重要的是对您自己的用例进行评估。功能比较电子表格和基准不应成为决定性因素，因此我们只是希望这篇博文为您的决策过程提供一个起点和参考。Apache Hudi 具有创新性，久经沙场，并且将继续存在。加入我们的 Hudi Slack，在这里您可以提出问题并与来自全球各地充满活力的 Apache Hudi 社区合作。
如果您希望一对一咨询以深入了解您的用例和架构，请随时联系 info@onehouse.ai。在 Onehouse，我们拥有数十年设计、构建和运营世界上一些最大的分布式数据系统的经验。我们认识到这些技术非常复杂且发展迅速。此外，我们可能错过了某个功能，或者本可以更仔细地阅读有关上述某些比较的文档。如果您发现上述任何比较需要更正，请给 info@onehouse.ai 留言，以便我们确保本文中的事实准确无误。
更新说明
8/11/22 - 原始发布日期
1/11/23 - 刷新功能比较，添加社区统计数据 + 基准
1/12/23 - Databricks 贡献了一些小更正
10/31/23 - 小编辑
1/31/24 - 关于 OneTable 当前状态的小更新
10/8/24 - 关于 XTable（称为 OneTable）当前状态的小更新；添加了第三段以引用相关的新博客文章
- 登录 发表评论
- 3 次浏览
最新内容
- 6 hours ago
- 7 hours 43 minutes ago
- 7 hours 50 minutes ago
- 7 hours 55 minutes ago
- 8 hours 2 minutes ago
- 8 hours 44 minutes ago
- 8 hours ago
- 9 hours ago
- 9 hours 55 minutes ago
- 10 hours ago