通过数据网格在 Netflix Studio 中移动数据

在接下来的几年里，Netflix 上的大部分内容都将来自 Netflix 自己的工作室。从 Netflix 电影或剧集开始投放到 Netflix 上架之前很久，它经历了许多阶段。这以前所未有的规模发生，并带来了许多有趣的挑战；挑战之一是如何提供跨多个阶段和系统的 Studio 数据的可见性，以促进卓越运营和授权决策。 Netflix 以其松散耦合的微服务架构和全球工作室足迹而闻名，将来自微服务的数据实时呈现并连接到工作室数据目录变得比以往任何时候都更加重要。运营报告是一种报告范式，专门用于涵盖高分辨率、低延迟的数据集，为业务领域的详细日常活动¹和流程提供服务。这种范式旨在帮助一线运营人员和利益相关者“经营业务”²；通过临时分析、决策支持和跟踪（任务、资产、计划等）等方式执行任务。该范式跨越方法、工具和技术，通常与更具战略性（与战术性）的分析报告和预测建模形成对比。在 Netflix Studio，团队构建各种业务数据视图，为日常决策提供可见性。凭借近乎实时的可靠数据，Studio 团队能够利用最新信息更好地跟踪和响应不断变化的制作节奏，并提高全球业务运营的效率。 Netflix Studio 之间的数据连接和运营报告工具的可用性也激励工作室用户避免形成数据孤岛。在过去几年中，Netflix Studio 经历了几次数据移动方法的迭代。在初始阶段，数据消费者建立直接从数据库拉取数据的 ETL 管道。使用这种批处理风格的方法，出现了几个问题，例如数据移动与数据库表紧密耦合，数据库模式不是业务数据模型的精确映射，以及由于不是实时数据而过时等。 后来，我们转移到事件驱动的流数据管道（由 Delta 提供支持），与批处理方式相比解决了一些问题，但也有其自身的痛点，例如流处理技术的高学习曲线、手动管道设置、缺乏模式演化支持、新实体入职效率低下、安全访问模型不一致等。借助最新的数据网格平台，Netflix Studio 中的数据移动达到了一个新阶段。这种配置驱动的平台在创建新管道时显着缩短了前置时间，同时提供了新的支持功能，例如端到端架构演变、自助 UI 和安全数据访问。下面的高级图表显示了 Operational Reporting 数据移动的最新版本。对于数据交付，我们利用数据网格平台为数据移动提供动力。 Netflix Studio 应用程序通过 Studio Edge 公开 GraphQL 查询，这是一个统一的图，连接 Netflix Studio 中的所有数据并提供一致的数据检索。更改数据捕获 (CDC) 源连接器从工作室应用程序的数据库事务日志中读取并发出更改事件。 CDC 事件被传递到数据网格扩充处理器，该处理器向 Studio Edge 发出 GraphQL 查询以扩充数据。一旦数据进入 Netflix 数据仓库的冰山表，它们就可以用于临时或预定的查询和报告。集中的数据将转移到第三方服务，例如为利益相关者提供的 Google Sheets 和 Airtable。我们将在以下部分深入探讨数据交付和数据消耗。 Data Mesh 是一种完全托管的流数据管道产品，用于启用变更数据捕获 (CDC) 用例。在数据网格中，用户创建源并构建管道。源模仿外部管理源的状态——当外部源发生变化时，相应的 CDC 消息会生成到数据网格源。管道可以配置为将数据转换和存储到外部管理的接收器。

Data Mesh 提供拖放式自助服务用户界面，用于探索源和创建管道，以便用户可以专注于提供业务价值，而不必担心管理和扩展复杂的数据流基础设施。更改数据捕获或 CDC 是一种语义，用于处理源中的更改，目的是将这些更改复制到接收器。表更改可能是行更改（插入行、更新行、删除行）或架构更改（添加列、更改列、删除列）。截至目前，已为 Netflix（MySQL、Postgres）的数据存储实施了 CDC 源。 CDC 事件也可以通过 Java 客户端生产者库发送到数据网格。在数据网格中，处理器是一个可配置的数据处理应用程序，它使用、转换和生成 CDC 事件。一个处理器有 1 个或多个输入和 0 个或多个输出。具有 0 个输出的处理器是接收器连接器；将事件写入外部管理的接收器（例如 Iceberg、ElasticSearch 等）。 Data Mesh 允许开发人员为平台贡献处理器。处理器不一定是集中开发和管理的。然而，数据网格平台团队努力提供和管理利用率最高的处理器（例如源连接器和接收器连接器） 处理器是可重用的。同一处理器映像包多次用于处理器的所有实例。每个实例都配置为适合每个用例。例如，可以配置一个 GraphQL 丰富处理器来查询 GraphQL 服务，以丰富不同管道中的数据； Iceberg sink 处理器可以被初始化多次以将数据写入具有不同模式的不同数据库/表。 Schema 是 Data Mesh 的关键组件。当上游模式发生变化时（例如 MySQL 表中的模式更改），Data Mesh 会检测到更改，检查兼容性并将更改应用到下游。通过架构演变，数据网格确保运营报告管道始终生成具有最新架构的数据。消费者模式 消费者模式定义了下游处理器如何使用数据。请参阅下面的示例。

模式兼容性数据网格使用消费者模式兼容性来实现灵活而安全的模式演变。如果操作报告管道使用的字段从 CDC 源中删除，数据网格将此更改归类为不兼容，暂停管道处理并通知管道所有者。另一方面，如果任何消费者都没有使用必需的字段，则删除这些字段将是兼容的。在 Data Mesh 中，我们引入了 Opt-in to Schema Evolution 布尔标志来区分这两种类型的用例。选择加入：所有上游字段都将传播到处理器。例如，当上游添加一个新字段时，它将自动传播。选择退出：只有一部分字段（使用“已使用”复选框定义）在处理器中传播和使用。其余字段的上游更改不会影响此处理器。 Schema Propagation 检查Schema Compatibility 后，Data Mesh Platform 将根据最终用户的意图传播Schema 更改。通过选择加入架构演变标志，运营报告管道可以使架构与上游数据存储保持同步。作为模式传播的一部分，平台还将模式从管道同步到冰山接收器。在当前的 Data Mesh Operational Reporting 管道中，最常用的中间处理器是 GraphQL Enrichment Processor。它将来自 Source Connector 的 CDC 事件的列值作为 GraphQL 查询输入，然后向 Studio Edge 提交查询以丰富数据。借助 Studio Edge 的单一数据模型，它集中了数据建模工作，Studio UI 应用程序、后端服务和搜索平台高度利用了这一点。通过 Studio Edge 丰富数据有助于我们在整个运营报告生态系统中实现一致的数据建模。这是 GraphQL 处理器配置的示例，管道构建器只需要配置以下字段即可提供浓缩处理器：

下图是生产环境中用于接收电影相关数据的示例操作报告管道。想要移动数据的团队不再需要学习和编写自定义的流处理作业。相反，他们只需要在 UI 中配置管道拓扑，同时获得开箱即用的其他功能，如模式演变和安全数据访问。 Apache Iceberg 是一种用于大型分析数据集的开源表格式。 Data Mesh 利用 Iceberg 表作为下游分析用例的数据仓库接收器。目前只附加了冰山水槽。视图建立在原始冰山表之上，以根据操作时间戳检索每个主键的最新记录，这表明记录何时在接收器中生成。当前的管道消费者直接使用视图而不是原始表。需要压缩过程来优化业务视图上下游查询的性能以及降低 S3 GET OBJECT 操作的成本。每日流程按时间戳对记录进行排序，以生成压缩记录的数据框。旧数据文件被一组仅包含压缩数据的新数据文件覆盖。 Data Mesh 在处理器和管道级别提供指标和仪表板，以实现操作可观察性。如果他们的管道出现问题，运营报告管道所有者将收到警报。我们还对从 Data Mesh 管道生成的数据表进行两种类型的审计以保证数据质量：端到端审计和合成事件。在 Iceberg 表之上创建的大多数业务视图可以容忍几分钟的延迟。然而，最重要的是我们验证完整的标识符集，例如跨生产者和消费者的电影 ID 列表，以提高对所选数据传输层的整体信心。对于端到端审计，目标是通过大数据平台调度程序每小时运行一次审计，这是一个由 Netflix 数据平台提供的集中集成工具，用于以高效、可靠和可重复的方式运行工作流。审计检查相等性（即查询结果应该相同），两个数据集之间的对称差异在多次运行中应该是空的，以及 SLA 内的最终一致性。当一组主键在真实来源和目标数据网格表之间始终不匹配时，每小时发送一次通知。合成事件审计是人为触发的变更事件，以模仿服务的常见 CUD 操作。它以恒定频率生成心跳信号，目的是将它们用作基线来验证管道的健康状况，而不管流量模式或偶尔的静音情况。我们的工作室合作伙伴依靠数据做出明智的决策并在与制作相关的所有阶段进行协作。 Studio 技术解决方案团队在一些选择的数据工具中提供近乎实时的报告，我们称之为跟踪器以增强决策能力。

在过去的几年里，这些跟踪器中的许多都由手工策划的 SQL 脚本和 API 调用提供支持，这些调用由在名为 Lego 的 Java 服务中实现的 CRON 调度程序管理。乐高是 STS 团队的主要工具，在巅峰时期，乐高管理着 300 多个跟踪器。这种策略有其自身的一系列挑战：无模式并将每个报告列视为字符串并不总是有效，对直接 RDS 连接的不稳定依赖和来自第三方 API 的速率限制通常会导致作业失败。我们有一组专门为报告量身定制的“核心视图”，但这导致只需要非常小的字段子集的查询速度缓慢且成本高昂，因为视图在执行大量连接和聚合工作之前能够检索那个小子集。除了这些问题之外，当我们没有很多跟踪器需要维护时，这工作得很好，但是随着我们创建了更多的跟踪器，达到了数百个，我们开始在维护、意识、知识共享和标准化方面遇到问题。新团队成员很难上手，弄清楚哪个 SQL 支持哪个跟踪器很困难，缺乏标准使每个 SQL 看起来都不同，并且必须随着数据源的变化更新跟踪器是一场噩梦。考虑到这一点，Studio Tech Solutions 专注于构建 Genesis，这是一个语义数据层，允许团队映射定义为 YAML 文件的数据源定义中的数据点，然后使用这些数据点生成跟踪器所需的 SQL，基于输入定义文件中指定的一系列字段、过滤器和格式化程序。 Genesis 负责根据数据源定义中的可用内容以及用户通过正在执行的输入定义指定的内容来连接、聚合、格式化和过滤数据。 Genesis 是一个用 Node.js 编写的无状态 CLI，它根据参数中指定的路径从文件系统中读取它需要的所有内容。这使我们能够将 Genesis 连接到 Jenkins Jobs，提供 GitOps 和 CI 经验来维护现有跟踪器，以及创建新的跟踪器。我们可以简单地更改数据层，触发一个空的拉取请求，审查更改并使我们的所有跟踪器都与数据源更改保持同步。截至撰写本文之日，Genesis 支持 240 多个跟踪器，并且每天都在增长，使我们全球工作室的数千名合作伙伴能够使用近乎实时的数据进行协作、注释和共享信息。生成的查询随后用于多个跟踪器的工作流定义中。 Netflix 数据仓库支持用户创建数据移动工作流，这些工作流通过我们由 Titus 提供支持的大数据调度程序进行管理。

我们使用调度程序来执行我们的查询并将结果移动到数据工具，通常是 Google Sheet Tab、Airtable base 或 Tableau 仪表板。调度程序提供模板化作业，用于将数据从 Presto SQL 输出移动到这些工具，从而可以轻松创建和维护数百个数据移动工作流。截至 2021 年 7 月，Studio 技术解决方案团队正在完成从乐高内置的所有跟踪器迁移到使用 Genesis 和数据门户。此策略提高了 Studio Tech Solutions 团队的绩效和稳定性。团队现在可以轻松地创建、审查、更改、监控和发现跟踪器。总之，我们的工作室合作伙伴有一个跟踪器可供他们使用，其中包含近乎实时的数据并根据他们的需求量身定制。他们可以使用他们熟悉的灵活工具进行操作、注释和协作。在此过程中，我们了解到复杂领域中不断发展的数据移动可能需要多次迭代，并且需要由业务影响驱动。所有数据利益相关者之间良好的跨职能伙伴关系和协作对于塑造理想的数据产品至关重要。然而，我们的故事并没有就此结束。要实现这种理想数据产品的愿景，我们还有很长的路要走，尤其是在以下领域： 在我们的 Studio 生态系统中引导跟踪器而不是第三方工具。与上述观点相同，这将使我们能够保持数据治理、沿袭和安全的高标准。这些是 Netflix Studio 计划投资的一些有趣领域。我们将在未来跟进有关这些主题的博客文章。敬请期待！

¹ 英蒙，比尔。运营和信息报告，信息管理，2000 年 7 月 1 日。² Dehghani，Zhamak。数据网格：大规模交付数据驱动的价值，O'Reilly Media, Inc.，2021 年。由于多个团队的努力，通过数据网格进行的数据移动在 Netflix Studio 中取得了成功。我们要感谢以下同事：Amanda Benhamou、Andreas Andreakis、Anthony Preza、Bo Lei、Charles Zhao、Justin Cunningham、Kasturi Chatterjee、Kevin Zhu、Stephanie Barreyro、Yoomi Koh。