在 Netflix，我们的会员和财务数据工程团队利用与计划、定价、会员生命周期和收入相关的各种数据来推动分析、为各种仪表板提供支持并做出基于数据的决策。
Netflix 财务报告中的许多指标均由我们团队的努力提供支持和协调！鉴于我们在这条关键路径上的作用，准确性至关重要。在这种情况下，管理数据，尤其是当数据延迟到达时，可能会带来巨大的挑战！
在这个由三部分组成的博客文章系列中，我们向您介绍Psyberg，我们的增量数据处理框架旨在应对此类挑战！
我们将讨论批量数据处理、我们面临的限制以及 Psyberg 如何成为解决方案。此外，我们将深入研究 Psyberg 的内部工作原理、其独特的功能以及它如何集成到我们的数据管道工作流程中。
挑战：对迟到数据进行增量数据处理
我们团队的数据处理模型主要包括批处理管道，这些管道以不同的时间间隔运行，从每小时运行到每天多次（也称为日内）甚至每天运行。我们期望每次运行结束时获得完整且准确的数据。为了满足这样的期望，我们通常会延迟几个小时来运行管道，以便为迟到的数据留出空间。
迟到数据本质上是由于系统重试、网络延迟、批处理计划、系统中断、上游工作流程延迟或源系统中的协调而延迟的数据。
我们的团队之前采用了一些策略来管理这些场景，这通常会导致不必要地重新处理未更改的数据。我们使用的一些技术是：
- 使用固定回溯窗口始终重新处理数据，假设大多数迟到事件将发生在该窗口内。然而，这种方法通常会导致冗余数据重新处理，从而增加ETL处理时间和计算成本。随着数据规模的增加，它也会变得低效。想象一下每小时重新处理过去 6 小时的数据！
- 在出现迟到数据时添加警报以进行标记，阻止管道，并执行手动干预，触发回填管道来处理错过的事件。这种方法是一种简单的解决方案，在大多数情况下只需最少的额外处理，因此是我们的首选解决方案。然而，当晚期事件发生时，重新处理数据和追赶所有依赖管道的痛苦是不值得的！我们稍后会讨论这个问题。
从较高的层面来看，这两种方法对于日内管道来说都是低效的，并且影响了成本、性能、准确性和时间。
我们开发了Psyberg ，这是一个使用Iceberg 的增量处理框架，可以更有效地应对这些挑战。
在 Netflix，我们的后端微服务不断生成实时事件数据，并流入 Kafka。这些原始事件是我们团队内各种数据处理工作流程的来源。我们摄取这些不同的事件数据并将其转换为标准化的事实表。然后，事实表会向下游的日内管道提供数据，每小时处理一次数据。
Psyberg：游戏规则改变者！
Psyberg 自动化我们的数据加载，使其适合各种数据处理需求，包括日内管道用例。它利用 Iceberg 元数据来促进处理增量和基于批处理的数据管道。
Psyberg 的关键功能之一是它能够检测和管理迟到数据，无论其位于哪个分区。此功能允许数据管道在无需人工干预的情况下有效处理迟到数据，从而确保我们系统中更高的数据准确性。Iceberg元数据和Psyberg自己的元数据构成了其高效数据处理能力的支柱。
Psyberg 主要利用两个关键的 Iceberg 元数据表（快照和分区）来管理工作负载。所有 Iceberg 表都具有关联的元数据，可以深入了解数据表中的更改或更新。
快照元数据表记录了重要的元数据，例如：
- 快照的创建时间
- 执行的操作类型（追加、覆盖等）
- 生成 Iceberg 快照期间创建/更新的分区的摘要
这些详细信息使 Psyberg 能够跟踪不同的操作并识别自上一个高水位线以来对源表所做的更改。
分区元数据表特别有趣，因为它存储：
- 有关数据表中使用的分区键的信息
- 特定分区内每列的列名称和值范围
Netflix 内部实现的一个独特之处在于，它以反序列化格式提供分区内每一列的值范围。此信息有助于 Psyberg 理解两种类型的迟到数据（事件和处理时间）的时间戳范围，而无需查询实际数据。
除了 Iceberg 元数据之外，Psyberg 还维护自己的元数据表——会话表和高水位表。这两个表均按管道进程名称进行分区，以独立维护与每个数据管道相关的信息。
会话表捕获特定于每个管道运行的元数据，包括：
- 进程名称分区用于跟踪与数据管道进程关联的所有运行
- 用于跟踪流程中唯一运行的会话 ID
- 处理 URI 以识别加载中涉及的输入分区
- 事件和处理时间的“从日期”、“从小时”、“到日期”和“到小时”
高水位线表存储每次管道运行结束时会话表中的相关值：
- 最新和之前的高水位标记时间戳
- 与最新运行相关的元数据
此信息对于每个管道运行实例至关重要，因为它有助于确定要加载的数据，在处理后更新高水位线，并最终生成输出信号以通知下游工作流有关数据完整且可用的日期时间。它还可以作为调试和创建管道作业审核的重要资源。