万字长文揭秘如何衡量云数据平台 ETL 性价比

由于数千家公司花费了数十亿美元，因此在评估和选择云数据平台（无论是数据湖仓一体还是数据仓库平台）时，性价比[1]至关重要。提取/转换/加载 （ETL） 工作负载占云支出的 50% 以上[2]，用于提取、准备数据并将其转换为数据模型（雪花模式、星型模式等），用于下游分析、商业智能、数据科学、机器学习等。无论团队是深度投入还是对云数据平台的成本控制越来越感兴趣，了解 ETL 性价比对于成功都至关重要。

在本博客中，我们重点介绍了当今标准基准测试规范和工具中的差距，这些差距使企业难以准确建模其 ETL 工作负载并衡量跨平台或供应商的总拥有成本[3]。特别是大多数基准测试方法尚未赶上围绕数据湖仓一体、开放表格式和流数据兴起的云数据格局的变化。因此由于无法更好地了解这些新兴的工作负载模式，他们严重低估了 L （Load） 的成本。我们提供了对这些模式的深入见解，以及可用于计算市场上不同数据平台成本的实用工具和方法。我们提供了一个计算器，可以使用它来对工作负载进行建模，以了解流行的 ETL 数据平台（如 AWS EMR、Databricks 和 Snowflake）在 TCO 方面的表现。

性价比对于当今的数据平台来说更为重要

在过去几年中，云数据生态系统在基础设施、技术和架构方面发生了巨大转变。总之这些变化模糊了数据平台之间的界限，现在可以将存储数据的方式（开放文件和表格式）、管理数据的方式（开放和封闭表维护服务）以及使用数据的方式（查询引擎、数据科学笔记本、优秀的 BI 平台）分离。查看我们的深入探讨博客，比较分析[4]、数据科学和机器学习[5]以及流处理[6]引擎，这些博客展示了自由选择可以为组织节省成本和灵活性。 但是每个方面都存在一些挑战。云成本控制可能是一把双刃剑（基础设施）： 由于数据的快速创新和爆炸式增长，云已成为数据平台的首选基础设施，高达 65%[7] 的公司拥有混合本地和云部署。虽然云提供了一些出色的新功能（例如，弹性按需扩展、基于使用量的计费、解耦计算、廉价存储），但选择合适的引擎也可能令人生畏，与“付费”本地数据基础设施相比，即使由于过度配置而导致 10-20% 的效率低下也可能使公司损失数百万美元。

数据湖仓一体是对传统数据湖（技术）的代际升级 ：Apache Hudi™ 和 Delta Lake 等数据湖仓一体存储框架的出现将基于文件的数据湖迁移到管理更完善的表，具有类似数据库的功能，包括 ACID 事务、更新、删除、时间旅行和变更数据捕获。这些功能还需要更多的计算资源。例如将增量合并到表中的成本可能比通过写入新文件插入记录的成本高 10 倍。因此根据这些方面对工作负载进行建模对于保持在预算范围内至关重要，本博客指出了当前基准测试工具未捕获的因素。

开放表格式正在使开放数据成为数据仓库的主流（体系结构）： 像 Apache Iceberg 这样的开放表格式的出现可能是数据仓库这十年来最令人兴奋的更新。然而大多数云仓库仅将它们视为“开放元数据”（例如 Apache Iceberg™）来读取/写入“开放数据”（例如 Apache Parquet™），并没有从根本上改变仓库的计算强度和限制。例如，仓库首次满足流数据的规模，并且主要在很少更新的假设下运行。本博客指出，当前大多数供应商关于衡量 ETL 性价比的工具都达不到要求，最终可能导致用户因将仓库用于错误的工作负载而超支。

总而言之，我们应该用一种可重复且现实的方法来衡量和建模 ETL 成本，而不会出现历史妥协，例如牺牲 ETL 可扩展性来换取数据仓库的查询速度。否则，用户支付的费用可能与供应商的概念验证显示的内容大不相同。

理想的 ETL 基准测试

要理解为 ETL 设计理想的基准测试框架的问题，我们需要分解在三个阶段（提取、转换和加载）执行的工作，并解开这些工作负载的特征。 提取 （E） 处理受 I/O 限制，因为它通常涉及从对象存储读取文件，但数据可能从 Kafka 或数据库等其他来源摄取。转换（如联接和聚合）更多地受计算限制（实际转换逻辑的 CPU 周期）和网络限制（在处理更改期间交换数据）。尽管 E-T 阶段是独立的，但 E-T 阶段是耦合的，因为查询计划程序可以应用特定的优化规则，这些规则可能会影响需要读取的数据量，从而影响 E 和 T 的性能。 例如在联接三个表时，表的联接顺序可能会对从输入表中扫描的数据量和为联接处理的数据量产生显著差异。另一方面， L 处理的 I/O 强度更高，并且与 ET 解耦。L 处理的效率取决于目标表的大小和传入记录的更新模式等因素。

‍

图：一个示例 ETL 管道，该管道联接两个表，聚合数据，然后与第三个表联接，然后写入目标表。

很多时候，我们将 ETL 性能简单地等同于 SQL 查询性能。这种简化无法捕获 ETL 工作负载的独特性能特征。理想情况下，我们的基准测试方法和工具应满足以下要求，以确保基准测试结果在应用于实际工作负载时保持相关性。

A） 跨运行增量提取

在过去几年中，用户已稳步从每日快照转储或批量摄取流程转向通过从源系统捕获变更数据进行更实时的数据集成。这种转变还影响了下游 ETL 在数据平台内处理数据的预期方式。毕竟，如果 ETL 管道每天或每天处理几次数据，那么近乎实时地摄取数据并不是很有用。Apache Hudi™ 或 Delta Lake 等数据湖仓一体项目以及 Snowflake 和 Google BigQuery 等云仓库公开了具有不同功能级别的变更流，以快速识别云数据平台中的变更数据，这与关系数据库非常相似。

理想的基准测试框架还应该明确测试在 ETL 运行之间一遍又一遍地“重新处理”了多少数据，以及使用列统计或区域映射等技术修剪要扫描的数据的效率。

B） 转变速度

这是 ETL 基准测试中一个广为人知但经常被忽视的方面，我们通常基于用户提供的 SQL 来衡量提取的数据转换为输出记录的速度。理想的基准测试应该测试不同的转换以及连接和聚合作的顺序，以生成这种转换后的输出。

C） 记录级删除

随着 GDPR 和 CCPA 等合规性要求的发展，删除数据的能力对企业来说变得至关重要。数据平台中围绕合规性要求的常见挑战包括快速识别要删除的记录的位置（大海捞针）到有效地从实际存储或表中清除记录。这些要求通常是正常增量加载之外的批量删除作。

理想的基准测试应独立于增量加载来执行这些删除请求，增量加载往往更侧重于使目标表与源表中的更改保持同步。

D） 表优化费用

ETL 管道写入数据，每次写入更改表状态时，都可能需要进行簿记（例如，使较旧的快照过期）或优化，以确保未来的 ETL 和查询性能（例如，及时压缩 ETL 管道写入的一堆小文件以进行查询）。在对延迟合并存储技术（例如读取时合并）进行基准测试时，这一点变得极其重要，这些技术在写入时使用差分数据结构（例如 Hudi 的日志文件或 Delta Lake 的删除向量）并延迟合并，直到用户查询表。

基准测试应了解这些细微差别，并在相关时包括表优化成本。

E） 具有真实更新/删除模式的增量加载

数据在变化，在许多公司中，数据变化迅速而频繁。例如，将数据从作系统实时摄取到云数据平台需要 ETL 管道来跟上源运营数据库所服务的艰难更新模式。然而许多数据仓库都是围绕数据不可变这一失败的概念而设计的。数据湖仓一体项目正面挑战了这一点，即使命名了 Hudi 和 Delta Lake。更新和删除现在是现代数据平台的主流考虑因素。数据湖已经从仅追加文件存储发展到可变表，Apache Iceberg™ 等开放表格式将更新处理纳入其 V2 规范。

任何有价值的 ETL 基准测试都应该考虑数据湖仓一体中出现的这些真实世界的更新模式。如果不这样做，可能会严重限制基准测试作为最终平台成本指标的有用性，因为目前大多数数据处理都使用数据湖仓一体存储（Hudi、Delta Lake）和计算（Apache Spark、Apache Flink）框架进行。

F） 事件流数据的规模

数据处理的另一个关键趋势是对事件数据的流处理的兴起。微服务通常会生成事件数据以响应业务事件，并且规模甚至可能比数据仓库中使用的最大事实表大 10 倍。例如，虽然大型事实表可以存储 Amazon.com 上的所有订单，但更大的事件表可以存储网站上每个订单的所有用户点击/交互。随着实时捕获和分析数据的需求不断增加，企业为批处理和流式 ETL 工作负载维护不同的系统变得很麻烦。由于高容量和低延迟要求，处理此类事件数据通常具有挑战性。

基准测试应捕获这些方面，并包含反映事件表的相对缩放因子的表以及现有事实/维度表。理想情况下，基准测试应反映 ETL 管道的延迟要求，并测试仓库或湖仓一体集群是否可以实现所需的数据新鲜度。

G） 并发下的吞吐量

今天的云平台是动态的。除了不断引入数据的增量负载之外，还有大量后台进程正在读取、修改记录并将其写回表中。例如可能有一个对要删除的记录强制执行 SLA 的合规性服务，一个通过计算列的历史值来写入新列的回填过程，或者一个只是重写数据以轮换加密密钥的进程。

基准测试应模拟这些并发进程，并能够报告此类条件下的工作负载吞吐量。鉴于当今大多数数据平台都乐观[8]地假设不存在争用，这一点尤其重要。这类似于 TPC-C 基准测试规范的创建方式，以捕获数据库的技术进步，而不是 TPC-A/B 等更简单的基准测试。我们需要一个用于 ETL 工作负载的基准测试框架。

深入了解标准行业基准

在 Onehouse，我们与客户密切合作，以了解他们的 ETL 工作负载特征、性能瓶颈和成本。无论是提供定价估算还是跨工作负载模式对我们的平台进行基准测试，我们都花费了大量时间和资源来评估 ETL 工作负载的不同基准和工具。在本节中，我们将讨论业内一些使用最广泛的基准和评估方法，重点介绍它们在上述要求中的优势和局限性。

TPC-DS，加载 （L） 一次并运行查询 （ET）

TPC-DS 规范[9]是评估 OLAP 系统使用最广泛的基准数据集，基于报告[10]的官方结果数量和众多博客的引用。TPC-DS 是作为 TPC-H 的继任者设计的[11]，经过多项改进以匹配 OLAP 平台的技术进步。

• • 具有共享维度表的多个 Snowflake 架构。复杂的表关系使用 I/O 吞吐量密集型联接和涉及较小表的小型随机 I/O 联接对系统进行压力测试。
• • 具有更多列的表数量越多（平均 18 个），则允许使用多个谓词创建更丰富的查询集。
• • 对非事实表进行更具代表性的倾斜次线性扩展，以准确模拟现实世界，其中客户的增长速度通常慢于交易。
• • 临时、报告和迭代查询的组合，有效地执行底层引擎的一系列运算符（扫描、连接、聚合等）和查询优化（连接重新排序、连接前 Bloom 过滤等）。

TPC-DS 是 OLAP 系统的 E 和 T 处理基准测试和压力测试的全面工具。如果底层引擎采用矢量化执行，它可以捕获转换作（如联接和聚合）的 CPU 加速[12]，同时还可以捕获基于规则的优化[13]，如动态分区修剪、布隆过滤器联接等，以帮助扫描和处理更少的数据。

不足之处

tpc-ds 的一个严重错误但遗憾的是普遍的用法是将其用作 ETL 工作负载的基准，只需执行初始加载[14]（L），然后运行几轮 99 个查询来衡量性能。99 查询本身不会写入或加载任何数据。由于以下原因，此方法充满了[15]不准确之处。

• • 由于它不执行常规增量加载，因此此测试不会测量有关 L 性能的任何内容。
• • 数据库、仓库和湖仓一体都有不同的初始批量加载和增量加载机制。即使在初始加载中，也存在多种方法（已排序与未排序）。如果不正确对齐，即使是查询性能数据也无法在不同的测试系统中直接比较。

具有数据维护功能的 TPC-DS

TPC-DS 规范[16]将“数据维护”定义为可能与 ETL 工作负载相关的增量加载的首批行业标准定义之一。数据维护运行[17]表示来自多个平面文件的数据的集成和转换，以及从目标系统中删除过时的数据。所有非静态表（包括 26 个表中的 20 个）都有更新。维度表具有 SCD 类型的更新，具有两个必需的选项：维护每条记录的历史记录日志和非历史记录版本，其中每条记录都使用最新版本记录中的值进行更新。需要这两种类型的 history 选项将测试系统的[18]插入和更新。事实数据表仅包含插入（新）记录，但会频繁清除或删除特定记录。

不足之处

TPC-DS 的数据维护不足以真正用于 ETL 基准测试的原因有多种：

• • 有限的记录更新量 ：只有维度表对现有记录有更新。事实数据表只能删除[19]现有记录，不能进行更新。根据我们的经验，以及从几家公司（例如 Amazon[20]、Stripe[21]、Walmart[22]）的生产中广泛报道，ETL 工作负载包含事实表、 维度表和事件表的组合。很大一部分事实表通常具有中到高更新量，而事件表主要是出于合规性原因需要删除记录而插入的（例如，Zoom[23]）。
• • 单一更新和删除模式 ：规范不提供混合模式。维度表的更新是通过数据生成在现有记录中随机生成的。事实表的删除[24]和插入在逻辑上是集群的。将为随机生成的日期范围内的记录生成删除作。这可能会有效地测试 drop 分区的性能，但可能不会对系统删除一个或多个文件中的记录的能力进行压力测试（大海捞针问题）。更新或删除记录的分配模式可能会对性能和成本产生重大影响（例如，Uber[25]、Affirm[26]）。

从另一个 TPC 基准测试中可以更容易地理解这个关键限制。在 OLTP 世界中，TPC-C 模拟[27]了均匀和倾斜的数据访问（例如，80% 的访问是对 20% 的数据的访问）。创建热点会增加对特定行或页面的争用。这强调了锁定、事务和缓冲区管理，为 OLTP 系统提供了一个具有挑战性和代表性的基准。TPC-DS 数据维护还需要包含不同的更新和删除模式，这些模式可能会对 OLAP 世界中的并发控制机制造成压力。

LST 工作台

最近，Microsoft 的团队提出了 LST-Bench[28] 框架，以有效地评估日志结构表 （LST），例如 Hudi、Delta Lake 和 Iceberg。它们解决了当前 TPC-DS 数据维护框架的不灵活性，以及现代数据湖平台的寿命、弹性、并发性和时间旅行查询模式等不同方面。TPC-DS 框架有一个定义明确的步骤序列：加载数据、单个用户查询、多个查询（吞吐量测试），然后是数据维护和重复。

• • LST-Bench 解决了测试平台使用寿命的问题，以使用一组可配置的阶段而不是明确定义的步骤来始终提供相同的性能。这有助于测量在对表执行定期更新时的性能下降。
• • 要测试弹性，可以在测量表的查询性能之前测试改变数据作的轮数。
• • LST-Bench 还允许在一个阶段内并行运行任务，因为许多现代数据湖都运行后台任务，例如压缩，以处理数据。同时，正在查询或写入数据集。
• • 最后LST-Bench 允许用户执行时间旅行查询，该查询在表的特定时间点快照上运行查询。

不足之处

LST-Bench 强化了我们关于当今数据湖中数据加载的演变和复杂性的观点，并通过使 TPC-DS 更具可配置性来衡量性能，填补了一个关键空白。虽然这是朝着正确方向迈出的一步，但该工具仍然存在与 TPC-DS 数据维护相同的潜在问题。如前所述，TPC-DS 数据集的主要限制是缺乏不同更新模式的混合和有限的更新工作负载，因为只有维度表有更新，并且完全没有事件规模的表。用于加载 LST-Bench 提供的数据的 SQL 脚本[29]仅对所有表执行删除作，并且不会为现有记录生成任何更新。

TPC-DI 系列

TPC-DI[30] 是第一个用于对数据集成 （DI） 系统（包括 ETL 工作负载）进行基准测试的标准基准数据集。TPC-DI 对 TPC-DS 数据维护所做的最大改进[31]是增加了对生成更新记录和定义被测系统生成结果的一致性审计的支持。TPC-DI 解决的最大挑战之一是根据先前的表写入历史记录生成正确的更新。与删除不同，更新必须在初始插入/更新后写入为具有正确状态的完整记录，并且不能为已删除的记录生成。对 PDGF 数据生成[32]工具进行了适当的更改，以支持一致的更新。TPC-DI 规范还包括类似于 TPC-DS 的转换类型、聚合作和数据类型转换的组合。Databricks 使用它来比较[33]增量实时表 （DLT） 的性能与其非 DLT 产品作为基准。Databricks 还发布了一个生成 TPC-DI 数据集的工具[34]，包括在 DLT 上运行基准测试的历史和增量 SQL。

不足之处

从理论上讲，TPC-DI 听起来非常令人兴奋，自然而然地，我们花了大量时间评估 TPC-DI 架构，因为它最有希望捕获 ETL 工作负载特征。不幸的是，尽管我们发现这是一个很好的起点，但它与我们所需的理想基准相去甚远，原因如下。

• • 从维度表派生事实表会使工作负载不切实际且僵化： 通常，FACT 表不是从 DIM 表中加载的。相反，下游查询和流联接 FACT 和 DIM 表，因为 DIM 表通常提供相关上下文。该规范使得很难使用比例因子独立配置 FACT 和 DIM 表上的增量插入[35]（新记录）和更新负载。TPC-DS 规范相对于 TPC-H 的主要改进[36]之一是使 FACT 表随比例因子线性增长，而 DIM 表则次线性增长，以使数据集更真实。
• • 其中一个事实表对整体性能的影响不成比例，但只有 4 列 ：在数据集的 10 多个表中，只有 3 个表包含足以影响整体性能的更新。在 5-6 个 FACT 表中，只有 FactWatches[37] 有更新，在我们对 3 个平台的测试中，我们看到处理 FactWatches 增量负载的延迟可能占总延迟的 30-40%。FactWatches 表的架构只有五列，包括两个主键和一个布尔类型。但是，TPC-DS 将平均列数增加到[38]18 列，而 TPC-C 数据集增加了架构的复杂性[39]，平均为 10 列，以更好地模拟真实的表。
• • 简化的更新和删除模式 ：唯一可用的旋钮是增加增量加载的更新：插入比率，这些增量加载可能无法对基于 ACID 的湖进行充分的压力测试。例如，TPC-C 通过混合事务为 OLTP 事务增加了复杂性[40]，每个事务都经过建模以执行在底层系统上执行的不同工作量，包括 I/O 和 CPU 瓶颈。它还在事务中引入了有意的负载变化。虽然很难将 OLTP 数据库和 ACID OLAP 湖的复杂性等同起来，但它确实需要仔细设计更新工作负载，以对现代数据湖进行全面压力测试。
• • TPC-DI 并未广泛用于基准测试 ：尽管它与 ETL 工作负载相关，但我们对 TPC-DI 的批评也得到了以下事实的支持：在撰写本博客时，没有报告 TPC-DI 的性能结果[41]。相比之下，IBM、Oracle、Databricks 和阿里巴巴等大型企业的 TPC-DS 和 TPC-C 的几份性能报告。与 TPC-DS 或 TPC-C 相比，我们发现使用 TPC-DI 进行基准测试的博客或文章要少得多。我们还解决了之前使用该工具报告的数据质量问题的[42]子集。
• • TPC-DI 数据生成工具中的漏洞意味着它没有得到很好的校准 ：删除记录是 TPC-DI 规范的一部分。但是，我们发现官方的 PDGF 数据生成工具将删除记录的 CDC_FLAG硬编码[43]为“U”，并将其标记为更新。比例因子按比例增加历史负载和增量负载，因此很难使用独立于目标表大小的增量负载变化对系统进行压力测试。最后，虽然该工具确实允许我们修改特定表的更新比率，但并非所有表都允许这样做。我们确实意识到这些缺点并不是规范所特有的，但必须指出它们，因为 PDGF 数据生成工具需要符合规范。

当前校准

我们发现，如果根据我们在博客前面列出的要求进行校准，则缺乏当前的行业基准。下表反映了当前状况：现代数据平台对 ETL 工作负载和生态系统中普遍存在的工具的基准测试程度。

简而言之，为了实现我们理想的基准，我们需要一个更新的 TPC 架构，该架构考虑了足够数量的列 / 表和事件表，以及更好地表示真实世界的更新-删除模式。这还必须补充并发的增量历史加载器/回填作业和删除作业。最后，转换 SQL 查询必须进行调整，以生成反映真实场景的更新和删除模式。最后的更改可能是最繁重的，会对基准测试架构和表设计的其他部分产生连锁反应。我们对行业在未来几年朝着这个方向发展持乐观态度。

忽视 L 成本是一个错误

在与 OSS 用户和客户互动时，我们注意到人们普遍缺乏对编写成本 （L） 可能占 ETL 运行时间的 20-50% 的认识。虽然这显然取决于工作负载，但让我们使用公共 TPC-DS 基准测试[45]中的基线数字来解读它。TPC-DS 加载插入所有记录一次，大约需要 2300 秒。运行所有 99 个查询大约需要 4000 秒（数字向下舍入）。

图：显示了基于 ETL 管道模型的 ET 和 L 的细分

仓库和湖仓一体通常运行批处理 ETL 流程，这些流程对所有或部分源表重复相同的 ET 转换，并在目标表中执行 INSERT OVERWRITE。这与 TPC-DS 初始载荷非常相似。另一种典型模式是使用 MERGE INTO 作将全部或部分源表与目标表合并，该作可有效读取目标表的某些部分，联接或转换以计算记录的新值，并有效地重写目标表的不同部分。通过读取、修改和重写整个表将更改合并到表中的“ 完全合并” 通常至少需要 2.3 倍（1 倍写入、1 倍读取和 0.3 倍之间随机排序）的成本是我们实证实验中插入的成本。

使用 ET 和 L 的基准成本，并根据 MERGE INTO 影响的表部分按比例缩放 L 成本，我们可以估计 ET 与 L 的总细分可能是什么样子。具体来说，我们将 INSERT OVERWRITE L 成本建模为与 TPC-DS 完整插入相同，将 MERGE INTO L 成本建模为完整合并成本的一部分。例如，如果 ETL 重写 10% 的表，则其成本为 0.1（表更改的比例）x 2.3（合并成本因子）x 2,300（基准 TPC-DS 插入成本）。 上图显示了这些管道类型的大致估计值，以强调为什么在衡量数据管道的成本时必须仔细考虑 ET 和 L 的细分。在接下来的部分中，我们将更深入地研究 ETL 管道的 L 阶段，并帮助更真实地对管道的这一部分进行建模，同时还要考虑事件表和不同的更新和删除模式。

了解实际负载 （L） 模式

我们强调了这些行业基准中缺乏现实的更新和删除模式，以及普遍缺乏对数据可变性的关注。对于 update 和 delete 模式，我们广泛地指针对受测表生成的增量负载中的以下特征。

• • 更新比率 ：更新与插入的比率会显著影响需要扫描以查找记录位置和写入放大的文件数，具体取决于需要重写的文件数。
• • 更新行分布 ：扫描和重写的文件数也可能受到给定表中更新分布[46]的影响。例如，对最近插入的数据的更新与 Zipf 分布[47]与随机更新的均匀分布的更新对于 MERGE/DELETE 作可能具有非常不同的性能配置文件。
• • 更新列分布 ： 跨所有列（而不是选择性列）的更新对 I/O 性能的影响可能非常不同。
• • 记录数和记录大小 ：在使用索引的系统中，索引开销取决于相对于给定表大小的记录数。因此，具有相同存储大小的两个表的不同记录数可能具有不同的更新/删除性能。

来源：Dremio 调查，2025 年 1 月

在本节中，我们通过一系列分析，使用来自不同数据湖仓一体和开放表格式 OSS 项目的真实数据量化了这一点，这些项目已经存在了至少 5+ 年，背后有大型社区支持，并在全行业范围内进行了大规模采用。

我们分析了这三个主要项目中提到 “sql” 的 GitHub 问题，并进一步研究了不同的写入作 - append （INSERT INTO） 与可变 （MERGE/DELETE/UPDATE） - 是如何相对分布的。值得注意的是，Iceberg/Delta Lake 使用 GitHub Issues 进行开发任务跟踪和用户支持，而 Hudi 主要使用 GitHub Issues 进行 OSS 支持，解决了 2700 多个问题。但是，不同项目的数据分布具有明显的可比性。该研究指出，与追加作相比，可变作在用例中是如何均匀分配的。 对于关注数据湖仓一体技术发展的读者来说，希望这并不奇怪，而只是重申了工作负载向可变数据模型的转变是一个真实的现象。

图：围绕 Hudi、Delta Lake 和 Iceberg 的 SQL 作的 GitHub 问题分析。

我们注意到 Onehouse 上所有活动表和流的 append 和 mutable writes 之间也有类似的拆分。我们分析了 Onehouse 管理的顶级表，总计超过 1 PB，以了解并确认这些模式是否持续存在。可变写入在每次写入中影响或重写的文件数以及更新涉及的分区数方面进一步变化。进一步深入研究，Top 表被划分为以下具体写入模式。

• • 更新/删除较少的大型事件表表示 “append” 写入作。（表 A、C、D）
• • 大量更新的维度表（表 E），随机分布在整个表中，涉及表中很大一部分文件/分区。这相当于 table 被多次重写以处理更新。
• • 具有大量更新但分布偏斜的事实表，显示写入放大率低于我们对更新比率的预期（表 H）
• • 某些事实表和维度表具有适度的更新比率（表 B、F、I）。但是，这些更新分布在许多分区中，从而导致 MERGE 作的读/写放大率很高。

总之，来自 OSS 社区的数据与 Onehouse 平台使用数据相吻合，即使在我们的样本量不大的情况下也是如此。它强调了需要仔细处理跨表类型（如 dimension、fact 和 event）的可变写入模式。在下面的部分中，我们将使用来自实际数据湖仓一体用户的数据进一步加强这一点，并提炼出关键写入模式，这将有助于我们更好地衡量 ETL 成本。

描述 Load 工作负载的特征

从这些数据点和讨论中得出了三种明确的数据加载模式： 具有统一更新的 DIM 表、具有 Zipfian 更新的 FACT 表和具有插入 + 删除的 EVENT 表 — 在传统数据仓库和现代湖仓一体中。如果这些工作负载分布听起来很熟悉，那是因为它们也被用于成熟的 YCSB NoSQL 数据库基准测试[48]中，这些基准测试显示了这些模式如何反映真实的访问模式。下面我们松散地使用术语 “files” 和 “partitions” 来指代受写入影响的表部分。它们还可以引用仓库中的微分区[49]（如 Snowflake）或湖仓一体存储中的文件组[50]（如 Apache Hudi）。此外这些模式不一定是刚性的，而只是捕获影响这些表性能的因素。例如，维度表也像事件表一样接收随机删除，但只是遵循与随机更新相同的模式。

具有统一更新的 DIM 表

DIM 表或维度表通常表示参考数据，例如用户配置文件或产品目录。这些表通常大小为中小型，可能是未分区的，并且经常以统一、随机的模式更新。随着时间的推移，这种访问模式会触及数据集中的各种文件，这使得处理更新特别具有挑战性且成本高昂。这通常会导致对传统仓库和大多数数据湖仓一体中的大型数据集进行昂贵的合并作。

图：显示维度表中各个文件的随机更新（黄色），遵循均匀分布[51].

实际示例包括 Salesforce/Delta Lake[52]、Uber/Apache Hudi[53]、NerdWallet/Apache Hudi[54]。

具有 zipfian 更新的 FACT 表

FACT 表更大，通常是 DIM 表大小的 10 倍，并且通常按基于时间的键（如 event_date）进行分区。这些表经历了 Zipfian 分布式更新 ，其中大多数写入和更新都针对最近的分区，但大量延迟到达的数据向后分布在数十个或数百个较旧的分区中。

图：显示最近分区的插入（绿色）/更新（黄色），以及 Zipfian 分布之后对旧分区的少量更新（黄色）。

实际示例包括 Affirm/Iceberg[55]、Amazon/Hudi[56]、Walmart/Hudi[57]。

金融交易记录需要更新状态转换，其中大部分发生在启动的最初几天（Stripe 分类账设计[58]）。各行各业的大规模产品都会遇到数据延迟到达的情况，这通常是由于产品的性质、更正或暂时性网络问题，从而导致最近分区上的高权重的倾斜更新。在开源数据社区（Iceberg[59] 和 Apache Doris[60] GitHub 问题）中提出的性能问题报告或功能差距表明，具有时间偏差的更新工作负载是数据工程从业者必须面对的一个真实而重要的问题。BigQuery[61]、Databricks[62] 和 Snowflake[63] 等供应商提供了一些关于这些场景的指南和文档，进一步为这种模式在整个行业中的普遍性奠定了基础。

具有插入 + 零星删除的 EVENT 表

EVENT 表是最大的类，通常比 FACT 表大 10 倍，并且通常仅追加。这些表示大量日志或遥测数据，例如点击流、传感器数据或金融交易。虽然大多数写入是纯附加，但有些需要重复数据删除或罕见的删除（例如，GDPR 合规性）。这些工作负载需要超高效的摄取管道，这些管道可以处理数十亿个事件，延迟为毫秒级。在许多情况下，append workload 会捕获传入的事件流或日志数据，通常用作奖章架构[64]的铜牌层。

图：一个大型事件表，它只获取对最近分区的插入（绿色），但可以在整个表中获取随机删除（红色）。

实际示例包括：Spotify[65]、Zoom/Apache Hudi[66]、 Adobe/Delta Lake/Iceberg[67]。

自 GDPR 和 CCPA 等隐私法颁布以来，从数据存储中删除客户记录变得至关重要。在大多数情况下，公司必须在客户提出删除请求后的特定时间窗口内删除个人身份信息 （PII）。为了满足这些要求，必须从多个表（包括大型事件表）中删除一小部分随机记录。这种记录级删除模式在数百 TB 的事件数据生产中带来了独特的挑战。

开源 Lake LoaderTM - 用于对增量负载进行基准测试的工具

今天，我们开源了一个新工具 – Lake Loader[68]TM – 多年来我们一直成功地使用它来模拟这些真实的写入模式。该工具可以将负载模式的各个方面作为输入 - 记录数量、分区数量、记录大小、更新插入比率、插入和更新在分区之间的分布以及要执行的增量加载的总轮数。它是一个独立的工具，由两个主要组件组成。

1. 1. 更改数据生成器 ：此组件采用指定的 L 模式并生成多轮输入。每个输入轮次都有更改记录，这些记录可以是前一输入轮次中的插入或对插入的更新。
2. 2. 增量加载器 ：加载器组件实施了使用 AWS EMR、Databricks 和 Snowflake 等流行的云数据平台将数据加载到各种开放表格式的最佳实践。第 0 轮专门设计用于使用数据平台的首选批量加载方法执行一次性批量加载。第 1 轮及以上版本仅使用每轮中预先生成的输入更改记录执行增量加载。

图：显示了 Lake Loader 工具的高级功能，用于对常用云数据平台中的增量负载进行基准测试。

通过将更改记录生成与加载分离，可以针对多个数据平台重复重放相同的更改记录模式，以便进行准确比较。此外，由于支持运行多轮增量加载，用户可以运行基准测试足够长的时间，以确保测量的性能稳定，并对目标表应用足够的更新和插入。这避免了加载基准测试时的常见陷阱，即用户在 1-2 轮写入后停止，即使他们的 ETL 管道在现实世界中日复一日地持续运行。

有意义的基准测试：TPC-DS （ET） + 逼真的 L 模式

我们已经介绍了一些内容 - 阐述了理想的 ETL 基准测试是什么样的，根据它校准了行业标准基准测试/工具，并检查了管道 L 阶段的差距。其中一些空白很深，可能需要一段时间才能填补。但是，在此期间，我们如何评估 ETL 工作负载呢？我们能否根据所学到的知识使用这些标准基准做些什么？我们认为答案是肯定的。

我们提出了一种简单但强大的方法，该方法尽可能多地利用完善的基准测试，同时还添加了一个新的基准测试组件以使其更接近现实。以下是它的大致运作方式。

第 1 步：使用标准 TPC-DS 测量 ET：这为不同的引擎如何采用各种智能提取 （E） 技术、查询规划和优化以及围绕实现选择（例如基于推与拉的处理和随机机制）练习核心转换引擎提供了很好的基准。 通过利用像 TPC-DS 这样久经考验的基准，我们站在巨人的肩膀上，避免了重新发明轮子（目前）。

第 2 步：使用新的 lake-loader OSS 工具测量 L：该工具允许在 DIM、FACT 和 EVENT 表上针对各种云数据平台（如 AWS EMR、Databricks 和 Snowflake）生成不同的模式，如上一节所述。我们欢迎来自社区的贡献和修复。在下图中，* 表示该工具目前不自动支持 DELETE。

第 3 步：使用性能规范化成本： 在你测量了感兴趣的数据平台上的 ET 和 L 后，使用每个数据平台的价格对它们进行标准化。这需要分别用于 ET 和 L 测量，甚至跨不同的 L 模式进行，因为它们不能直接比较。TPC-DS 和 Lake Loader 使用不同的表架构，专为模拟不同的工作负载而构建。由于我们计划只估计相对成本，即一个平台与另一个平台相比的成本/成本，因此在测量组（ET、L-DIM、L-FACT、L-EVENT、L-DELETE）内独立标准化是完全可以的。

为此，我们首先使用每个平台的定价策略确定每个工作负载的运行成本。最常见的是，数据平台采用基于使用量的定价模型（例如，1 USD/小时/集群），如果 ET 运行需要 2400 秒，则成本计算公式为：2400/3600 * 1 USD = 0.67 USD。我们针对每个测量组的每个数据平台执行此作，并在每个组中以从最便宜到最昂贵的数据平台的排名列表结束。我们将成本 1 美元分配给最实惠的和次便宜的相对定价。例如，如果下一个最便宜的系统的成本高出 20%，则它的成本为 1.2 USD。

第 4 步：测量工作负载： 在 Onehouse，我们多年来一直在 OSS 中支持大规模数据湖，并在以前的工作中作了一些实践。这些经验告诉我们，使用基准测试作为方向性指导，同时使用实际工作负载和生产输入对其进行微调。然后，应用这些经验教训，我们测量当前设置上不同测量组的 ETL 工作负载所花费的时间，并确定在每个阶段或测量组中花费的 ETL 管道总时间的比例。将这些计算时间分数与上一节中计算的相对成本进行加权，可以得出所比较的每个数据平台的总相对成本。基本假设是，即使绝对性能数字会有所不同，则 ET 和 L 阶段所花费的时间比例在某种程度上保持一致。该方法偏爱在花费最多计算时间的阶段中性能更好的数据平台。

图：提议的 ETL 基准测试方法

这种务实的方法平衡了 ETL 基准测试中的已知差距与我们拥有和已经信任的差距。为了便于测试此方法，我们为市面上流行的数据平台（AWS EMR[69]、Databricks[70] 和 Snowflake[71]）运行了实际测量，并构建了一个漂亮的计算器供感兴趣的读者探索。ET 测量使用与 Iceberg 和 Delta Lake 相同的物理 1TB TPC-DS 表，使用 Apache XTable™（孵化）提供给这些数据平台。L 测量是通过使用 Lake Loader 运行 DIM、FACT 和 EVENT 工作负载来执行的。这些与配置和脚本一起在 GitHub 存储库中共享，以重现我们的结果。使用下面的计算器，用户可以将他们的工作负载测量值输入到下面的滑块中，并查看它如何影响在这些常用数据平台上运行 ETL 工作负载的相对成本。我们打算在未来几个月内不断改进此计算器。

摘要：构建更好的基准测试

如果负责构建或维护 ETL 管道，那么信息很明确： 不测量就无法优化，而测量会得到修复 。在仓库和湖仓一体中，很明显大多数标准基准测试根本没有对加载数据的现实进行建模：高频更新、事件规模摄取、扭曲突变以及回填、删除和 GDPR 流程的并发性。

这篇博客不仅阐述了 L 相基准测试的重要性，还阐述了当今的工具和规范（如 TPC-DS、TPC-DI 和 LST-Bench）在捕获 ETL 管道的全部性能足迹方面是如何不足的。我们还概述了一种实用的方法，使 ETL 基准测试更加现实和可靠。鉴于在这些工作负载上花费了大量的计算周期和美元账单，我们真诚地希望这可以导致一些长期的努力，以实现真正围绕 ETL 的标准化和专业化基准测试。

我们需要工具来重现真实世界的模式，这就是我们开源 Lake Loader™[72] 的原因：这是一种基准测试工具，可在实际的 DIM、FACT 和 EVENT 表工作负载中模拟随时间推移的增量数据变化。它与 Spark 和 Hudi、Iceberg 和 Delta Lake 等开放表格式即插即用，并支持可重现的 ETL 成本同类比较。借助 Lake Loader可以超越一次性插入，并测量管道每小时、每天、永远运行时的实际情况。

我们才刚刚开始。我们希望：

• 扩展对更多云原生数据平台和执行引擎的支持。

• 使负载生成器更具可配置性、数据类型感知性和可倾斜可调性。

• 尝试将逼真的 L 模式插入修改后的 TPC-DS、TPC-DI 或 LST-Bench 版本中。

• 捕获模拟生产复杂性的时间旅行、压缩和并发负载场景。

引用链接

[1] 性价比:https://en.wikipedia.org/wiki/Price%E2%80%93performance_ratio [2]50% 以上:https://www.linkedin.com/posts/alighodsi_how-we-performed-etl-on-one-billion-records-activity-7053061066888548352-fS2L/ [3]的总拥有成本:https://en.wikipedia.org/wiki/Total_cost_of_ownership [4]分析:https://www.onehouse.ai/blog/apache-spark-vs-clickhouse-vs-presto-vs-starrocks-vs-trino-comparing-analytics-engines [5]数据科学和机器学习:https://www.onehouse.ai/blog/apache-spark-vs-ray-vs-dask-comparing-data-science-machine-learning-engines [6]流处理:https://www.onehouse.ai/blog/apache-spark-structured-streaming-vs-apache-flink-vs-apache-kafka-streams-comparing-stream-processing-engines [7]高达 65%:https://siliconangle.com/2024/07/27/databricks-vs-snowflake-not-zero-sum-game/ [8]都乐观:https://hudi.apache.org/blog/2021/12/16/lakehouse-concurrency-control-are-we-too-optimistic/ [9]TPC-DS 规范:https://www.tpc.org/tpc_documents_current_versions/pdf/tpc-ds_v2.13.0.pdf [10]报告:https://www.tpc.org/tpcds/results/tpcds_results5.asp?version=3 [11]的继任者设计的:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=fe178bd7cb36ad9f7c7449ea2d934b33860bb6b1#:~:text=Another%20distinctive%20characteristic%20of%20the,number%20of%20tables%20and%20columns. [12]CPU 加速:https://www.databricks.com/blog/2022/05/17/reduce-time-to-decision-with-the-databricks-lakehouse-platform-and-latest-intel-3rd-gen-xeon-scalable-processors.html [13]捕获基于规则的优化:https://aws.amazon.com/blogs/big-data/amazon-emr-7-1-runtime-for-apache-spark-and-iceberg-can-run-spark-workloads-2-7-times-faster-than-apache-spark-3-5-1-and-iceberg-1-5-2/ [14]执行初始加载:https://github.com/databricks/spark-sql-perf [15]充满了:https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-transparent-tpc-ds-lakehouse-performance-benchmarks [16]TPC-DS 规范:https://www.tpc.org/tpc_documents_current_versions/pdf/tpc-ds_v2.13.0.pdf [17]数据维护运行:https://www.tpc.org/information/sessions/tpc_ds.pdf [18]将测试系统的:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=fe178bd7cb36ad9f7c7449ea2d934b33860bb6b1#:~:text=Another%20distinctive%20characteristic%20of%20the,number%20of%20tables%20and%20columns. [19]只能删除:https://www.tpc.org/information/sessions/tpc_ds.pdf [20]Amazon:https://hudi.apache.org/blog/2025/03/31/amazon-hudi/ [21]Stripe:https://stripe.com/blog/ledger-stripe-system-for-tracking-and-validating-money-movement [22]Walmart:https://medium.com/walmartglobaltech/lakehouse-at-fortune-1-scale-480bcb10391b [23]Zoom:https://aws.amazon.com/blogs/big-data/how-zoom-implemented-streaming-log-ingestion-and-efficient-gdpr-deletes-using-apache-hudi-on-amazon-emr/ [24]事实表的删除:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=fe178bd7cb36ad9f7c7449ea2d934b33860bb6b1#:~:text=Another%20distinctive%20characteristic%20of%20the,number%20of%20tables%20and%20columns. [25]Uber:https://www.uber.com/blog/uber-big-data-platform/ [26]Affirm:https://tech.affirm.com/expressive-time-travel-and-data-validation-for-financial-workloads-c8b8cc8d12f4 [27]TPC-C 模拟:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=7a80e7f13cf566c2e7facbd3a783737d64b5c17b [28]LST-Bench:https://arxiv.org/pdf/2305.01120v3 [29]SQL 脚本:https://github.com/microsoft/lst-bench/tree/main/core/run/spark-3.3.1/scripts/tpcds/data_maintenance [30]TPC-DI:https://www.tpc.org/TPC_Documents_Current_Versions/pdf/TPC-DI_v1.1.0.pdf [31]最大改进:https://www.vldb.org/pvldb/vol7/p1367-poess.pdf [32]PDGF 数据生成:https://www.tpc.org/tpc_documents_current_versions/current_specifications5.asp [33]比较:https://www.databricks.com/blog/2023/04/14/how-we-performed-etl-one-billion-records-under-1-delta-live-tables.html [34]的工具:https://github.com/shannon-barrow/databricks-tpc-di [35]增量插入:https://github.com/shannon-barrow/databricks-tpc-di/blob/main/src/incremental_batches/silver/FactWatches%20Incremental.sql [36]改进:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=fe178bd7cb36ad9f7c7449ea2d934b33860bb6b1#:~:text=Another%20distinctive%20characteristic%20of%20the,number%20of%20tables%20and%20columns. [37]FactWatches:https://github.com/shannon-barrow/databricks-tpc-di/blob/main/src/incremental_batches/silver/FactWatches%20Incremental.sql [38]增加到:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=fe178bd7cb36ad9f7c7449ea2d934b33860bb6b1#:~:text=Another%20distinctive%20characteristic%20of%20the,number%20of%20tables%20and%20columns [39]增加了架构的复杂性:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=7a80e7f13cf566c2e7facbd3a783737d64b5c17b [40]增加了复杂性:https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=7a80e7f13cf566c2e7facbd3a783737d64b5c17b [41]的性能结果:https://www.tpc.org/tpcdi/default5.asp [42]质量问题的:https://doras.dcu.ie/22315/1/2018_Data_Quality_Problems_in_TPC-DI_Based_Data_Integration_Processes.pdf [43]硬编码:https://github.com/shannon-barrow/databricks-tpc-di/blob/main/src/tools/datagen/pdgf/config/tpc-di-schema.xml#L654 [44]这里有:https://medium.com/@kywe665/delta-hudi-iceberg-a-benchmark-compilation-a5630c69cffc [45]TPC-DS 基准测试:https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-transparent-tpc-ds-lakehouse-performance-benchmarks [46]分布:https://hudi.apache.org/docs/indexes/#picking-indexing-strategies [47]Zipf 分布:https://en.wikipedia.org/wiki/Zipf%27s_law [48]YCSB NoSQL 数据库基准测试:https://dl.acm.org/doi/10.1145/1807128.1807152 [49]微分区:https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions [50]文件组:https://hudi.apache.org/docs/storage_layouts [51]均匀分布:https://en.wikipedia.org/wiki/Continuous_uniform_distribution [52]Salesforce/Delta Lake:https://engineering.salesforce.com/engagement-activity-delta-lake-2e9b074a94af/ [53]Uber/Apache Hudi:https://www.uber.com/blog/uber-big-data-platform/ [54]NerdWallet/Apache Hudi:https://aws.amazon.com/blogs/big-data/how-nerdwallet-uses-aws-and-apache-hudi-to-build-a-serverless-real-time-analytics-platform/?utm_source=chatgpt.com [55]Affirm/Iceberg:https://tech.affirm.com/expressive-time-travel-and-data-validation-for-financial-workloads-c8b8cc8d12f4 [56]Amazon/Hudi:https://hudi.apache.org/blog/2025/03/31/amazon-hudi/ [57]Walmart/Hudi:https://medium.com/walmartglobaltech/lakehouse-at-fortune-1-scale-480bcb10391b [58]Stripe 分类账设计:https://stripe.com/blog/ledger-stripe-system-for-tracking-and-validating-money-movement [59]Iceberg:https://github.com/apache/iceberg/issues/11800 [60]Apache Doris:https://github.com/apache/doris/issues/15723 [61]BigQuery:https://medium.com/google-cloud/when-did-your-data-really-arrive-in-bigquery-bb5203458258 [62]Databricks:https://www.databricks.com/blog/2020/12/15/handling-late-arriving-dimensions-using-a-reconciliation-pattern.html [63]Snowflake:https://www.snowflake.com/en/blog/out-of-sequence-data/ [64]奖章架构:https://www.onehouse.ai/glossary/medallion-architecture [65]Spotify:https://engineering.atspotify.com/2016/03/spotifys-event-delivery-the-road-to-the-cloud-part-iii [66]Zoom/Apache Hudi:https://aws.amazon.com/blogs/big-data/how-zoom-implemented-streaming-log-ingestion-and-efficient-gdpr-deletes-using-apache-hudi-on-amazon-emr/ [67]Adobe/Delta Lake/Iceberg:https://blog.developer.adobe.com/search-optimization-for-large-data-sets-for-gdpr-7c2f52d4ea1f [68]Lake Loader:http://github.com/onehouseinc/lake-loader [69]AWS EMR:https://aws.amazon.com/emr/ [70]Databricks:http://databricks.com/ [71]Snowflake:https://www.snowflake.com/en/ [72]Lake Loader™:https://github.com/onehouseinc/lake-loader