挑战
- 挑战 1：自定义用例需要不同的开发人员和运营经验。
- (Figure: A/B test to select the best artwork to personalize to the user,
- 我先举两个自定义流处理用例的例子。
- 计算推荐的流式基本事实。为了让 Netflix 推荐算法提供最佳体验，有必要使用最新数据训练模型。训练模型的输入之一是标签数据集。标签是先前的个性化预测是否准确的直接真实指标。如果用户决定观看一部电影以获得推荐，我们就有了一个肯定的标签。你可以猜到，我们越快得到这个标签数据集，整个 ML 反馈循环就越快。要计算标签，我们需要将展示流和用户点击流连接在一起。但是，用户点击活动通常会延迟到达。例如，用户有时会花几分钟来决定，或者干脆让他们的设备开机而不看几个小时。该用例要求流管道在所有相关信息到达后立即发出标签，但仍能容忍迟到的信息。
- 计算推荐的比例。 Netflix 提供个性化推荐以优化用户体验。其中之一是选择最佳个性化艺术作品（以及展示它们的最佳位置）的算法，以优化用户参与度。在底层，流处理管道通过在某个自定义窗口上将播放数据流与印象流连接起来，以近乎实时的方式计算该提取分数指标。由于 Netflix 数亿用户群的规模，流媒体作业需要不断检查 1-10 TB 之间的内部状态。
- 参考：通过 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 |
+-----------------------+----------+------------------------------+
