【数据架构】Netflix 万亿级实时数据基础架构的四个创新阶段

Chinese, Simplified

我叫徐振中。我于 2015 年加入 Netflix，担任实时数据基础架构团队的创始工程师，后来领导了流处理引擎团队。我在 2010 年代初对实时数据产生了兴趣，从那时起我就相信还有很多价值有待发掘。



Netflix 是一个很棒的地方，周围有许多了不起的同事。我为参与将共同信念变为现实的旅程中的每个人感到无比自豪。我想花点时间分享一下团队的主要成就：

  • 我们在 Netflix 的所有组织中将流数据用例从 0 增加到 2000 多个。
  • 我们构建和发展了成功的产品，例如 Keystone、托管 Flink 平台、Mantis 和托管 Kafka 平台。这些产品在数据生态系统的许多方面提供解决方案：包括数据摄取、移动、分析和操作处理以及机器学习用例。
  • 我们是业内率先扩展开源 Kafka 和 Flink 部署以在 2017 年左右,每天处理 1 万亿个事件的公司之一，后来到 2021 年又扩展了 20 倍！

几个月前，我离开了 Netflix，在实时 ML 领域追求类似但扩展的愿景。我认为现在是总结我在 Netflix 构建实时数据基础架构的经验的最佳时机。我希望这篇文章能帮助平台工程师开发他们的云原生、自助式流数据平台，并在许多业务功能中扩展用例（不一定来自我们的成功，也许更多来自我们的失败）。我还相信，了解数据平台的构建方式可以帮助平台用户（例如数据科学家和机器学习工程师）充分利用他们的平台。



帖子里有什么



我将分享实时数据基础架构在 Netflix（2015-2021 年）的迭代之旅的四个阶段。



第 1 阶段：从失败的批处理管道中拯救 Netflix 日志 (2015)



在 Netflix 的全球高速增长期间，业务和运营决策比以往任何时候都更依赖于更快的记录数据。 2015 年，基于 Chukwa/Hadoop/Hive 的批处理管道难以扩展。在这个阶段，我们从头开始构建了一个流优先平台来替换失败的管道。



第 2 阶段：Scale 100s 数据移动用例 (2016)



在最初的产品发布后，内部对数据移动的需求稳步上升。我们必须专注于常见的用例。在这个阶段，我们通过构建一个具有简单而强大的构建块设计的自助服务、完全托管的平台来扩展以支持 100 多个用例。



第 3 阶段：支持定制需求并扩展超过 1000 个用例（2017-2019）



随着流处理在 Netflix 中的发展势头，许多团队要求在数据工程、可观察性和机器学习领域具有更低的延迟和更高的处理灵活性。在此阶段，我们构建了新的流处理开发体验以支持自定义用例，并且我们还应对了新的工程和运营挑战。



第 4 阶段：扩展流处理职责——未来的挑战和机遇（2020 年至今）



随着行业数据平台技术的快速演进，出现了许多新的挑战：协调困难、学习曲线陡峭、流到批边界分裂等。在这个阶段，我们探索了流处理发挥更突出的作用在连接技术和提高抽象以使数据平台更易于使用方面。我们面前还有更多的机会。

对于每个阶段，我将回顾不断发展的业务动机、团队的独特挑战、战略赌注以及我们在此过程中发现的用例模式。

致谢



许多人帮助我审阅了这篇文章，如果没有他们的反馈，我永远不会深入研究许多公正的细节。特别感谢 Chip Huyen、Steven Wu、Prashanth Ramdas、Guanhua Jiang、Scott Shi、Goku Mohandas、David Sun、Astasia Myers 和 Matt Willian！



Netflix 实时数据基础架构的四个阶段



第 1 阶段：从失败的批处理管道中拯救 Netflix 日志 (2015)



语境



2015 年，Netflix 已经拥有约 60MM 的订户，并正在积极扩大其国际影响力。我们都知道，迅速扩大平台杠杆将是维持快速增长的用户增长的关键。



旁注：对于那些不熟悉的人，平台团队通过集中管理基础设施来提供杠杆作用，因此产品团队可以专注于业务逻辑。



我们的团队必须弄清楚如何帮助 Netflix 扩展日志记录实践。当时，Netflix 拥有约 500 个微服务，每天在生态系统中产生超过 10PB 的数据。



收集这些数据对 Netflix 有两个主要目的：

  • 获得业务分析见解（例如，用户保留、平均会话时长、趋势等）。
  • 获得运营洞察力（例如，测量每秒流媒体播放次数以快速轻松地了解 Netflix 系统的运行状况），以便开发人员可以发出警报或执行缓解措施。

您可能会问，为什么我们首先需要将日志从边缘移动到数据仓库？由于数量庞大，对在线事务数据库进行大规模按需分析是不可行的。原因是在线事务处理 (OLTP) 和在线分析处理 (OLAP) 是在不同的假设下构建的——OLTP 是为面向行的访问模式而构建的，而 OLAP 是为面向列的访问模式而构建的。在底层，他们使用不同的数据结构进行优化。



例如，假设我们想知道数亿 Netflix 用户的平均会话长度。假设我们将此按需分析查询放在面向行的 OLTP 系统上。它将导致行级粒度的全表扫描并可能锁定数据库，并且应用程序可能会变得无响应，从而导致不愉快的用户体验。这种类型的分析/报告工作负载在 OLAP 系统上完成要好得多，因此需要以低延迟方式可靠地移动日志。

(Figure: Move data from Edge to Data Warehouse)

到 2015 年，日志记录量已从 2011 年的 450 亿事件/天增加到每天 5000 亿个事件（1PB 的数据摄取）。现有的日志记录基础设施（一个使用 Chukwa、Hadoop 和 Hive 构建的简单批处理管道平台）正在失败 与每周惊人增长的订户数量相比。 据估计，我们有大约六个月的时间来发展流媒体优先的解决方案。 下图显示了从失败的批处理架构到新的基于流的架构的演变。

(Figure: the failing batch pipeline architecture, before migration)

我们决定用 Keystone 替换这个失败的基础设施。

(Figure: the Keystone streaming architecture, after migration)

您可能有的另一个问题是为什么要考虑流优先架构？当时，正确使用流式架构的价值超过了潜在的风险。 Netflix 是一家数据驱动型公司，流媒体架构的直接重要性在于：

  • 减少开发者和运营反馈回路。开发人员严重依赖查看日志来做出运营决策。访问更新的按需日志使开发人员能够更早地检测问题，从而提高生产力。
  • 更好的产品体验。许多产品功能，例如个性化推荐、搜索等，都可以从更新鲜的数据中受益，从而改善用户体验，从而提高用户留存率、参与度等。



挑战



在构建流媒体平台时，我们必须考虑许多挑战。

  • 挑战一：规模大，资源有限。我们有六个月的时间来构建 Keystone 以每天处理 500B 事件，并且我们必须与六个团队成员一起完成它。
  • 挑战 2：不成熟的流媒体生态系统。 2015 年，当传输（Apache Kafka）和处理技术（Apache Samza、Apache Flink）都相对新生时，开发和运营流媒体优先的基础设施很困难。很少有科技公司能够以我们需要的规模证明成功的流媒体优先部署，因此我们必须评估技术选项并进行试验。鉴于我们的资源有限，我们无法自己构建所有东西，必须决定构建什么以及押注哪些新生工具。
  • 挑战 3：分析和运营关注点不同。
    • 分析流处理侧重于正确性和可预测性。例如，将所有用户点击流移入数据仓库需要数据一致性（最少重复或丢失）和延迟的可预测性，延迟通常在分钟范围内。 （Keystone 擅长这个）
    • 操作流处理更多地关注成本效益、延迟和可用性。例如，了解整个 Netflix 设备生态系统的健康状态可以从亚秒级到秒级的延迟中受益，并且可以从源头对数据进行采样或分析以节省成本。 （螳螂擅长这个）
  • 挑战 4：有状态数据平台的云原生弹性很难。 Netflix 已经在 AWS 云上运行了几年。然而，我们是第一个在容器化云基础设施上安装有状态数据平台的人。引擎盖下的每个数据中心都有数十万台物理机器为云提供动力。在这种规模下，硬件故障是不可避免的。当这些故障意外出现时，系统可能很难跟上可用性和一致性预期。在无限制的低延迟流处理环境中更具挑战性，任何故障恢复都可能导致背压累积。流优先架构的云原生弹性将意味着重大的工程挑战。

(Figure: How does stream processing help with operational and analytical data)

第 1 阶段的流处理模式总结



我包括了一些观察到的用例及其每个创新阶段各自的流处理模式。 因此，您可以了解随着时间的推移而发生的演变。

+-----------------------------------------------------------------+
| Pattern               | Product  | Example Use Cases            |
|-----------------------|----------|------------------------------|
| Data Routing          | Keystone | Logging, Data Movement (MVP) |
|-----------------------|----------|------------------------------|
| RT Alerts / Dashboard | Mantis   | SPS Alert                    |
+-----------------------------------------------------------------+

 

策略投注

 

  • 赌注 1：在构建 MVP 产品时，为最初的几个客户构建它。在探索最初的产品市场契合度时，很容易分心。我们决定只帮助少数高优先级的大容量内部客户，并担心以后扩大客户群。这一决定不仅使我们能够专注于产品的核心。它还让我们意识到不应该投资什么（例如，我们使用电子表格而不是成熟的控制平面来保存每个管道的客户姓名、电子邮件地址和元数据信息，以促进 MVP 阶段的客户部署）。
  • 赌注 2：与技术合作伙伴共同发展，即使不是处于理想的成熟状态，而不是自己重新发明轮子。这样，我们可以共同发展生态系统。我们很早就选择了合作。
    • 流媒体合作伙伴：在外部，我们与领导行业流处理工作的合作伙伴合作，例如 LinkedIn（Kafka 和 Samza 团队）、Confluent、Data Artisan（Apache Flink 背后的构建者，后来更名为 Veverica）。这样做使我们能够在利用社区工作的同时为 OSS 做出贡献以满足我们的需求。
    • 容器化合作伙伴：2015年，还是容器虚拟化技术的初期。我们需要一个快速部署的策略。在内部，我们与新创建的容器基础设施 Titus 团队合作。 Titus 建立在 Apache Mesos 之上，并通过抽象 API 提供计算资源管理、调度和隔离部署。 Titus 后来在 2020 年初演变为利用 K8S，他们的团队设法透明地迁移了所有工作负载。由于这种合作关系，我们在构建数据平台时不必担心低级计算基础设施。
    • 在合作过程中，我们一直保持沟通，分享经验并提供反馈。我们与密切的合作伙伴每两周举行一次同步会议，以调整目标并讨论问题和解决方案。当出现阻塞问题时，合适的人会立即参与进来。
  • 赌注 3：将关注点解耦而不是忽略它们。
  • 运营和分析用例之间的分离问题。我们分别发展了 Mantis（专注于运营）和 Keystone（专注于分析），但创造了空间来连接这两个系统。
    • （Figure: separation of concerns for different stream processing scenarios)
    • 生产者和消费者的关注点分开。我们引入了配备标准化有线协议和简单模式管理的生产者/消费者客户端，以帮助解耦生产者和消费者的开发工作流程。后来证明它是数据治理和数据质量控制的一个重要方面。
    • 分离的组件职责。我们从面向微服务的单一职责原则开始，将整个基础设施划分为 Messaging（流传输）、Processing（流处理）和控制平面（控制平面在这个阶段只是一个脚本，后来演变成一个成熟的系统）。组件职责的分离使团队能够尽早在界面上保持一致，同时通过同时关注不同的部分来释放团队的生产力。
  • 赌注 4：投资于构建一个预期故障并监控所有操作的系统，而不是延迟投资。由于云的弹性、不断变化、故障概率较高的特性，我们需要设计系统来监控、检测和容忍各种故障。故障范围包括网络故障、实例故障、区域故障、集群故障、服务间拥塞和背压、区域灾难故障等。我们在假设故障是恒定的情况下投资构建系统。我们很早就采用了 DevOps 实践：例如针对故障场景的设计、严格的自动化、持续部署、影子测试、自动化监控、警报等。这个 DevOps 基础使我们能够实现一天多次交付的终极工程敏捷性。

(reference: What is Chaos Money in DevOps on Quora)

学习



拥有一个心理安全的失败环境对于任何团队领导变革都是必不可少的。

我们犯了很多错误。我们在产品发布当天惨遭失败，并发生了全公司范围内的事件，导致大量数据丢失。经过调查，事实证明，尽管正确估计了流量增长，但我们构建的庞大的 Kafka 集群（拥有超过 200 个代理）太大并最终达到了其扩展极限。当一个代理死亡时，由于 Kafka（当时）对代理和分区数量的限制，集群无法自行恢复。它最终退化到无法恢复的地步。

以这种规模失败是一次可怕的经历，但由于心理安全的团队环境，我们与所有利益相关者进行了透明的沟通，并将快速的学习转化为永久的解决方案。对于这种特殊情况，我们开发了更细粒度的集群隔离功能（更小的 Kafka 集群 + 隔离的 Zookeeper）来控制爆炸半径。

还有很多其他的失败。当我们挖掘根本原因时，我们意识到我们无法完全预测所有边缘场景，尤其是当我们在托管云上构建时，其中的变化经常超出我们的控制范围，例如实例终止或租户托管，等等。同时，我们的产品被很多人使用，太重要了，不能失败。始终为最坏的情况做好准备已成为一项操作原则。

事件发生后，我们采用了每周一次的 Kafka 集群故障转移演习。每周值班人员都会模拟 Kafka 集群故障。该团队将确保故障转移自动化能够将所有流量迁移到对用户影响最小的健康集群。如果您有兴趣了解有关此练习的更多信息，此视频有更多详细信息。



第 2 阶段：Scale 100s 数据移动用例 (2016)



语境



在交付了最初的 Keystone MVP 并迁移了一些内部客户之后，我们逐渐获得了一些信任，并且消息传到了其他工程团队。流媒体在 Netflix 中获得了发展势头，因为现在可以轻松移动日志以进行分析处理并获得按需运营洞察力。

现在是我们为普通客户扩展的时候了。

(Figure: evolving Keystone architecture diagram, circa 2016. Keystone includes Kafka and Flink engines as its core components. For more technical design details, please refer to blog posts focused on Kafka and Flink)

挑战

 

  • 挑战一：增加运营负担。我们最初为新客户提供白手套协助。然而，随着需求的增长，它很快变得不可持续。我们需要开始发展 MVP 以支持十几个客户。因此，我们需要重新构建一些组件（例如，是时候将电子表格变成适当的数据库支持的控制平面了）。
  • 挑战 2：出现多样化的需求。随着我们收到更多客户要求，我们开始看到非常多样化的需求。有两大类：
    • 一组更喜欢易于使用的完全托管服务。
    • 另一组更喜欢灵活性，需要复杂的计算能力来解决更高级的业务问题，他们可以使用寻呼机，甚至管理一些基础设施。
    • 我们不能同时做好这两件事。
  • 挑战 3：我们破坏了我们接触到的一切。不开玩笑，由于规模的原因，我们在某些时候破坏了几乎所有的依赖服务。我们曾经破坏过 aws S3。我们在 Kafka 和 Flink 中发现了很多 bug。我们多次破坏了 Titus（托管容器基础设施）并发现了奇怪的 CPU 隔离和网络问题。当我们开始以编程方式管理数百个客户部署时，我们打破了 Spinnaker（持续部署平台）。
    • 幸运的是，这些团队也是最好的。他们与我们一起解决了这些问题。这些努力对于成熟整个流媒体生态系统至关重要。

第 2 阶段的流处理模式总结

+-----------------------------------------------------------------+
| Pattern               | Product  | Example Use Cases            |
|-----------------------|----------|------------------------------|
| Data Routing          | Keystone | Logging, Data Movement       |
|                       |          | (+ At scale)                 |
|-----------------------|----------|------------------------------|
| RT Data Sampling/     | Mantis   | Cost-effective RT Insights   |
| Discovery             |          |                              |
|-----------------------------------------------------------------|
| RT Alerts / Dashboard | Mantis,  | SPS Alert,                   |
|                       | Kafka    | + Infrastructure Health      |
|                       |          | Monitoring (Cassandra &      |
|                       |          | Elasticsearch),              |
|                       |          | +RT QoE monitoring           |
+-----------------------------------------------------------------+

策略投注

 

  • 赌注 1：首先关注简单性，而不是向用户暴露基础设施的复杂性。 我们决定首先将重点放在针对一般流用例的高度抽象、完全托管的服务上，原因有二。
    • 它使我们能够处理大多数数据移动和简单的流式 ETL（例如，投影、过滤）用例。 为数据路由提供如此简单、高级别的抽象将使所有 Netflix 组织的工程师能够将数据路由用作与其他平台服务结合的“乐高”构建块。
    • 它将使我们的用户能够专注于业务逻辑。
    • 我们将在以后处理更高级的用例。
  • 赌注 2：投资于完全托管的多租户自助服务，而不是继续使用手动白手套支持。 我们必须专注于自动化控制平面和工作负载部署。 客户工作负载需要完全隔离。 我们决定一个客户的工作量不应该以任何方式干扰另一个客户的工作量。

(Figure: Keystone UI. showing a self-serve drag-n-drop experience powered by a fully managed multi-tenant streaming infrastructure)

  • 赌注 3：继续投资 DevOps，而不是拖延。我们希望根据需要每天多次发布平台更改。我们还认为，有必要让我们的客户能够随时发送更改。部署应在客户启动几分钟后自动完成并安全地投入生产。

学习

 

  • 学习 1：决定不做什么是困难的，但却是必要的。虽然满足客户要求很重要，但有些可能会分散注意力。优先级是第一步，但有意识地决定和沟通要削减的内容更为关键。说不很难。但请注意，说不是暂时的，说是是永久的。
  • 学习 2：注意缩放速度。在最初的产品与市场契合得到验证之后，这是一个激动人心的时刻。然而，过快扩展可能会使团队分心于多个方向，留下大量技术债务，并破坏客户信任。扩展太慢会使团队失去动力，客户需求无法满足太久，也会破坏他们的信任。这是一个微妙的平衡，但这里有一些你可以注意的信号：
    • 软件质量。部署回滚频率是否改变？合作伙伴团队多久阻止一次团队？现在测试失败的频率更高了吗？由于任何系统瓶颈，事件多久发生一次？
    • 客户情绪。客户支持请求的增加是否与用例数量成线性关系？ SLO 违规趋势。客户是否在新功能公告中表现出兴奋？当客户提出“紧急”问题时，他们考虑了哪些替代方案？
    • 运营开销。团队的运营与开发时间比例是否发生变化？ RCA 与事故的比率会改变吗？团队是否因运营劳累而筋疲力尽？团队的创新频率是否发生变化（例如，博客文章、会议演讲）？
  • 学习 3：教育您的用户并耐心纠正误解。围绕数据质量（如事件丢失或重复）或处理语义（如故障场景下的正确性保证）存在许多流处理误解。许多这些误解来自流处理不成熟的旧时代，但已经发展了很多。对你的用户要有耐心，用数据和故事教育他们！

第 3 阶段：支持定制需求并扩展超过 1000 个用例（2017-2019）



语境



在最初推出 Keystone 产品一年后，所有组织的用例数量从 2015 年的不到十几个迅速增加到 2017 年的几百个。此时我们已经建立了坚实的运营基础：客户在待命期间很少收到通知，所有基础设施问题都由平台团队密切监控和处理。我们建立了一个强大的交付平台，帮助我们的客户在几分钟后将变更引入生产。

Keystone 产品非常擅长它最初的设计目标：一个易于使用且几乎可以无限扩展的流数据路由平台。然而，很明显，流处理的全部潜力远未实现。为了满足自定义用例，我们不断发现对复杂处理能力进行更精细控制的新需求，例如流连接、窗口化等。

同时，Netflix 拥有独特的自由和责任文化，每个团队都有权做出自己的技术决策。这种文化使每个团队甚至可以投资定制解决方案。作为一个中央平台团队，我们注意到了这种增长。如果我们没有办法提供保险，这将意味着公司的长期成本很高。

是时候让团队扩大其范围了。我们再次面临一些新的挑战。

挑战

 

  • 挑战 1：自定义用例需要不同的开发人员和运营经验。
    • 我先举两个自定义流处理用例的例子。
    • 计算推荐的流式基本事实。为了让 Netflix 推荐算法提供最佳体验，有必要使用最新数据训练模型。训练模型的输入之一是标签数据集。标签是先前的个性化预测是否准确的直接真实指标。如果用户决定观看一部电影以获得推荐，我们就有了一个肯定的标签。你可以猜到，我们越快得到这个标签数据集，整个 ML 反馈循环就越快。要计算标签，我们需要将展示流和用户点击流连接在一起。但是，用户点击活动通常会延迟到达。例如，用户有时会花几分钟来决定，或者干脆让他们的设备开机而不看几个小时。该用例要求流管道在所有相关信息到达后立即发出标签，但仍能容忍迟到的信息。
    • 计算推荐的比例。 Netflix 提供个性化推荐以优化用户体验。其中之一是选择最佳个性化艺术作品（以及展示它们的最佳位置）的算法，以优化用户参与度。在底层，流处理管道通过在某个自定义窗口上将播放数据流与印象流连接起来，以近乎实时的方式计算该提取分数指标。由于 Netflix 数亿用户群的规模，流媒体作业需要不断检查 1-10 TB 之间的内部状态。
      • (Figure: A/B test to select the best artwork to personalize to the user,
    • 参考：通过 A/B 测试为视频选择最佳艺术品 |由 Netflix 提供）
    • 这些用例涉及更高级的流处理功能，例如复杂的事件/处理时间和窗口语义、允许的延迟、大状态检查点管理。他们还需要围绕可观察性、故障排除和恢复提供更多运营支持。全新的开发人员体验是必要的，包括更灵活的编程接口和操作能力，例如自定义可观察性堆栈、回填能力以及管理 10 TB 本地状态的适当基础架构。我们在 Keystone 中没有这些，我们需要建立一个新的产品入口点，但要尽量减少多余的投资。
  • 挑战 2：在灵活性和简单性之间取得平衡。对于所有新的自定义用例，我们必须找出适当的控制暴露水平。我们可以在更具有挑战性的操作的权衡下一路公开最低级别的 API（因为我们永远无法完全预测用户将如何使用引擎）。或者我们可以选择中途（例如，暴露有限的功能），冒着客户不满意的风险。
  • 挑战 3：操作复杂性增加。支持自定义用例需要我们增加平台的自由度。因此，我们需要在许多复杂场景中提高操作可观察性。同时，随着平台与许多其他数据产品的集成，我们系统的接触点增加，需要与其他团队进行运营协调，以更好地为我们的集体客户服务。
  • 挑战 4：中央平台与本地平台。我们团队的职责是提供一个集中的流处理平台。但是由于之前专注于简单性的策略，一些团队已经使用不受支持的技术在本地流处理平台上进行了投资，例如火花流。我们必须说服他们回到铺好的道路上，因为他们可能会失去平台的影响力，并在多余的投资上浪费资源。现在是我们扩展到自定义用例的正确时机。

第 3 阶段的流处理模式总结

+-----------------------------------------------------------------+
| Pattern               | Product  | Example Use Cases            |
|-----------------------|----------|------------------------------|
| Stream-to-stream Joins| Flink    | Take-fraction computation,   |
| (ETL)                 |          | Recsys label computation     |
|-----------------------|----------|------------------------------|
| Stream-to-table joins | Flink    | Side input: join streams with|
| (ETL)                 |          | slow-moving Iceberg table    |
|-----------------------|----------|------------------------------|
| Streaming Sessionizat-| Flink    | Personalization Sessionizat- |
| ion (ETL)             |          | ion, Metrics sessionization  |
|-----------------------|----------|------------------------------|
| RT Observability      | Mantis   | Distributed tracing,         |
|                       |          | Chaos EXPER monitoring,      |
|                       |          | Application monitoring       |
|-----------------------|----------|------------------------------|
| RT Anomaly / Fraud    | Mantis,  | Contextual alert,            |
| Detection             | Flink    | PII detection,               |
|                       |          | Fraudulent login prevention  |
|-----------------------|----------|------------------------------|
| RT DevOps Decision    | Mantis   | Autoscaling,                 |
| Tool                  |          | Streaming ACA & A/B tests,   |
|                       |          | CDN placement optimization   |
|-----------------------|----------|------------------------------|
| Event Sourced         | Flink    | Content Delivery Network     |
| Materialized View     |          | snapshotting                 |
+-----------------------+----------+------------------------------+

策略投注

 

  • 赌注 1：构建新产品入口点但重构现有架构，而不是孤立地构建新产品。 在分析处理方面，我们决定从原始架构中衍生出一个新平台，以利用 Apache Flink 展示流处理的全部功能。 我们将从头开始创建一个新的内部客户群，但我们也认为现在是重构架构以最小化冗余投资（在 Keystone 和 Flink 平台之间）的正确时机。 在这个新架构中，较低的 Flink 平台同时支持 Keystone 和自定义用例。
    • (Figure: Architecture splitting Flink Platform as a separate product entry point)
  • 赌注 2：从流式 ETL 和可观察性用例开始，而不是一次性处理所有自定义用例。有很多机会，但我们决定专注于分析方面的流式 ETL 用例和操作方面的实时可观察性用例。由于其复杂性和规模，这些用例最具挑战性。为了展示流处理的全部力量，我们首先解决最困难的问题并从中学习是有意义的。
  • 赌注3：最初与客户分担运营责任，随着时间的推移逐渐共同创新以减轻负担。我们很幸运，我们的早期采用者能够自给自足，而且每当客户遇到困难时，我们也会提供白手套支持模式。我们逐渐扩大了运营投资，例如自动扩展、托管部署、智能警报、回填解决方案等。

学习

 

  • 学习 1：支持新的自定义用例的新产品入口点是必要的演进步骤。这也是一个重新架构/重构并融入现有产品生态系统的机会。不要被引诱去孤立地构建一个新系统。避免第二系统效应。
  • 学习 2：简单性吸引了 80% 的用例。灵活性有助于更大的用例。回顾过去，这些是过去几年对实际客户群的观察。我想在这里向读者传达的一点是，在支持大多数用例或影响更大的用例之间进行优先级排序，都取决于具体情况。这个论点可以双向进行，但您应该阐明适合您的业务场景的推理。
    • 简单性和灵活性不是光谱的两个极端。这是一个封闭的创新反馈循环。灵活性的力量将推动与一小部分客户进行新的联合创新。一开始，这些创新可能会更昂贵，但在被证明之后，价值最终可能会变成商品并回到简化的体验。由于这些新价值有助于不断增长的客户，一小部分新用户将再次要求灵活性的力量。
  • 学习 3：善待你的早期采用者。他们是最忠实的客户，会免费为您做营销。感谢我们早期采用者的认可，我们的用例在此阶段激增至数千个。
  • 学习 4：当事情破裂时，不要惊慌。相信你周围的所有人。如果您已经有一个支持该产品的社区，则可以加分。我记得有一次我们经历了整个平台的缓慢退化。每天，我们都会收到大量的页面，而我们在两周内都无法找出根本原因。这太可怕了，团队很痛苦，客户也很痛苦。但是该团队能够跨越团队边界一起工作，让具有正确专业知识的人参与进来，使用数据对症状进行逻辑推理。最终，我们在 Linux 内核中发现了一个错误，该错误导致特定于流式工作负载的缓慢内存泄漏。我们必须信任所有相关人员，有时即使我们并不具备所有专业知识！

第 4 阶段：扩展流处理职责——未来的挑战和机遇（2020 年至今）

(Figure: how stream processing fits in Netflix — 2021)

语境



随着流处理用例扩展到 Netflix 中的所有组织，我们发现了新模式，并享受了早期的成功。但现在不是自满的时候。

作为一家企业，Netflix 继续探索新领域，并在内容制作工作室以及最近在游戏方面进行了大量投资。出现了一系列新挑战，我们开始着手解决这些有趣的问题空间。



挑战

 

  • 挑战一：多样化的数据技术使协调变得困难。由于团队被授权，Netflix 的许多团队都在使用各种数据技术。比如事务端：有Cassandra、MySQL、Postgres、CockroachDB、分布式缓存等；分析端：有Hive、Iceberg、Presto、Spark、Pig、Druid、Elasticsearch等。相同的数据通常存储在 Netflix 数据生态系统内的不同数据存储中。
    • 有很多选择可供选择，将技术放在不同的桶中是人类的天性。批处理与流式处理。事务性存储与分析性存储。在线处理与离线处理。这些都是数据世界中经常争论的话题。重叠的划分边界通常会给最终用户增加更多的困惑。
    • 如今，跨技术边界协调和处理数据极具挑战性。边界难以通过划分边界来推动。
  • 挑战 2：更陡峭的学习曲线。随着可用数据工具数量的不断增加和专业化程度的不断加深，用户学习和决定哪些技术适合特定用例是一项挑战。
  • 挑战 3：ML 实践没有利用数据平台的全部功能。前面提到的所有挑战都会对 ML 实践造成影响。数据科学家的反馈循环很长，数据工程师的生产力受到影响，产品工程师在共享有价值的数据时面临挑战。最终，许多企业失去了适应瞬息万变的市场的机会。
  • 挑战 4：中央平台模型的规模限制。由于中央数据平台以超线性的速度扩展用例，单点联系支持是不可持续的。现在是评估中央平台支持本地中央平台以增加杠杆作用的模型的正确时机（这意味着我们将优先支持构建在我们平台之上的本地平台）。

机会

 

我将在这部分相对简短，并在以后的博客文章中扩展细节。

  • 使用流连接世界。对于流处理而言，除了低延迟处理的优势外，它在现代数据平台中越来越显示出更为关键的优势：连接各种技术并实现流畅的数据交换。变更数据捕获 (CDC)、流式物化视图和数据网格概念等技术越来越受欢迎。最后，Martin Kleppmann 在 2015 年提出的“彻底颠覆数据库”的愿景开始实现其价值。
  • 通过结合最好的简单性和灵活性来提高抽象性。了解各种数据技术的深层内部原理很有价值，但并不是每个人都需要这样做。随着云优先的数据基础设施正在成为商品，这种思路尤其正确。适当提升数据基础设施抽象化成为让更广泛的受众轻松访问所有高级功能的直接机会。流式 SQL 等技术将降低准入门槛，但这仅仅是开始。数据平台还应提高对最终用户不可见的划分边界（例如，流式与批处理）的抽象。

(Figure: the sweet spot between simplicity and flexibility)

  • 机器学习需要来自现代数据平台的更多爱。 在所有开发人员角色中，ML 人员可以说是对业务影响最大和服务最不足的群体。 所有 ML 平台都依赖于数据存储和处理。 因此，Data Platform 有很多机会向 ML 世界伸出援助之手：例如数据质量、可靠性和可扩展性、开发到产品的反馈循环、实时可观察性、整体效率等。

第 4 阶段的流处理模式总结

+-----------------------------------------------------------------+
| Pattern               | Product  | Example Use Cases            |
|-----------------------|----------|------------------------------|
| Streaming Backfill /  | Flink    | Pipeline Failure mitigation, |
| Restatement           |          | Avoid cold start             |
|-----------------------|----------|------------------------------|
| Data Quality Control  | Keystone,| Schema evolution management, |
|                       | Flink    | Data Quality SLA,            |
|                       |          | Cost reduction via Avro      |
|                       |          | compression                  |
|-----------------------|----------|------------------------------|
| Source/Sink Agnostic  | Keystone,| Delta, Data Mesh,            |
| Data Synchronization  | Flink    | Operational reporting,       |
|                       |          | Notification,                |
|                       |          | Search Indexing Pipeline     |
|-----------------------|----------|------------------------------|
| Near-real-time (NRT)  | Flink    | Customer service recommend-  |
| Inference             |          | ation, Intent-based in-      |
|                       |          | session adaptations          |
|-----------------------|----------|------------------------------|
| Streaming SQL         | Flink    | Dynamic feature Engineering  |
|-----------------------|----------|------------------------------|
| Intelligent Operation | 4        | Auto-diagnosis & remediation |
+-----------------------+----------+------------------------------+

下一个前沿是什么



谢谢你走到这一步。这篇博文描述了在 Netflix 构建流处理基础设施的高级迭代之旅。我很想听听您对有趣之处的反馈，以便我可以跟进未来的博客文章。



根据设计，我在这篇文章中省略了许多技术细节。但如果您有兴趣了解更多信息，请参阅附录部分，了解 Netflix 中所有流处理创新的完整时间线视图。



我对数据基础设施的未来感到非常兴奋，尤其是支持更好的机器学习体验。我相信这是我们要大胆前行的下一个前沿！如果你感兴趣，我强烈推荐我的好朋友兼同事 Chip 的优秀读物“实时机器学习：挑战和解决方案”。



我也很高兴地宣布，我将与 Chip Huyen 一起开始新的旅程，在流媒体优先的机器学习平台上工作。我们还很早，我们正在寻找一位创始基础设施工程师，共同塑造未来！如果您有兴趣，我们很乐意收到您的来信！

如果这篇博文引起您的共鸣，请联系我们。我想连接！

附录



Netflix 中的流处理模式

+-----------------------------------------------------------------+
| Pattern               | Phase    | Example Use Cases            |
|-----------------------|----------|------------------------------|
| Data Routing          | 1        | Logging, Data Movement       |
|-----------------------|----------|------------------------------|
| RT Alerts / Dashboard | 1, 2     | SPS Alert,                   |
|                       |          | Infrastructure Health        |
|                       |          | Monitoring (Cassandra &      |
|                       |          | Elasticsearch),              |
|                       |          | RT QoE monitoring            |
+-----------------------------------------------------------------+
| RT Data Sampling/     | 2        | Cost-effective RT Insights   |
| Discovery             |          |                              |
|-----------------------------------------------------------------|
| Stream-to-stream Joins| 3        | Take-fraction computation,   |
| (ETL)                 |          | Recsys label computation     |
|-----------------------|----------|------------------------------|
| Stream-to-table joins | 3        | Side input: join stream with |
| (ETL)                 |          | slow-moving Iceberg table    |
|-----------------------|----------|------------------------------|
| Streaming Sessionizat-| 3        | Personalization Sessionizat- |
| ion (ETL)             |          | ion, Metrics sessionization  |
|-----------------------|----------|------------------------------|
| RT Observability      | 3        | Distributed tracing,         |
|                       |          | Chaos EXPER monitoring,      |
|                       |          | Application monitoring       |
|-----------------------|----------|------------------------------|
| RT Anomaly / Fraud    | 3        | Contextual alert,            |
| Detection             |          | PII detection,               |
|                       |          | Fraudulent login prevention  |
|-----------------------|----------|------------------------------|
| RT DevOps Decision    | 3        | Autoscaling,                 |
| Tool                  |          | Streaming ACA & A/B tests,   |
|                       |          | CDN placement optimization   |
|-----------------------|----------|------------------------------|
| Event Sourced         | 3        | Content Delivery Network     |
| Materialized View     |          | snapshotting                 |
| Streaming Backfill /  |          | Pipeline Failure mitigation, |
| Restatement           |          | Avoid cold start             |
|-----------------------|----------|------------------------------|
| Data Quality Control  | 4        | Schema evolution management, |
|                       |          | Data Quality SLA,            |
|                       |          | Cost reduction via Avro      |
|                       |          | compression                  |
|-----------------------|----------|------------------------------|
| Source/Sink Agnostic  | 4        | Delta, Data Mesh,            |
| Data Synchronization  |          | Operational reporting,       |
|                       |          | Notification,                |
|                       |          | Search Indexing Pipeline     |
|-----------------------|----------|------------------------------|
| Near-real-time (NRT)  | 4        | Customer service recommend-  |
| Inference             |          | ation, Intent-based in-      |
|                       |          | session adaptations          |
|-----------------------|----------|------------------------------|
| Streaming SQL         | 4        | Dynamic feature Engineering  |
|-----------------------|----------|------------------------------|
| Intelligent Operation | 4        | Auto-diagnosis & remediation |
+-----------------------+----------+------------------------------+

References

Indexed in chronological order …

原文：https://zhenzhongxu.com/the-four-innovation-phases-of-netflixs-trillion…

本文：https://jiagoushi.pro/node/2066

  • 168 次浏览
SEO Title
The Four Innovation Phases of Netflix’s Trillions Scale Real-time Data Infrastructure