【Lakehouse】Walmart 的湖仓架构实践

沃尔玛系统产生了世界上最大、最多样化的数据集之一，每天增长10 PB的数据。从许多不同的来源及其支持的后端系统，一系列高容量的业务事件流被发送到我们的消息层，主要由Apache Kafka支持。

沃尔玛团队强烈希望扩展近实时决策，因为事件驱动架构、生产数据库的变更数据捕获（CDC）、ML和计算机视觉服务的显著增加，所有这些都导致了具有新查询模式的超大表。由于复杂的拓扑结构、事件的速度、数据的多样性和快速变化的模式，高效地存储这些事件以在我们的许多业务领域（例如，供应链、客户、库存、搜索等）进行进一步的聚合、报告、分析和机器学习是一项挑战。

正是考虑到这些挑战，沃尔玛已经开始将我们的数据湖从面向批处理的架构发展到现代的Lakehouse方法，通过寻求一个通用的框架来提供具有类似仓库的语义（强类型、事务保证和ACID合规性）的近实时数据，并通过缓存、列式统计、数据分区，压缩、集群和排序。

由于将数据从一种格式迁移到另一种格式需要花费大量的计算时间和开发人员时间，所选择的指导和方向将在多年内产生重大影响。为了减少所有未来已知和未知的风险，沃尔玛必须对支持的格式和运行时间的各个方面保持全面控制，确保在沃尔玛和公共云以及我们生态系统中的所有查询加速层上运行时，能够根据需要灵活地维护、修补、升级和扩展框架。这导致我们只能选择开源格式，以确保沃尔玛能够维护并为此做出贡献。

我们的团队根据以下内容评估了现代Lakehouse建筑的当前行业标准：

1. ·在我们的多云环境中，沃尔玛现实世界中两个关键工作负载的摄入/查询性能。WL1（工作负载1）由于延迟到达数据而具有显著扇出的无限时间分区数据，＜0.1%的更新，＞99.9%的插入，以及WL2（工作负载2）具有未分区数据写入的大部分有界基数，更新＞99.999%，＜0.001%的插入。
2. ·对底层设计选择和微妙权衡的体系结构审查。
3. ·与行业专家和其他财富500强公司的技术领导层进行讨论。

根据这项工作，考虑到系统特征或“不合格”，创建了加权得分矩阵：

1. ·可用性[3]、可恢复性和可移植性
2. ·与不同版本的Spark、执行和查询引擎的兼容性[3]
3. ·沃尔玛真实世界数据集上每单位工作的成本[3]
4. ·接收、查询、可调性、正常默认值、迁移任何现有数据的工作量的性能[2]
5. ·产品开发路线图[2]以及沃尔玛的贡献和影响力
6. ·支持[2]，产品、文档和部署控制的稳定性
7. ·基于工作成本和内部管理因素的TCO[3]（总拥有成本）

为了简洁起见，我们已经包含了对Apache Hudi、open source Delta和Apache Iceberg等开源数据湖格式（兼容性、性能和总体思想）的内部调查的亮点。

兼容性

获奖者：Apache Hudi

模式演变和验证

如今，沃尔玛在管理增强业务能力所需的数据管道总数方面有着巨大的开销。模式管理的复杂性使我们的业务现代化和发展所需的数千个应用程序更改进一步加剧了这一问题。理解和管理这些模式更改的兼容性对于构建一个健壮的Lakehouse至关重要。此外，至关重要的是，在我们的Lakehouse中，在可能的情况下，在源代码处快速解决无效的模式演变。

Lakehouse平台在写时强制执行模式（schemas ），从而缓解任何读兼容性问题，从而避免将发现和报告错误的责任推给使用系统。此外，如果在读取器发现故障之前写入了大量数据，则可能会导致数据丢失和/或成本高昂且耗时的恢复。通过在写入时验证模式，Hudi、Delta和Iceberg消除了大部分数据不兼容问题，但Lakehouse编写器仍然需要处理来自上游数据源的无效和不可映射的模式。许多上游模式问题无法通过任何一种Lakehouse格式来解决，需要通过灵活的模式管理或对上游源强制执行模式进化规则来全面解决。

Iceberg的模式进化方法是最灵活的，允许最大的潜在上游模式格式横截面，支持Protocol Buffers、Avro和Thrift中最有效的模式进化场景。Hudi和Delta支持Avro兼容的进化，但缺乏列重命名功能，这是一种支持的协议缓冲区和Thrift消息二进制表示的模式进化。这就要求沃尔玛对这些类型的管道实施限制，如果它们进入我们的Lakehouse。在处理流数据时，必须在不中断管道和查询的情况下处理模式更改，这排除了允许任何此类破坏性的向后不兼容更改的可能性。

在向上游数据源写入时验证模式有助于缓解这一问题，然而，由于沃尔玛中很大一部分流数据是使用JSON编码的“代码中的模式”，因此迁移到基于合同的数据交换格式的路径将很长。由于可能会发生不受支持的模式更改，对强大的操作（工具和监控）进行大量投资，以及对数据所有者进行教育，以及对强制上游进行长期投资，沃尔玛的消息来源坚持通过全球模式注册管理的非破坏性模式更改。

出于同样的原因，所有Lakehouse表格式都只支持向后兼容性，以保留在未来进行突破性更改的权利。表格式架构的更改并不常见，但在迁移表之前，读取器可能需要升级。

引擎支架

沃尔玛的数据通过各种引擎进行查询：Hive和Spark、Presto/Trino、BigQuery和Flink。对所有这些引擎的本地读写器支持对于减少现有客户迁移到新Lakehouse所需的更改非常重要。此表列出了沃尔玛使用引擎的程度，以及每种产品对该引擎的支持。

架构与设计

性能的提高是沃尔玛开始调查表格格式变化的主要原因。Hudi、Delta和Iceberg都以性能为中心，虽然下表中指出的每种系统方法都有差异，但它们的功能可以分为并发、统计、索引、主机代管和重组。

性能

获奖者： Apache Hudi

摄入性能

批处理和流接收基准测试是在两个难以满足业务延迟SLA的真实工作负载上执行的。这两个关键的内部工作负载被称为WL1和WL2。WL1（批处理）是一个典型的基于时间的表，按年、月、日、小时进行分区，并且存在大量延迟到达的记录，导致Spark摄入在许多分区中受到显著的读/写放大。没有分区的WL2（流式传输）维护到有界数据集的行级追加，其中低延迟数据通过从多TB Cassandra表中捕获变化数据来投影。

WL2模式已成为沃尔玛在有限的操作数据集上保持对低延迟数据湖表的商业需求的关键模式。

为了测试，为所有测试构建了完全隔离的环境，以避免出现任何噪声邻居的机会。然后部署每个摄取作业（德尔塔、胡迪、冰山、Legacy），并留出足够的时间达到稳定状态。在一组合理的批次（n>30）中测量中位批次摄入时间，并在摄入的总核心中进行归一化，以确定加权得分[摄入的时间*GB]/核心（最低得分为最佳）。当执行压缩时，通过与外部Spark应用程序异步执行或内部内联（阻塞）隔离压缩来计算与标准摄取类似的度量，并从压缩阶段开始测量。

WL1的结果表明，与现有的ORC处理管道相比，摄取性能显著提高，性能提高了5倍以上，性能最好的是在Spark 3.x上运行的Hudi。对于WL2，流式摄取性能在Delta上提高了27%，然而，Hudi的压缩速度要快得多，因为上的应用程序执行了压缩，并且缺乏在Delta管道中执行的ZOrdering（在测试时，Hudi还不支持异步排序）。这种额外的效率大大提高了Delta中的查询性能。

Delta WL2模式-摄入困难

摄入作业-包括要处理的目标分区文件和记录的全局混洗-150个核心（6个多小时，未完成）

阅读器具有干净压缩的数据视图（无需合并日志以获得实时视图），但随着基数的增加，合并成本越来越高

由于全局混洗的成本和不断增长的数据大小，Delta编写器无法有效处理数据。我们尝试了一种替代体系结构来将数据附加到表中并运行后台（异步-非阻塞压缩），但德尔塔的体系结构阻止了这些操作的成功完成。

摄入作业-由两个作业组成，一个是仅附加流作业，另一个是异步cron计划压缩。由于多个写入程序接触相同的文件，因此此操作失败。

阅读器通过读取重复项并在数据上应用窗口来消除记录的重复。

Hudi WL2 Pattern

在我们的测试中，具有同步或后台压缩的Hudi MOR（Merge on Read）表是唯一能够处理这种模式的打开文件格式，确保数据消费者可以使用最新的写入和清理视图。

摄入作业-具有行密钥到文件组映射，降低了连接操作的复杂性--150个核心（约15分钟的批处理/50分钟的压缩）

读卡器-可以选择压缩（避免更改日志视图）或性能较慢的实时视图。定期压缩将日志合并到各自的文件组中

查询性能

选择了常见的业务查询模式，并将其命名为工作负载1的Q1-Q7和WL2的Q1-Q10。这些模式包括：

1. ·表计数
2. ·聚合分区计数
3. ·计数行键
4. ·基于分区的计数行键
5. ·基于row键的大海捞针
6. ·基于行键和分区的大海捞针
7. ·基于数据集字段的大海捞针
8. ·基于数据集字段和分区的大海捞针
9. ·行键上的双向表连接
10. ·行键上的三向表联接

 

尽管Delta在大多数查询中提供了约40%的最佳性能，但与Hudi RT端点相比，在事务实时数据之上的Delta视图也有例外，Hudi在提供端点的重复数据消除（最新记录视图）方面明显更快。Delta的一个显著性能优势是记录的ZOrdering，这将在表中的大多数查询中创造优势。自测试以来，现在Hudi中提供了ZOrdering，并改进了文件组元数据管理。这将使基准更加接近。

在图3和图4中，总结了经过测试的三种Lakehouse技术的查询和摄取性能。需要考虑的一个关键脚注是，Hudi提供了显著的性能优化，尽管配置比Delta更复杂。在我们测试时，“开箱即用”的Delta默认配置得到了显著的优化，并且需要更少的框架知识才能发挥作用。

全面的

获奖者：Apache Hudi

根据沃尔玛的调查，考虑到我们在可用性、兼容性、成本、性能、路线图、支持和TCO方面的加权矩阵的最终得分，Apache Hudi被选中为我们的下一代Lakehouse提供支持。此外，值得注意的是，我们的最终决策受到了高度多样化的技术堆栈的巨大影响，我们在沃尔玛的内部云、谷歌和Azure中拥有超过60万个Hadoop和Spark核心。这些工作负载还运行在大量Spark发行版和版本中。Apache Hudi是唯一一个与2.4.x Spark兼容的版本，使我们能够在庞大的生态系统中获得更大的灵活性和采用。

沃尔玛已经开始了一场重大的转型，从一些关键工作负载的迁移开始。旅程尚未完成，该领域正在迅速发展，沃尔玛将不断重新评估该领域的最新技术，为这些开源举措做出贡献，推动它们满足我们复杂的业务需求，并确保新的和传统的仓储技术之间的互操作性。

沃尔玛平台团队广泛利用开源技术，因此我们的重点是仅评估开源数据湖格式。我们并没有把重点放在企业产品上。考虑到这一点，我们选择了Apache Hudi来推动我们的Lakehouse模式向前发展。来帮助世界上最大的公司进行转型，支持创建周围最大的Lakehouse之一，我们正在招聘！！

注意：需要注意的是，这个领域的情况正在迅速变化，到发布时，这个博客中的一些发现和结果可能已经过时。我们利用Delta Core 1.0.0、Apache Iceberg 0.11.1、Apache Hudi 0.10.1进行了基准测试

共同贡献者：

• Toni LeTempt — Walmart Sr. Director
• Konstantin Shavachko — Walmart Distinguished Engineer
• Satya Narayan — Walmart Sr. Distinguished Technical Architect