沃尔玛团队强烈希望扩展近乎实时的决策制定，如事件驱动架构的显着增加、来自生产数据库的变更数据捕获 (CDC、ML 和计算机视觉服务，所有这些都导致了大表新的查询模式。 由于复杂的拓扑结构、事件的速度、 数据种类繁多，模式快速变化。
由于将数据从一种格式迁移到另一种格式的计算和开发人员时间成本很高，因此所选择的指南和方向将产生多年的重大影响。 为了减少所有未来已知和未知的风险，沃尔玛保持对支持的格式和运行时的所有方面的全面控制至关重要，确保在跨沃尔玛和公共云运行时根据需要灵活地维护、修补、升级和扩展框架，以及生态系统中的所有查询加速层。 这导致我们只选择开源格式，以确保沃尔玛能够维护和贡献。
- 在多云环境中摄取/查询两个关键工作负载的性能。 WL1（工作负载 1）无限时间分区数据，由于数据延迟到达，具有显着扇出，< 0.1% 更新，> 99.9% 插入和 WL2（工作负载 2）主要有界基数，未分区数据写入 > 99.999% 更新，< 0.001% 插入
- 对底层设计选择和架构评审的权衡
- 与其他财富 500 强公司的行业专家和技术领导进行讨论
从这项工作中，考虑到系统特征创建了一个加权分数矩阵：
- 可用性 [3]、可恢复性和可移植性
- 与不同版本的 Spark、执行和查询引擎的兼容性 [3]
- 沃尔玛真实世界数据集上每单位工作的成本 [3]
- 摄取、查询、可调优的性能[2]，合理默认值、迁移现有数据成本
- 产品开发路线图 [2] 以及沃尔玛的贡献和影响能力
- 支持 [2]，产品、文档和部署控制的稳定性
- TCO [3]，基于工作成本和内部管理因素
兼容性
获胜者：Apache Hudi
模式演变和验证
Lakehouse 平台在写入时强制执行模式以缓解读取兼容性问题，从而避免将发现和报告错误的责任放在消费系统上。 此外如果在读取发现故障之前写入了大量数据，则可能会导致数据丢失和/或昂贵且耗时的恢复。 通过在写入时验证模式，Hudi、Delta 和 Iceberg 消除了大部分数据不兼容问题，但 Lakehouse 写入端仍然需要处理来自上游数据源的无效和不可映射的模式。 许多这些上游模式问题无法通过 Lakehouse 格式来解决，需要通过灵活的模式管理或对上游源强制执行模式演化规则来全面解决。
在写入上游数据源时验证模式有助于缓解这个问题，但是由于沃尔玛中很大一部分流数据是使用 JSON 编码的“代码模式”，迁移路径将很长。 由于可能发生不支持的模式变更、对运维（工具和监控）的投入、以及对数据所有者的培训以及对上游授权的长期投资，沃尔玛的消息来源坚持通过统一模式管理更改注册表。
引擎支持
沃尔玛数据使用多种引擎进行查询：Hive 和 Spark、Presto / Trino、BigQuery 和 Flink。 支持这些引擎的本地读取/写入端对于减少现有客户迁移到新 Lakehouse 非常重要。 此表列出了沃尔玛使用引擎的程度以及每个产品对该引擎的支持。
架构与设计
性能
摄取性能
批处理和流式摄取基准测试在两个难以满足业务延迟 SLA 的真实世界工作负载上执行。 这两个关键的内部工作负载被称为 WL1 和 WL2。 WL1（批处理）是一个典型的基于时间的表，按年、月、日、小时分区，并且存在大量延迟到达的记录，导致 Spark 摄取在许多分区中遭受显着的读/写放大。 没有分区的 WL2（流式传输）维护行级更新到有界数据集，低延迟数据通过从多 Cassandra 表捕获更改数据。
5 倍，性能最高的是运行在 Spark 3.x 上的 Hudi。 对于 WL2 流摄取性能在 Delta 上快了 27%，但是 Hudi 的压缩速度显着加快，因为应用程序执行压缩并且缺少在 Delta 管道中执行的 Z-Ordering（在测试时 Hudi 尚不支持异步排序）。 这种额外的效率使 Delta 中的查询性能显着提高了查询性能。
Delta WL2 模式——摄取困难
摄取作业——由目标分区文件和要处理的记录的全局混洗组成——150 核（6 小时以上且未完成）
Reader 具有干净紧凑的数据视图（无需合并日志以进行实时查看）但是随着基数的增加，合并变得更加昂贵
摄取作业——由 2 个作业组成，一个仅附加流作业和一个异步 cron 计划压缩。 由于多个写入端修改相同的文件而失败。
Reader 通过读取重复项并在数据上应用窗口来消除重复记录。
Hudi WL2模式
摄取作业——具有文件组映射的行键，降低了连接操作的复杂性——150 核（~15 分钟批处理/50 分钟压缩）
Reader——可以选择压缩（避免更改日志视图）或性能较慢的实时视图。 定期压缩将日志合并到各自的文件组中
查询性能
- 表数
- 聚合分区计数
- 主键计数
- 计算基于分区的主键
- 基于主键查询
- 基于主键和分区的查询
- 基于数据集字段查询
- 基于数据集字段和分区的查询
- 主键上的 2 表连接
- 主键上的 3 表连接
图 3 和图 4 是对所测试的三种 Lakehouse 技术的查询和摄取性能的总结。 需要考虑的是，Hudi 通过比 Delta 更复杂的配置提供了显着的性能优化。 在我们测试时，“开箱即用”的 Delta 默认配置得到了显着优化，并且需要更少的框架知识。
总体而言
根据沃尔玛的调研，考虑到在可用性、兼容性、成本、性能、路线图、支持和 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