Apache Hudi - 我们需要的开放数据湖仓一体平台

一些要点如下

• • Hudi 是一个草根开源项目，社区比以往任何时候都更强大。Hudi 社区在行业创新方面有着良好的记录，多年来一直为一些最大的数据湖和云供应商提供支持。
• • Hudi 是一个开放数据湖仓一体平台。开放表格式是必不可少的，但我们需要开放计算服务来实现无锁定的数据架构。将 Hudi 最小化为表格格式是一种不准确且不公平的表征。
• • 格式标准化是必不可少的，但并不妨碍解决与数据处理相关的复杂计算机科学问题的需要。Hudi 仍然更适合它所设计的增量工作负载。
• • 历史经常重演。Hudi 推出了世界上第一个生产数据湖仓一体，其中包含一种新的“Headless”计算模型，我们都喜欢这个模型。想要尽早支持创新技术的用户应该认识到创新从历史上来。
• • 在你为开源选择“付费”之前，你不会为它们付费。如果我们真的渴望开放，用户必须超越供应商所写或推销的内容，并根据技术事实和业务需求做出明智的决策。
• • 要认识到Hudi在数据生态系统中的应有地位，需要了解自上而下的供应商技术推动和自下而上的开源开发人员采用。我们将继续保持建设性和协作性，例如我们如何通过创建 Onetable（现在的 Apache XTable（孵化））来启动行业互操作性对话。
• • 接下来我们正在努力在未来几个月内将具有根本改进的存储和计算能力的开源数据湖数据库推向市场。

社区

毋庸置疑，Hudi 是一个非常成功和有影响力的开源项目，它已经为许多公司提供了 7+ 年，在云上管理多个 EB。但考虑到我们所处的位置以及市场上人为的双头垄断叙事，很高兴看到一些数据来获得观点。

Hudi 不会固步自封，在ASF经过验证的治理结构下，它作为一个独立的OSS社区继续蓬勃发展。下一个要解决的问题是 Hudi 在从业者中的心智份额。如果我们超越 80/20 的规则，即 80% 的市场叙事是由 20% 的影响者塑造的，我们会看到安静的数据从业者继续参与该项目，因为它提供了价值。这清楚地表明了 Hudi 的相关性和未来潜力。

社区应该为 Hudi 的实力感到自豪，尽管营销资金花在其他方向上。一些“专家”甚至供应商传播的流行叙述将在他们的世界观中缺乏可比的 Hudi “嗡嗡声”等同于不存在的 Hudi 社区的极端。下面的历史数据描绘了一幅截然不同的画面。总而言之，Hudi 社区比以往任何时候都更强大，只要社区愿意，它就会继续创新。

正如我在这里分享的那样，这些叙述有意或无意地破坏了 450+[1] 开发人员的辛勤工作，他们为项目贡献了超过 1.5M 行代码。现在就到此为止，因为这不是我们的主要关注点，但不幸的是，这似乎是试图在一个庞大而嘈杂的市场中建立独立的东西的严峻现实。

Hudi 如何融入开放数据湖仓一体

最近向互操作性和兼容性的转变只是强调了一种“格式谬误”，即我们在生活中所需要的只是简单地就某些数据格式达成一致。这就是 Hudi 在哲学上的不同之处，早在 2021 年就认为[2]，开放性的真正力量是由一个开放平台释放的，该平台为数据堆栈的所有组件提供开放选项，包括表优化、摄取/ETL 工具和目录同步机制。开放格式有助于在供应商之间轻松导入/导出/迁移存储中的数据。但是如果没有开放服务，将被迫向供应商付款或在内部从头开始构建所有内容。有时我会惊讶地听到这样的意见：“为什么 Hudi 要自我管理这些表。供应商不应该这样做吗？诚实的回答是，当我们第一次在 Uber 上线时，我不希望我们的工程师手动调整 4000+ 张表。但是多年来，Hudi 用户已经意识到他们可以提交作业，它将写入数据，然后以独立的方式管理表，而无需强制执行更多计划的后台作业。开放服务为用户带来了真正的价值，通过适当的数据管理作为“默认”操作模式来降低计算费用。

这种“开放”计算服务确实蚕食了供应商的潜在商业机会（包括我们的商业机会），但对于每个人来说，这是一个更好的模式，通过使这些自动化/智能化/自适应化，在平台层创造最大价值。上图说明了 Hudi 的各个部分如何提供开放数据/表格式和开放数据服务的组合。XTable 提供了关键的互操作性，以确保生态系统不会因表格式而破裂。正如你所看到的，堆栈中的大问题和隐藏在众目睽睽之下的锁定是目录。我们很乐意与我们和其他社区合作，为这个新的世界秩序重新构想一个真正开放、多格式的数据目录。

但是在技术上有什么不同呢？

开放是第一原则，但我们的技术愿景始终是为主流数据仓库和数据湖（现在融合成一个数据湖仓一体）“增量化数据处理”[3]，拥有强大的新存储层和内置的数据管理。然后用户可以在 Hudi 上添加自己的查询引擎/目录以完成堆栈。我看到许多用户甚至供应商将其与流处理混淆。我们不是在谈论处理存储在 Kafka 中的流并将结果发回 Kafka！这是对数据仓库/数据湖 ETL 的根本性重新思考，可以缓解成本或数据延迟问题。即使你现在不“关心”成本，为什么在“少即是多”的情况下多做？

让我们重新审视增量数据处理的概念。这是一种通过减少每次运行中处理的数据来优化常规 ETL 作业的策略。这是通过记录更改跟踪扫描较少的输入和通过更新记录写入较少的输出来实现的。此 AWS 实验室[4]提供了从批处理模型到增量模型的综合示例。我们独特的功能和设计选择经受住了时间的考验，证明了这种方法的有效性。

• • 保留更改历史记录的记录级元数据可有效地提取在某个时间点之后更改的记录，而无需保留所有历史表元数据。
• • 将表元数据作为更改日志而不是快照进行跟踪，以将活动元数据限制为固定大小，即使对于巨大的表大小也是如此。
• • 在可插入索引[5]模块下支持大约六个索引，以促进对表的高效/快速突变。
• • 智能[6]混合行和列数据格式，以平衡写入与读取放大以及扫描与点查找。
• • 表元数据和其他索引作为另一个[7] Hudi 表实现，以与表的比例成比例缩放。
• • 将记录分组到文件组中，以控制在读取时合并查询期间读取的数据量。
• • 记录更新而不是将其转换为删除和插入可能会影响数据的临时位置并降低查询性能。
• • 内置表和元数据管理，因此频繁更新数据/元数据不会降低查询性能。
• • 在写入器和表服务之间仔细协调，以最大限度地提高并发非阻塞操作，其中写入端无需“脱机”进行表维护。
• • 用于引入和增量 ETL 的平台工具，用于打包写入器、表服务、目录交互等，以简化生产路径。

那么 Hudi 是否只适用于这个增量处理用例？不是！虽然 Hudi 的存储和并发模型专门用于独特地支持增量读/写，但 Hudi 也支持所有常规批处理原语对“慢速移动数据”的需求。严格来说，Hudi 提供了跨常规批处理和增量处理的超集功能，其雄心勃勃的技术愿景是有朝一日使所有处理都增量化的。在奖章架构[8]方面，我们经常看到用户最终转向青铜/银层数据管道的增量模型。同时像 Apache Flink 这样的引擎可以解锁 Gold 层的端到端增量处理。所以这不是一个遥远的白日梦，而是现在正在展开的现实，并推动着Hudi在这些时期的成长。

来自社区的结果 ( 1[9]， 2[10]） 非常令人印象深刻，没有充分的理由不考虑支持增量模型的湖仓一体存储，即使今天只是批处理。这值得进一步阐述，但我希望理解它与设计标准表文件列表和统计表示是正交的。同样，XTable为Hudi带来了这种互操作性，具有批处理表格式（如果这有助于使其更加内化）来利用这些方面的工作。

云生态系统中的Hudi

我经常从与我打交道的几十位工程师那里听到，“数据空间令人困惑”或“术语太多了”。完全解释这一切超出了我的凡人能力，但在这里，我将尝试阐明云生态系统为什么/如何支持/不支持，谈论/不谈论 Hudi。如本文所述，除 Snowflake 和 Azure Synapse 外，所有主要仓库和湖查询引擎都支持“原生”读取 Hudi 表。对于写入表，Hudi 社区在 Apache Spark、Apache Flink 和 Apache Kafka Connect 上投入了大量精力，因为它们代表了在数据湖仓一体上编写的 ETL 管道的最大份额。此外，这些框架的技术功能有助于我们实现高性能且功能丰富的写入路径，例如，洗牌/重新分区以帮助实现索引或运行一些内联维护。虽然非常可行，但对于引擎供应商/维护者来说，自己实现这样的写入路径相对来说相对较少。

社区可以通过直接贡献拉取请求来维护这些集成，从而增加对 Apache Spark、Apache Flink、Presto、Starrocks、Doris、Trino 和 Apache Hive 等开源查询引擎的支持。云仓库是另一回事，因为它们都（至少在撰写本文时）默认使用其专有数据格式，同时并行采用开放数据格式。云仓库引擎本身仍处于关闭状态，OSS社区无法提供支持。这就造成了一种情况，即仓库通常会集中押注其中一种格式，以应对实际资源限制。但是，对 XTable 的更广泛支持[11]有助于利用对一种格式的支持（例如，Snowflake 中的 Iceberg）将其他格式的开放数据引入仓库引擎，而不会牺牲 Hudi/Delta Lake 写入器端功能。

现在我们了解了技术注意事项，让我分享一下如何在手机和计算机屏幕上将它们组合在一起。当营销团队进行日常业务时，“我们支持 x”的叙述被市场广泛解释为“我们不支持 y 和 z”，甚至“y 和 z 不好，因为支持 x”。在Hudi的案例中，供应商的绝对规模和市场规模进一步放大了这一点，以至于来自更小的开源社区的创新声音被践踏了。如果希望在引擎上支持 Hudi，只需询问供应商是否可以这样做。作为Onehouse的创始人，我们与所有查询引擎厂商平等合作，为用户带来真正开放的数据湖仓一体。但是从技术上讲，由于开放列式文件格式、开放表格式和 XTable，使用 Hudi 的能力不一定取决于任何供应商的支持。这怎么能更容易呢？Databricks、EMR、DataProc 和 Fabric 等基于 Spark 的平台解锁了一个更加开放的模型，让我们能够快速创新，而无需用户等待 1-2 年才能获得专有供应商的格式支持。开放数据格式是此类平台的默认格式，如果用户拥有工程资源，则可以轻松扩展平台以读取/写入新源。这将是一个梦幻般的世界，用户也可以扩展云仓库，毕竟这是用户的数据。

为什么 Hudi 值得信赖

对于用户来说，一个重要的考虑因素是确保他们的技术选择具有所需的支持结构。鉴于数据湖仓一体空间的实际技术进步来自 3 个开源社区，并且在整个行业中分布不均匀，因此将“支持”的含义内化非常重要。多年来，Hudi一直得到大约五家公共云提供商的支持和良好集成。如果支持意味着“获得帮助”，那么在项目存在期间，社区已经帮助其用户解决了超过 2500+ 个支持工单，并且 Slack 社区在过去六个月中响应时间中位数为 ~20 分钟。多年来，Hudi 提交者还本着社区精神，免费帮助解决了云供应商客户升级的许多生产问题。我相信一个自我维持的开源社区是最好的长期解决方案。第二。Hudi 在 Apache 软件基金会的监督下采用社区优先、以用户为中心的开源方法。有时，拥有某样东西的价值只有在你没有它时才会显现出来。如果你以业务关键型的方式使用开源技术，而没有良好的中立治理，你应该非常认真地思考。最后，Hudi 已经被世界上一些最大的数据湖所依赖。团队还可以通过做出贡献并成为有价值的社区成员来对行业产生巨大的影响。依赖开源软件确实需要付出更多的努力，而不是为所有麻烦付钱给供应商。但是，拥抱开源并更接近尖端创新是我们不可避免的未来。

我们对 Hudi 的愿景

去年年底，我们为 Hudi 1.x 的未来制定了一个大胆的愿景，包括整个堆栈的激动人心的变化、新功能的引入和新组件的添加，将 Hudi 更多地打包为数据库，此外（而不是代替）一个嵌入到数据处理框架和查询引擎中的库。社区正在花时间解决这个问题，同时支持具有更多功能的 0.X 发布行。这不是一个新概念，但我们认为用户从一开始就需要。然而生态系统支持需要更多，用户对数据湖的期望只坚持在作业和现有目录中的支持。随着现在一致同意向数据湖仓一体的融合，我们认为现在是重振这一愿景的更好时机，并考虑到自那以后的所有新发展，将其变为现实，并赋予更多价值 - 更成熟的 SQL 湖引擎、围绕数据互操作性的广泛共识、支持开放数据格式的仓库、对非结构化数据的需求增加、 更快的云存储等。

Hudi 的这一长期愿景将与其他项目不同，使 Hudi 更接近于云仓库/湖仓一体的开放版本。使用 Snowflake 的这个架构作为参考，我们将有一个类似的模型，其中 Hudi 维护其针对 Hudi 原生支持的功能优化的开放元数据/数据，同时确保可移植到 Iceberg/Delta 以实现互操作性。关于未来互操作性和统一表格式可能存在的问题，我们一直愿意始终如一地跨过道工作（例如，我们在 XTable 时帮助 Delta Uniform 支持 Hudi）。在技术上可行且社区愿意的范围内，我们将尝试与 Databricks 保持一致，通过探索 Hudi 中的一种模式来统一 2/3 的开放表格式，在该模式中，它写入Iceberg/增量存储兼容文件/元数据，可能会损失增量工作负载的功能和性能。共同的目标是为用户提供更多的权力和选择。

结论

我希望这篇博客能为开源用户提供一个更平衡的 Hudi 视图，这比供应商（包括 Onehouse）的想法更重要。数据湖仓一体仍然是一个非常“辛辣”的话题。你将继续看到数据爱好者用“R.I.P Hudi”之类的帖子来娱乐自己，或者猜测 Snowflake/Databricks 接下来会做什么。你会看到一些专家专栏文章在播放世界末日的场景，完全忽略了开源用户影响接下来发生的事情。我真诚的建议是从表面上看事情，做一些有助于你的项目并实现你公司的数据目标的事情。

引用链接

[1] 450+: https://github.com/apache/hudi/graphs/contributors [2] 认为: https://hudi.apache.org/blog/2021/07/21/streaming-data-lake-platform [3] “增量化数据处理”: https://www.oreilly.com/content/ubers-case-for-incremental-processing-on-hadoop/ [4] AWS 实验室: https://github.com/vinothchandar/hudi_shopping_cart_demo/tree/master [5] 索引: https://hudi.apache.org/docs/indexing/ [6] 智能: https://www.linkedin.com/posts/jorritsandbrink_dataengineering-softwareengineering-activity-7196666227786665986-YXIy/?utm_source=share&utm_medium=member_desktop [7] 另一个: https://www.onehouse.ai/blog/introducing-multi-modal-index-for-the-lakehouse-in-apache-hudi [8] 奖章架构: https://learn.microsoft.com/en-us/azure/databricks/lakehouse/medallion [9] 1: https://www.uber.com/blog/ubers-lakehouse-architecture/ [10] 2: https://aws.amazon.com/blogs/big-data/how-zoom-implemented-streaming-log-ingestion-and-efficient-gdpr-deletes-using-apache-hudi-on-amazon-emr/ [11] XTable 的更广泛支持: https://www.microsoft.com/en-us/microsoft-fabric/blog/2024/05/22/snowflake-and-microsoft-announce-expansion-of-their-partnership/