数据存储的演变

Ankur 以数据存储方法的历史开始了演讲，包括每种方法的动机、优点和缺点。他解释说，最初数据仓库是结构化数据的首选解决方案，可以有效地与商业智能 (BI) 工具连接以生成见解。然而其高昂的运营成本以及维护的复杂性标志着对创新的需求。

进入数据湖时代。在 2012 年至 2013 年左右 Apache Hadoop 的发展和云存储激增的推动下，数据湖因其不仅能够处理结构化数据，而且能够处理大量半结构化和非结构化数据而受到关注。数据湖因其可扩展性和多功能性而成为大型组织的主要组成部分。尽管有其优势，数据湖在维护数据完整性和防止数据变成混乱的“数据沼泽”方面提出了显着的挑战。数据沼泽的解决方案？Ankur 认为，它需要是一种两全其美的方法——数据湖屋。他解释说，“……数据仓库非常适合管理功能，并且数据湖具有可扩展性和敏捷性……我们正在结合[它们的优势]并创建数据Lakehouse。”

了解 Apache Hudi

随着这种自然的演变，Ankur 和 Ayush 旅程的下一步是为沃尔玛选择正确的数据Lakehouse架构。虽然主流使用三种开放表格式（Apache Hudi、Apache Iceberg 和 Delta Lake），但沃尔玛选择使用 Apache Hudi 有两个关键原因：

1. 它最擅长启用流处理和批处理，这对其用例至关重要
2. 它对流媒体用例的开源软件 (OSS) 格式提供最佳支持

Ankur 解释说，Apache Hudi 的核心是其创新结构，它以独特的方式将数据文件（以 Parquet 格式存储）与元数据结合起来，以实现一系列优势。这种设计可实现高效的数据管理并支持重要功能，例如记录主键和预组合主键。

为了准确解释 Hudi 的工作原理，Ankur 首先介绍了核心概念和术语：

• 记录键：与任何关系数据库管理系统 (RDBMS) 中的主键或组件键相同。
• 预组合键：用于更新插入排序的字段。
• 索引：记录键与文件组或文件 ID 之间的映射。这些有助于尽快扫描数据。
• 时间轴：不同时刻在表上执行的所有操作的事件顺序。这有助于创建时间序列数据视图或探索。
• 数据文件：Parquet 格式的实际数据文件。

为了帮助建立围绕该系统的一些直觉，Ankur 描述了它如何使用假设的学生数据库来工作。在他的示例中，学生 ID 充当主键，创建的列是分区路径，记录上的“更新时间戳”充当预组合键。

通过此设置，如果从学生记录的源到目标传入 upsert（即更新记录的操作，或在记录尚不存在时插入记录的操作），将会发生一些事情：Hudi 将检查传入数据是否具有该特定预组合键的更大值，即我们示例中的“更新时间戳”字段。然后它将简单地更新插入数据，确保我们将最新数据更新到目标中，而无需查看所有其他记录，这要归功于我们可以检查的方便的预组合字段，从而显着加快了操作速度。

Hudi 还支持两种类型的表——“写入时复制”(CoW) 和“读取时合并”(MoR)。写入时复制对于读取密集型环境来说是最佳选择，因为它在数据写入阶段应用大多数操作。相比之下读时合并适合写入量大的场景。

在组织中启用 Apache Hudi

鉴于 Ankur 提供的 Apache Hudi 的工作直觉，Ayush 深入研究了 Apache Hudi 在组织中的实际启用，解决了他经常遇到的一个问题：“在我的数据湖架构中启用 Hudi 有多容易？” 事实证明相当容易。Ayush 解释说，这是因为 Hudi 与下游存储和上游计算或查询引擎的交互方式。由于所有数据湖都使用某种文件系统（AWS 上的 S3 等），并且某些文件格式（Parquet、CSV 等）在其上存储数据，因此 Hudi 适合原始数据格式和计算之间的层引擎。“[Hudi] 与计算引擎（无论是 Spark、BigQuery 还是 Flink）的兼容性都非常出色，我们可以继续使用现有的文件系统，”Ayush 说。

Hudi在沃尔玛的优势

总之 Hudi 直接带来了 Ayush、Ankur 和团队在沃尔玛的实施中直接看到的广泛好处：

• 对行级更新插入和合并操作的显着更好的支持
• 模式实施、演进和版本控制（即在人们期望使用 RDBMS 的级别）
• 比其他方案更好的事务（ACID）支持
• 历史数据和版本控制，无需额外开销即可实现数据“时间旅行”
• 支持部分更新，无需单独的 NoSQL 系统来支持部分更新用例
• 内置对硬删除和软删除的支持，消除整个类别的潜在实施错误
• 支持更高效的索引和聚簇
• 使用主键和重复数据删除键的组合进行高效的重复处理

为了为他们看到的改进的更新插入和合并操作提供更好的直觉，Ayush 解释了图书馆员如何在数据湖和数据湖房范式下组织物理图书馆文件。在这个比较中，我们的“图书馆员”在功能上是我们的计算引擎，它在这些场景中执行繁重的计算工作。在数据湖范式中，一批新的论文将被归档到许多松散组织的论文中。然后，图书馆员必须检查之前的每组论文，将它们组合起来，然后插入新的论文。这是因为现有的论文没有经过特别的组织，因此我们的图书馆员需要检查每一篇论文以使它们相对于彼此进行组织。

然而，在新的数据Lakehouse范式中，事情可以更有效地发生。这是因为现在我们的散文是一个组织良好的书架。当一批新的书籍进来归档时，由于组织的增强，我们的图书管理员只能与书架上的空间进行交互。

在实际实现中，Lakehouse方法还有一些额外的优点：减少开发人员开销和减少数据分叉。减少开发人员的开销对于整个组织来说非常重要，可以最大限度地减少潜在的错误向量和成本。Lakehouse 范式中为开发人员减轻的一项主要负担是读取和计算时间（图 4 中的步骤 2），因为在数据湖中，实现和管理全部由开发人员承担。此外湖范式中的数据删除（数据组织不清晰）可能会成为一个巨大的错误向量，跨分区和连接的错误删除很容易导致数据不正确或过时。

Lakehouse 由于其部分更新支持而减少了数据分叉（图 5 中的步骤 2）。以前团队经常使用单独的 NoSQL 数据库（例如 MongoDB）来支持这一重要用例。Hudi 允许开发人员将这些数据作为单一事实来源保留在文件系统中，同时仍然启用部分更新。这样可以节省资金，并通过减少重复来保持数据干净和最新。

总结

通过说明性的、外行人友好的示例，帮助开发 Apache Hudi 数据Lakehouse的清晰直觉，以及它给沃尔玛数据组织带来的明显好处，Ayush 和 Ankur 彻底解释了该系统的工作原理及其带来的巨大好处可以赋予数据组织。