作者丨George Anadiotis
编译丨布加迪
审校丨孙淑娟、梁策
Netflix 是怎么成功的?Investopedia 网站给出了三个答案：引人入胜的原创节目制作，针对订阅服务而开展的用户数据分析，以及允许用户以自己喜爱的方式进行内容消费。
可能这三点大多数人都同意。不过，Netflix 通过用户数据和运营数据分析来提高订阅用户服务水平，这方面背后的故事却可能鲜为人知。Zhenzhong Xu 表示，在 Netflix 全球高速发展时期，业务和运营决策比任何时候都依赖更快速的日志数据。
Xu 在 2015 年加入 Netflix，担任实时数据基础架构团队的创始工程师，后来领导流处理引擎团队。他在 2010 年代初对实时数据产生兴趣，从那时起就认为这个领域大有可为。
Xu 于近期离开了 Netflix，开始在实时机器学习领域谋求发展。对于 Netflix 实时数据基础架构的开发之旅，Xu 认为从 2015 到 2021 年是一段迭代过程。他将这段旅程分为四个阶段：
第一阶段：从失败的批处理管道中拯救 Netflix 日志(2015 年)
第一阶段涉及从失败的批处理管道中拯救 Netflix 日志。在这个阶段，Xu 的团队从头开始构建了一个流优先平台，以取代失败的管道。
Xu 及其团队负责集中管理底层基础架构，以提供赋能机制，从而使产品团队能够专注于业务逻辑。
2015 年，Netflix 已经拥有约 6000 万订阅用户，并积极拓展全球影响力。平台团队知道，迅速扩大平台影响力将是保持订阅用户迅猛增长的关键。
其中一个紧迫任务是 Xu 的团队必须弄清楚如何帮助 Netflix 扩展日志实践。当时，Netflix 拥有 500 多个微服务，每天生成的数据量超过 10PB。
通过收集这些海量数据，Netflix 获得了两种认知。首先，这有助于了解业务分析(比如用户保留、平均会话长度和趋势等)。其次，这有助于了解运营层面(比如测量每秒流媒体播放量，以快速轻松地了解 Netflix 系统的健康状况)，从而让开发人员可以发出警报或执行缓解措施。
Xu 表示，数据必须从生成数据的边缘转移到某个分析存储区。所有数据人员都知道这么做的原因：微服务是为满足运营需求而建的，并使用联机事务处理(OLTP)存储。分析工具则需要联机分析处理(OLAP)。
使用 OLTP 存储来分析效果欠佳，还会降低那些服务的性能。因此，需要以低延迟的方式可靠地移动日志。到 2015 年，Netflix 的日志量已从 2011 年 450 亿个事件 / 每天增加到 5000 亿个事件 / 每天(数据摄取量达 1PB)。
现有的日志基础架构是一个简单的批处理管道平台，它用 Chukwa、Hadoop 和 Hive 构建，面对每周订阅用户数量增加的现状，很快就难以招架。Xu 的团队只有六个月左右的时间来开发流优先解决方案，更为糟糕的是，他们只有六名团队成员来完成任务。
此外，Xu 特别指出了当时流数据生态系统还不成熟的情况。很少有科技公司能在 Netflix 需要的那种规模下成功地部署流优先解决方案，因此团队必须评估技术选项和试验方案，并决定构建什么系统、看好哪些新兴工具。
正是在那几年，他们为 Netflix 的一些自主开发的产品(比如 Keystone 和 Mantis)打下了基础。这些产品后来自立门户，其中 Mantis 后来还开源了。
第二阶段：扩展到数百个数据移动用例(2016 年)
早期做出的一个关键决策是，分离问题而不是忽视问题。Xu 的团队通过单独完善 Mantis(以运营为重点)和 Keystone(以分析为重点)，将运营用例和分析用例方面的问题分开来，但又为这两个系统的对接留有余地。
他们还将内容生产者和消费者方面的问题分开来。为此，他们引入了生产者 / 消费者客户软件，配备标准化有线协议和简单模式管理，帮助分离生产者和消费者的开发工作流程。后来证明这是数据治理和数据质量控制的一个重要方面。
团队从面向微服务的单一职责原则入手，将整套基础架构分为消息传递(流传输)、处理(流处理)和控制平面。分离组件职责让该团队能够尽早确保界面一致，同时又通过关注不同的部分来释放生产力。
除了资源限制和不成熟的生态系统外，团队最初还不得不面对这个事实：分析问题和运营问题不一样。分析型流处理专注于正确性和可预测性，运营型流处理更专注于成本效益、延迟和可用性。
此外，对有状态数据的平台来说，云原生弹性问题有些棘手。在第一阶段开始时，Netflix 已经在 AWS 云上运行了几年。但是，它是首家将有状态数据平台搬到容器化云基础架构上的公司，这带来了巨大的技术挑战。
在交付最初的 Keystone 最简可行产品(MVP)并迁移几个内部客户之后，Xu 的团队逐渐获得了信任，也得到其他工程团队认可。因为很容易移动日志用于分析处理、根据需要获得运营洞察力，流媒体在 Netflix 受到追捧。现在是时候为普通客户扩展规模了，而这带来了一系列新的挑战。
第一个挑战是运营负担加重。最初他们为新用户提供细致入微的协助，但是随着需求激增，这很快难以为继。MVP 不得不与时俱进，只支持十几个客户是不够的。
第二个挑战是出现了多样化需求，出现了两大客户群。一群更喜欢易于使用的完全托管服务，另一群更爱灵活一些，需要复杂的计算能力来解决更高级的业务问题。Xu 指出，这两大客户群的需求很难同时兼顾。
第三个挑战是，由于规模庞大，团队几乎一度中断了所有依赖的服务：从亚马逊的 S3 到 Apache Kafka 和 Apache Flink，不一而足。不过，之前做出的战略性选择之一是，要与技术合作伙伴共同发展，即使状态并不理想成熟。
这些伙伴包括业内许多领导流处理工作的品牌，比如领英，Apache Kafka 和 Samza 两大项目正是诞生于此，Kafka 也由他们商业化;此外还有更名为 Ververica 的 Data Artisans，他们将 Apache Flink 商业化。
选择合作途径使团队能够在利用社区成果的同时，按需求为开源软件做贡献。该团队在应对与容器化云基础架构相关的挑战方面与 Titus 团队进行了合作。
Xu 还详述了早期做出的更多关键决策，比如构建专注几个早期客户的 MVP 产品。在探索最初的产品市场契合时，一不留神就会分心。然而，他们决定帮助几个高优先级、数据需求量大的内部客户，以后再考虑扩大客户群。
第三阶段：支持定制需求，扩展海量用例(2017 年 – 2019 年)
在整个第二阶段，Xu 的团队再度做出了一些关键决策，这对他们大有助益。
他们选择先专注于简单性，而不是将基础架构的复杂性暴露在用户面前，因为这让团队能够支持大多数数据移动和简单的流式 ETL 用例，同时使用户能够专注于业务逻辑。
他们决定投入完全托管的多租户自助服务，而不是继续提供细致入微的人工支持。在第一阶段，他们选择投入于构建一个预料故障，并监测所有运营的系统，而不是延迟投入。在第二阶段，他们继续投入于 DevOps，旨在根据需要每天多次发布平台变更。2017 年左右，团队认为已建立了稳固的运营基础：客户很少在他们待命期间收到通知，所有基础架构问题都由平台团队密切监控和处理。强大的交付平台已实施到位，在几分钟内就能帮助客户将变更引入生产环境。
Xu 特别指出，他们推出的 Keystone 产品在实现最初设想上非常出色：已成为一个易于使用、几乎可以无限扩展的流数据路由平台。不过，很明显流处理的潜力远未全部发挥出来。Xu 的团队不断碰到新需求，需要对复杂的处理能力拥有更精细化的控制。Xu 写道，Netflix 有独特的自由和责任文化，每个团队有权做出自己的技术决策。该团队决定扩大平台的范围，同时在此过程中遇到了一些新的挑战。
第一个挑战是自定义用例需要不同的开发者和运营体验。比如说，Netflix 推荐的对象可以包括接下来要观看的内容、个性化的艺术作品，以及最佳展示区域等一系列内容。
这些用例需要更高级的流处理功能，比如复杂的事件 / 处理时间和窗口语义、允许的延迟和大状态检查点管理。它们还需要更多的运营支持、更灵活的编程接口以及能够管理 TB 数据中本地状态的基础架构。
第二个挑战是兼顾灵活性和简单性。针对所有新的自定义用例，团队必须对暴露水平进行合理控制。此外，支持自定义用例要求增加平台的自由度，而这也是第三个挑战：运营复杂性增加。
最后，团队的职责是提供一个集中式流处理平台。但由于之前的策略专注于简单性，一些团队已使用不受支持的技术投入到了他们的本地流处理平台——用 Netflix 的话来说，就是“舍近求远”。Xu 的团队不得不说服他们搬回到托管平台。这也是第四个挑战：集中平台与本地平台之争。
在第三阶段，Flink 被引入进来，由 Xu 的团队管理。他们决定构建一个新的产品入口点，这是对现有架构的重构，而不是孤立地构建新产品。Flink 充当这个入口点，重构有助于尽量减少冗余问题。
另一个关键决策是先从流式 ETL 和可观察性用例入手，而不是一次性处理所有自定义用例。由于这些用例难度大、规模大，极具挑战性，Xu 认为先处理最困难的用例并从中汲取经验是明智之举。
这时候做出的最后一个关键决策是，一开始与客户分担运营责任，然后随着时间的推移，逐渐共谋创新，以减轻负担。早期采用者自给自足，细致入微的支持帮助了那些无法做到的人。久而久之，自动扩展和托管部署等运营投入也相继到位。
第四阶段：扩大流处理方面的职责(2020 年至今)
随着流处理用例扩展到 Netflix 的所有部门，人们发现了全新模式，团队也获得了早期的成功。但随着 Netflix 继续探索新领域，并大力投入于内容制作和游戏上，一系列新的挑战随之而来。
第一个挑战是团队自治的弊端。由于团队有权做出自己的决定，因此 Netflix 许多团队使用的数据技术各种各样，迥异的数据技术使协调变得困难。Xu 写道，有许多技术可供选择，人们自然会将技术分门别类，而有分类的存在就会阻碍组织往前推进。第二个挑战是学习难度更大。由于可用的数据工具越来越多，专业化程度不断加深，用户学习和决定什么技术适合特定的用例显得困难重重。
Xu 特别指出，第三个挑战是机器学习实践没有充分发挥数据平台的力量。所有上述的挑战都会对机器学习实践造成影响。数据科学家的反馈环路很长，数据工程师的生产力受到影响，产品工程师在共享有价值的数据方面遇到了挑战。最终，许多企业失去了抓住市场瞬息变化的大好机会。
第四个挑战是中央平台模型的规模限制。Xu 特别指出，由于中央数据平台以超线性的速度扩展用例，使用单一联系点来支持是无以为继的。应评估注重支持构建在中央平台上的本地平台的模式，现在正是最佳时机。
Xu 在此过程中汲取了宝贵的经验，一些经验可能产品负责人也很熟悉，并适用于流数据之外的领域。比如营造失败也没有关系的氛围、决定不开发什么内容、鼓励用户成为平台忠粉，以及在压力下保持镇静。有兴趣的读者可以参阅(https://zhenzhongxu.com/the-four-innovation-phases-of-netflixs-trillions-scale-real-time-data-infrastructure-2370938d7f01)。
在第四阶段及之外，Xu 也看到了实时数据处理的特殊机会。数据流可以连接世界，并可以通过结合简单性和灵活性来提高抽象性，更好地满足机器学习的需求。
