日增数据超10PB！揭秘沃尔玛Lakehouse架构选型之路

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

沃尔玛团队强烈希望扩展近乎实时的决策制定，如事件驱动架构的显着增加、来自生产数据库的变更数据捕获 (CDC)、ML 和计算机视觉服务，所有这些都导致了大表新的查询模式。 由于复杂的拓扑结构、事件的速度、 数据种类繁多，模式快速变化。

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

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

我们团队基于以下方面评估了现代 Lakehouse 架构的当前行业标准：

• 在多云环境中摄取/查询两个关键工作负载的性能。 WL1（工作负载 1）无限时间分区数据，由于数据延迟到达，具有显着扇出，< 0.1% 更新，> 99.9% 插入和 WL2（工作负载 2）主要有界基数，未分区数据写入 > 99.999% 更新，< 0.001% 插入
• 对底层设计选择和架构评审的权衡
• 与其他财富 500 强公司的行业专家和技术领导进行讨论

从这项工作中，考虑到系统特征创建了一个加权分数矩阵：

• 可用性 [3]、可恢复性和可移植性
• 与不同版本的 Spark、执行和查询引擎的兼容性 [3]
• 沃尔玛真实世界数据集上每单位工作的成本 [3]
• 摄取、查询、可调优的性能[2]，合理默认值、迁移现有数据成本
• 产品开发路线图 [2] 以及沃尔玛的贡献和影响能力
• 支持 [2]，产品、文档和部署控制的稳定性
• TCO [3]，基于工作成本和内部管理因素

为简洁起见我们包含了对开源数据湖格式（如 Apache Hudi、开源 Delta 和 Apache Iceberg）的调研（兼容性、性能和总体想法）。

兼容性

获胜者：Apache Hudi

模式演变和验证

今天沃尔玛在管理支持业务所需的数据管道总数方面有巨大的开销。 使我们的业务现代化和发展所需的数千个应用程序更改导致模式管理复杂性进一步加剧了这种情况。了解和管理这些架构演变的兼容性对于构建强大的 Lakehouse 至关重要。 此外至关重要的是 Lakehouse 中的无效模式演变必须在源头上迅速解决，并尽可能在源头上解决。

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

Iceberg 的模式演化方法是最灵活的，允许潜在上游模式格式，支持 Protocol Buffers、Avro 和 Thrift 中最有效的模式演化场景。 Hudi 和 Delta 支持 Avro兼容的模式演变，但缺乏列重命名能力， Protocol Buffers 和 Thrift 消息的二进制表示中支持该 Schema Evolution。 这要求沃尔玛在这些类型的管道进入我们的 Lakehouse 时对其实施限制。 在处理流数据时，模式演变必须在管道和查询不停止的情况下进行处理，排除允许任何向后不兼容的破坏性变更的可能性。

在写入上游数据源时验证模式有助于缓解这个问题，但是由于沃尔玛中很大一部分流数据是使用 JSON 编码的“代码模式”，迁移路径将很长。 由于可能发生不支持的模式变更、对运维（工具和监控）的投入、以及对数据所有者的培训以及对上游授权的长期投资，沃尔玛的消息来源坚持通过统一模式管理更改注册表。

出于同样的原因，所有 Lakehouse 表格式仅支持向后兼容，以支持未来进行重大更改。表格式架构更改很少见，但读取端可能需要在迁移表之前进行升级。

引擎支持

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

架构与设计

性能的改进是沃尔玛着手研究表格格式变化的主要原因。 Hudi、Delta 和 Iceberg 都以性能为中心，虽然如下表所示每种系统方法存在差异，但它们的功能可以分为并发、统计、索引、托管和重组。

性能

获胜者：Apache Hudi

摄取性能

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

WL2 模式已成为沃尔玛维持对有界操作数据集上的低延迟数据湖表的业务需求的关键模式

所有测试构建了完全隔离的环境，以避免互相影响。 然后部署每个摄取作业（Delta、Hudi、Iceberg、Legacy）并留出足够的时间达到稳定状态。 中值批摄取时间是在一组合理的批次 (n > 30) 上测量的，并在所有摄取核心之间进行归一化以确定加权分数 [时间 * GB 摄取] / 核心（最低分数最好）。 执行压缩时，通过使用外部 Spark 应用程序异步执行或在内部作为内联（阻塞）隔离压缩，并从压缩阶段进行测量，从而计算出与标准摄取类似的指标。

WL1 的结果表明，与现有的 ORC 处理管道相比，摄取性能显着提高，性能加速超过 5 倍，性能最高的是运行在 Spark 3.x 上的 Hudi。 对于 WL2 流摄取性能在 Delta 上快了 27%，但是 Hudi 的压缩速度显着加快，因为应用程序执行压缩并且缺少在 Delta 管道中执行的 Z-Ordering（在测试时 Hudi 尚不支持异步排序）。 这种额外的效率使 Delta 中的查询性能显着提高了查询性能。

Delta WL2 模式——摄取困难

摄取作业——由目标分区文件和要处理的记录的全局混洗组成——150 核（6 小时以上且未完成）

Reader 具有干净紧凑的数据视图（无需合并日志以进行实时查看）但是随着基数的增加，合并变得更加昂贵

由于全局洗牌的成本和不断增长的数据大小，Delta 写入无法有效地处理数据。 我们尝试了一种替代架构来将数据附加到表中并运行后台（异步 - 非阻塞压缩）但是 Delta 的架构下这些操作并不能成功完成。

摄取作业——由 2 个作业组成，一个仅附加流作业和一个异步 cron 计划压缩。 由于多个写入端修改相同的文件而失败。

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

Hudi WL2模式

在测试中具有同步或后台压缩的 Hudi MOR（读取时合并）表是唯一能够处理这种模式的开放文件格式，确保最新的写入和清理的视图可供数据消费者使用。

摄取作业——具有文件组映射的行键，降低了连接操作的复杂性——150 核（~15 分钟批处理/50 分钟压缩）

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

查询性能

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

• 表数
• 聚合分区计数
• 主键计数
• 计算基于分区的主键
• 基于主键查询
• 基于主键和分区的查询
• 基于数据集字段查询
• 基于数据集字段和分区的查询
• 主键上的 2 表连接
• 主键上的 3 表连接

尽管 Delta 在大多数查询中有大约 40% 的最佳性能，但在将交易实时数据之上的 Delta 视图与 Hudi RT 视图进行比较时情况不同，其中 Hudi 在提供去重（最新记录视图）方面明显更快。 Delta 的一个显着性能优势在于记录的 ZOrdering，这可以加速表中的大多数查询。ZOrdering 现在可用于 Hudi 以及文件组元数据管理方面的改进。 这将使基准更加接近。

图 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