架构设计内容分享(一百四十四)：Netflix增量处理解决方案

增量处理是一种处理工作流中新数据或更改数据的方法。主要优点是它仅增量处理新添加或更新到数据集的数据，而不是重新处理整个数据集。这不仅降低了计算资源的成本，而且还显着减少了执行时间。当工作流执行的持续时间较短时，失败和手动干预的机会就会减少。它还通过简化现有管道和解锁新模式来提高工程生产力。

在这篇博文中，我们讨论了 Netflix 工作流程的现状和挑战。我们将展示如何使用 Netflix Maestro 和 Apache Iceberg 构建干净高效的增量处理解决方案 (IPS)。IPS为用户提供数据准确性、数据新鲜度、回填等增量处理支持，解决工作流程中的诸多挑战。IPS 使用户能够继续使用数据处理模式，只需进行最小的更改。

介绍

Netflix 依靠数据来推动其各个阶段的业务。无论是分析 A/B 测试、优化工作室制作、训练算法、投资内容获取、检测安全漏洞还是优化支付，结构良好且准确的数据都是基础。随着我们的业务在全球范围内扩展，对数据的需求不断增长，并且对可扩展的低延迟增量处理的需求开始出现。数据集所有者通常面临三个常见问题。

• • 数据新鲜度：需要快速准确地处理来自 Iceberg 表的大型数据集，以生成见解，从而更快地做出产品决策。目前数据平台工具集提供的每小时处理语义以及有效的时间戳水印或数据信号满足了许多用例，但对于低延迟批处理来说并不是最好的。在 IPS 之前，数据平台没有作为单一易于使用的产品来跟踪数据集状态和进展的解决方案。这导致了一些内部解决方案的出现，例如 Psyberg。这些内部库通过捕获更改的分区来处理数据，这只适用于特定的用例。此外，这些库与用户业务逻辑紧密耦合，这往往会带来较高的迁移成本、维护成本，并且需要与数据平台团队的大量协调。

• • 数据准确性：迟到的数据会导致过去处理的数据集变得不完整，从而不准确。为了弥补这一点，ETL 工作流通常使用回溯窗口，并根据该窗口重新处理特定时间窗口内的数据。例如，作业会重新处理过去 3 天的聚合，因为它假设会有延迟到达的数据，但 3 天之前的数据不值得重新处理的成本。

• • 回填：回填数据集是大数据处理中的常见操作。这需要重新填充计划处理之前的历史时间段的数据。需要回填的原因可能有多种，例如：(1) 上游数据集由于其数据管道的业务逻辑发生变化而被重新填充，(2) 数据管道中的业务逻辑发生更改，(3) 创建了需要填充历史时间范围的新指标，(4 ）发现历史数据缺失等。

目前，各个当地团队正在以次优且成本效益较低的方式解决这些挑战，以满足需求，例如

• • 回顾：这是数据工程师用来解决数据准确性问题的通用且简单的方法。用户配置工作流程以读取窗口中的数据（例如过去 3 小时或 10 天）。该窗口是根据用户的领域知识设置的，以便用户高度确信迟到的数据将被包含在内或无关紧要（即数据到达太晚而无用）。它以较高的时间和计算资源成本来确保正确性。

• • Foreach 模式：用户使用 Maestro foreach 支持构建回填工作流程。它非常适合回填单个工作流程生成的数据。如果管道有多个阶段或许多下游工作流程，用户必须为每个阶段手动创建回填工作流程，这需要大量的手动工作。

这里描述的增量处理解决方案（IPS）旨在解决上述问题。设计目标是为增量处理提供一个干净且易于采用的解决方案，以确保数据新鲜度、数据准确性，并提供轻松的回填支持。

• • 数据新鲜度：为具有状态跟踪功能的微批量方式（例如 15 分钟间隔）调度工作流程提供支持

• • 数据准确性：提供处理所有迟到数据的支持，以达到业务所需的数据准确性，在时间和成本效率方面显着提高性能

• • 回填：提供托管回填支持来构建、监控和验证回填，包括自动将更改从上游工作流传播到下游工作流程，从而大大提高工程生产力（即，需要几天或几周的工程工作来构建回填工作流，而不是一键完成托管工作流） 回填）

方法概述

一般概念

增量处理是一种批量处理数据的方法，但仅限于新数据或更改的数据。为了支持增量处理，我们需要一种方法，不仅可以捕获增量数据更改，还可以跟踪其状态（即更改是否由工作流处理）。它必须了解更改并可以从源表捕获更改，然后继续跟踪这些更改。在这里，变化不仅仅意味着新数据本身。例如，聚合目标表中的一行需要源表中与聚合行关联的所有行。此外，如果有多个源表，通常所有输入表中更改的数据范围的并集会给出完整的更改数据集。因此，捕获的更改信息必须包括所有相关数据，包括源表中那些未更改的行。由于前面提到的复杂性，更改跟踪不能简单地通过使用单个水印来实现。IPS 必须以更细的粒度跟踪那些捕获的变化。

源表的更改可能会以各种方式影响目标表中的转换结果。

• • 如果目标表中的一行源自源表中的一行，则新捕获的数据更改将成为工作流管道的完整输入数据集。

• • 如果目标表中的一行源自源表中的多行，则捕获新数据只会告诉我们必须重新处理这些行。但 ETL 所需的数据集超出了变更数据本身。例如，基于帐户 ID 的聚合需要源表中有关帐户 ID 的所有行。更改数据集将告诉我们哪些帐户 ID 发生了更改，然后用户业务逻辑需要加载与更改数据中找到的这些帐户 ID 关联的所有数据。

• • 如果目标表中的一行是基于更改的数据集之外的数据导出的，例如 将源表与其他表连接起来，新捕获的数据仍然有用，并且可以指示受影响的数据范围。然后工作流程将根据范围重新处理数据。例如，假设我们有一个表，用于保存给定帐户的累计查看时间（按天划分）。如果3天前的观看时间因数据迟到而立即更新，则该帐号接下来两天的观看时间必须重新计算。在这种情况下，捕获的迟到数据将告诉我们重新计算的开始，这比通过猜测重新计算过去 X 天的所有内容要准确得多，其中 X 是由业务领域知识决定的截止回溯窗口。

一旦捕获到更改信息（数据或范围），工作流必须以稍微复杂的方式将数据写入目标表，因为简单的 INSERT OVERWRITE 机制无法正常工作。有两种选择：

• • 合并模式：在某些计算框架中，例如 Spark 3，它支持MERGE INTO，允许新数据合并到现有数据集中。这解决了增量处理的写入问题。请注意，使用 MERGE INTO 时可以安全地重新启动工作流程/步骤，而不必担心插入重复数据。

• • 追加模式：用户还可以使用仅追加写入（例如 INSERT INTO）将新数据添加到现有数据集。处理完成后，追加数据将提交到表中。如果用户想要重新运行或重新构建数据集，他们将运行回填工作流程以完全覆盖目标数据集（例如 INSERT OVERWRITE）。

此外，在许多情况下，IPS 自然会支持回填。下游工作流程（如果没有业务逻辑变化）将由回填引起的数据变化触发。这使得回填数据能够在多级管道中自动传播。请注意，本博客中跳过了回填支持。我们将在下面的另一篇博客文章中讨论 IPS 回填支持。

Netflix Maestro

Maestro 是 Netflix 数据工作流编排平台，旨在满足 Netflix 当前和未来的需求。它是一个通用工作流编排器，为 Netflix 的数据平台用户提供完全托管的工作流即服务 (WAAS)。它为各种用例的数千名用户提供服务，包括数据科学家、数据工程师、机器学习工程师、软件工程师、内容制作者和业务分析师。Maestro 具有高度可扩展性和可扩展性，可支持现有和新的用例，并为最终用户提供增强的可用性。

自上一篇关于 Maestro 的博客以来，我们已经代表用户将所有工作流程迁移到其中，并最大限度地减少了中断。Maestro 已完全部署在生产环境中，并在其上运行 100% 的工作负载。

IPS 是在 Maestro 的基础上构建的，作为扩展，添加了两个构建块，即新的触发机制和步骤作业类型，以支持所有工作流程的增量处理。它以最低的入职成本无缝集成到整个 Maestro 生态系统中。

Apache Iceberg

Iceberg 是一种适用于大型分析表的高性能格式。Iceberg 将 SQL 表的可靠性和简单性带入大数据，同时使 Spark、Trino、Flink、Presto、Hive 和 Impala 等引擎能够同时安全地处理相同的表。它支持表达 SQL、完整模式演化、隐藏分区、数据压缩以及时间旅行和回滚。在 IPS 中，我们利用 Apache Iceberg 提供的丰富功能来开发一种轻量级方法来捕获表更改。

增量变更捕获设计

使用 Netflix Maestro 和 Apache Iceberg，我们创建了一种新颖的增量处理解决方案，它以超轻量级的方式提供增量变化（数据和范围）捕获，而无需复制任何数据。在我们的探索过程中，我们看到了使用增量处理来提高成本效率和工程生产率的巨大机会。

这是我们基于 Apache Iceberg 功能实现增量变更捕获的解决方案。众所周知，iceberg表包含带有一组元数据数据的快照列表。快照包括对实际不可变数据文件的引用。快照可以包含来自不同分区的数据文件。

上图显示 s0 包含分区 P0 和 P1 在 T1 的数据。然后在 T2，新快照 s1 与新数据文件列表一起提交到表中，其中包括分区 P0 和 P1 的迟到数据以及 P2 的数据。

我们实现了一种轻量级方法来创建iceberg表（称为 ICDC 表），该表具有自己的快照，但仅包含原始表中的新数据文件引用，而不复制数据文件。它效率高、成本低。然后，工作流管道只需加载 ICDC 表即可仅处理分区 P0、P1、P2 中的更改数据，而无需重新处理 P0 和 P1 中未更改的数据。同时，由于 Iceberg 表元数据包含每个数据文件的每个数据字段的上限和下限信息，因此还捕获了指定数据字段的变化范围。此外，IPS将跟踪每个工作流程的数据文件粒度的变化。

这种轻量级方法与 Maestro 无缝集成，允许所有（数千个）调度程序用户在数以万计的工作流程中使用这个新的构建块（即增量处理）。每个使用IPS的工作流程都会注入一个表参数，该参数是轻量级ICDC表的表名。ICDC 表仅包含变更数据。此外，如果工作流需要更改范围，则会将参数列表注入到用户工作流中以包含更改范围信息。增量处理可以通过新的步骤作业类型（ICDC）和/或新的增量触发机制来启用。用户可以将它们与所有现有的 Maestro 功能一起使用，例如 foreach 模式、基于有效时间戳水印的步骤依赖性、写入-审核-发布模板化模式等。

主要优点

通过这种设计，用户工作流程可以以非常低的工作量采用增量处理。用户业务逻辑也与IPS实现解耦。多阶段管道还可以将增量处理工作流程与现有的正常工作流程混合在一起。我们还发现，使用 IPS 后，通过删除处理回溯窗口的复杂性或调用一些内部库的额外步骤，可以简化用户工作流程。

将增量处理功能作为用户的新功能/构建块添加到 Netflix Maestro 中，将使用户能够以更有效的方式构建工作流程，并弥合差距，以更简单的方式解决许多具有挑战性的问题（例如处理迟到的数据） 。

新兴的增量处理模式

在将用户管道引入 IPS 时，我们发现了一些增量处理模式：

对捕获的增量变化数据进行增量处理，直接追加到目标表中

这是简单的增量处理用例，其中变更数据携带数据处理所需的所有信息。上游更改（通常来自单个源表）被传播到下游（通常是另一个目标表），工作流管道只需要处理更改数据（可能与其他维度表连接），然后合并到（通常追加）到 目标表。此模式将取代回溯窗口模式来处理迟到的数据。用户工作流程不需要使用回溯窗口模式完全覆盖过去 X 天的数据，而是只需通过处理 ICDC 表将更改数据（包括迟到的数据）合并到目标表中。

使用捕获的增量变更数据作为行级过滤列表来删除不必要的转换

ETL 作业通常需要根据某些分组键聚合数据。更改数据将公开由于源表中的新登陆数据而需要重新聚合的所有分组键。然后，ETL 作业可以使用 ICDC 作为筛选器，将原始源表与这些分组键上的 ICDC 表连接起来，以加快处理速度，从而能够计算更小的数据集。业务转换逻辑没有改变，ETL工作流程也没有重新设计。ETL 管道保留了批处理工作流的所有优点。

在业务逻辑中使用捕获的范围参数

此模式通常用于复杂的用例，例如连接多个表并进行复杂的处理。在这种情况下，变更数据无法全面反映 ETL 工作流程所需的输入。相反，更改数据指示给定输入表或通常多个输入表中的特定字段集（可能是分区键）的一系列已更改数据集。然后，所有输入表中的变更范围的并集给出了工作流所需的完整变更数据集。此外，通常必须覆盖整个数据范围，因为转换不是无状态的，并且取决于先前范围的结果。另一个例子是，查询中的目标表或窗口函数中的聚合记录必须基于分区中的整个数据集进行更新（例如，计算整个分区中的介质）。基本上，从变化数据导出的范围指示要重新处理的数据集。

用例

Netflix 的数据工作流程通常必须处理迟到的数据，由于其简单且易于实现，通常通过使用回溯窗口模式来解决。在回溯模式中，ETL 管道将始终消耗源表中过去 X 个分区数据，然后在每次运行时覆盖目标表。这里，X是管道所有者根据其领域专业知识决定的数字。缺点是计算和执行时间的成本。在不考虑迟到数据的情况下，它的成本通常比管道高出近 X 倍。由于迟到的数据稀疏，大部分处理都是对已经处理过的数据进行的，这是不必要的。另请注意，这种方法基于领域知识，有时会受到业务环境或数据工程师领域专业知识的变化的影响。在某些情况下，得出一个好的常数是很有挑战性的。

下面，我们将通过一个两级数据管道来说明如何使用IPS对其进行重建，以提高成本效率。我们将观察到成本显着降低（> 80%），而业务逻辑几乎没有变化。在此用例中，我们将回溯窗口大小 X 设置为 14 天，这在不同的实际管道中有所不同。

具有回溯窗口的原始数据管道

• • playback_table：一个冰山表，保存来自用户设备的播放事件，这些事件是通过流管道摄取的，并且数据迟到，该表很稀疏，只有大约百分之几的数据迟到。

• • playback_daily_workflow：每日定时工作流程，处理过去X天的playback_table数据，并将转换后的过去X天的数据写入目标表

• • playback_daily_table：playback_daily_workflow的目标表，过去X天每天都会被覆盖

• • playback_daily_agg_workflow：每日定时工作流程，处理过去X天的playback_daily_table数据，并将过去X天的聚合数据写入目标表

• • playback_daily_agg_table：playback_daily_agg_workflow 的目标表，过去 14 天每天都会被覆盖。

我们使用真实的业务逻辑在示例数据集中运行此管道，这是示例运行的平均执行结果

• • 第一阶段工作流程处理playback_table数据大约需要7个小时

• • 第二阶段工作流程处理playback_daily_table数据大约需要3.5小时

具有增量处理的新数据管道

使用IPS，我们重写了管道，以尽可能避免重新处理数据。新管道如下所示。

第一阶段：

• • ips_playback_daily_workflow：它是playback_daily_workflow的更新版本。

• • 然后，工作流 Spark SQL 作业读取增量更改数据捕获 (ICDC) 冰山表（即playback_icdc_table），该表仅包含添加到playback_table 中的新数据。它包括迟到的数据，但不包括playback_table 中任何未更改的数据。

• • 业务逻辑将通过 MERGE INTO SQL 查询替换 INSERT OVERWRITE，然后新数据将合并到playback_daily_table 中。

第二阶段：

• • IPS捕获playback_daily_table的变化数据，并将变化数据保存在ICDC源表(playback_daily_icdc_table)中。因此我们不需要在业务逻辑中对回溯窗口进行硬编码。如果playback_daily_table中只有Y天有数据变化，那么只需要加载Y天的数据。

• • 在 ips_playback_daily_agg_workflow 中，当天分区的业务逻辑将相同。然后我们需要更新业务逻辑来处理迟到的数据

• • 将playback_daily表与过去2到X天的聚合group-by键上的playback_daily_icdc_table连接起来，不包括当天（即第1天）

• • 由于迟到的数据稀疏，JOIN 将缩小playback_daily_table 数据集的范围，以便仅处理其中的一小部分。

• • 业务逻辑将使用 MERGE INTO SQL 查询，然后更改将传播到下游目标表

• • 对于当天，业务逻辑将相同，并使用playback_daily_table中的数据，然后使用INSERT OVERWRITE将结果写入目标表playback_daily_agg_table，因为不需要与ICDC表连接。

通过这些微小的改变，数据管道的效率得到了极大的提高。在我们的示例运行中，

• • 第一阶段工作流程只需大约 30 分钟即可处理来自playback_table 的 X 天更改数据。

• • 第二阶段工作流程大约需要 15 分钟来处理来自playback_daily_table 的第 2 天到第 X 天之间的变化数据，并与playback_daily_cdc_table 数据连接，并需要另外 15 分钟来处理当天（即第 1 天）playback_daily_table 变化数据。

这里，原始管道和新管道中的 Spark 作业设置是相同的。因此，总的来说，基于 IPS 的新管道总体需要大约 10% 的资源（以执行时间衡量）才能完成。