介绍

在我们之前的博客中，我们比较了Delta 1.2.0、Iceberg 0.13.1和Hudi 011.1，我们发布了我们的测试结果，却发现误解了 Apache Hudi 的真正能力。

尽管我们不同意，但我们认真对待这一点，我们决定使用他们的配置再次运行基准测试。我们在这个博客中分享了我们对如何进行基准测试的看法，我们还深入研究了 Hudi 的调整并讨论了它对整体性能的影响。

基准测试结果

1. 整体性能

在调整 Hudi 的配置后，Delta 仍然是整体上最快的，差别很小，可以忽略不计。

Tuned Hudi 的整体性能得到改善，比开箱即用的Hudi快 4.29 倍。

2.加载性能

Delta 在加载性能方面仍然是最快的，而且差异可以忽略不计。

Tuned Hudi 的加载性能比开箱即用的Hudi快 9.35 倍。[图表2]

3.查询性能

调优后，Hudi比开箱即用的 Hudi 快1.38倍。因此，它达到了与开箱即用的 Delta 类似的性能。

Hudi的调优分析

为了提高 Hudi 的性能，Onehouse 建议调整一些 Table、Spark DataSource、Storage 和 Metadata 配置。如果我们知道 Hudi 总共有超过70 个 spark 数据源配置、60 个写入配置、超过15 个存储配置和超过20 个元数据配置以及数十种其他配置，那么需要进行大量调整 . 这正是我们希望通过运行基准测试来避免的那种复杂性，而无需对所有 3 种格式进行任何调整，并且只使用它们的默认配置。否则，每种格式总会有一些东西需要调整和调整，每个人在他的基准测试中都会看起来不错，用户会被拖入很多复杂的环境中，而对他们的日常工作负载影响很小甚至是负面的。

同样重要的是要说明 Hudi 的调优技术性太强，需要深入了解它的底层功能。一些调整选项对普通用户没有意义，因为它“似乎”与文档相矛盾，其他选择只能由专家支持，而其他选择只是为了模仿 Delta 的配置。

1. 禁用 Hudi 的元数据表。

Hudi 0.11.1 默认启用元数据表，根据Hudi 文档，它们显着提高了读/写性能。因此禁用此配置以使 Hudi 的性能更好似乎与调整意图不一致。我们需要 Onehouse Hudi 的专长来做出这样一个反直觉的决定。此外，这种自定义和复杂的调整会对基准测试的完整性产生非常糟糕的影响。它为诸如为什么不在 Delta 和 Iceberg 上尝试类似的事情（例如禁用统计数据收集）等问题打开了大门。

实际上，Iceberg 0.13.1 相比 0.13.0 版本实现了 2 倍的性能提升，而无需任何调整工作（参见之前的博客）。这是 Iceberg 开箱即用的表现。对于 Delta 1.2.0，与 1.0.0 版本相比，负载性能下降了 15%。任何改进它的调整工作都不应该成为基准测试的一部分。事实上，我们定期调整 Iceberg、Hudi 和 Delta 并在它们上运行基准测试，但我们选择不分享结果，因为我们相信开箱即用的性能对客户来说最重要。

2. Onehouse 调整 Hudi 的文件大小以匹配 Delta 的设置。

为什么 hudi 需要匹配 Delta 的默认设置？我们认为这种调整也会影响基准测试的完整性。为了正确运行基准测试，我们不应使用其默认设置运行 SUT（被测系统）A，然后使用其中一些来调整 SUT B。每个 SUT 都需要使用其自己的默认配置进行测试，并且不对其他。如果即使对于 Hudi，默认 Delta 文件大小也比 Hudi 的文件大小更优化，为什么不将其也设为 Hudi 的默认值呢？

3.将Hudi的压缩编解码器更改为snappy。

Hudi 使用 gzip 作为默认压缩编解码器，而 Delta 使用 Snappy。因此，即使我们决定调整一个 SUT（我们认为这不是运行基准测试的正确方式），调整决策也不应该受到另一个 SUT 配置的启发，否则这将只是为了基准测试而调整。如果 Snappy 更适合 Hudi，这应该反映在 Hudi 默认配置中。

4.回退到parquet写入遗留格式。

根据Hudi 文档，如果启用，数据将以 Spark 1.4 及更早版本的方式写入。这不是一个简单的调整操作。事实上，在使用 spark 3.2 时使用 spark 1.4 写入数据的方式至少对于简单的 Hudi 用户（比如我们）来说没有多大意义。它需要这方面的专家。

结论

Lakehouse 的承诺之一是提供 Datawarhouse 的简单性和性能。Lakehouse 上的用户应该专注于他们的业务用例，而不是通过配置来选择正确的文件大小、选择最佳压缩或运行维护操作。Lakehouse 上的工作负载需要为大小表、高或低并发查询以及所有类型的工作负载按预期运行。这就是为什么我们强烈认为需要在没有任何调整工作的情况下对开放格式进行基准测试，并且需要测量开箱即用的性能。我们知道每种开放格式都有自己的改进空间，但如果我们希望 Lakehouse 成功，这应该是方向。

如果您有任何问题，请随时通过 databeans-blogs@databeans.fr 与我们联系

原文链接：https://databeans-blogs.medium.com/delta-vs-hudi-databeans-vision-on-benchmarking-32d1774a7c20