作者丨GeorgeAnadiotis编译丨布加迪评测丨孙淑娟、梁策Netflix是如何成功的？Investopedia网站给出了三个答案：引人入胜的原创节目、订阅服务的用户数据分析、以及让用户以自己喜欢的方式消费内容。对于这三点，大多数人可能都认同。然而，Netflix利用用户数据和运营数据分析来提升订阅者服务水平的背后故事可能鲜为人知。许振中表示，在Netflix全球快速发展时期，业务和运营决策比以往任何时候都依赖更快的日志数据。徐于2015年作为实时数据基础设施团队的创始工程师加入Netflix，后来领导流处理引擎团队。他在2010年代初开始对实时数据产生兴趣，并从那时起就认为该领域很有前途。Xu最近离开Netflix，开始从事实时机器学习方面的工作。对于Netflix实时数据基础设施的发展历程，许认为，从2015年到2021年是一个迭代的过程。他将此旅程分为四个阶段：第1阶段：从失败的批处理管道中拯救Netflix日志(2015)第1阶段涉及从失败的批处理管道中拯救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构建的简单批处理管道平台，很快就被越来越多的每周订阅者所淹没。徐的团队只有大约六个月的时间来开发流程优先的解决方案，更糟糕的是，他们只有六名团队成员才能完成任务。此外，徐还特别指出了当时流数据生态系统的不成熟。很少有科技公司能够以Netflix所需的规模成功部署流优先解决方案，因此该团队必须评估技术选项和实验场景，并决定构建哪些系统以及支持哪些新兴工具。正是在那些年里，他们为Netflix的一些本土产品（如Keystone和Mantis）奠定了基础。这些产品后来都建立了自己的门户，Mantis后来也开源了。第二阶段：扩展到数百个数据移动用例(2016)早期做出的一个关键决定是隔离问题而不是忽略它。Xu的团队通过分别改进Mantis（以运营为中心）和Keystone（以分析为中心）来分离运营用例和分析用例的关注点，但为两个系统的交互留出了空间。他们还将内容生产者和消费者方面的问题分开。为此，他们推出了具有标准化线路协议和简单模式管理的生产者/消费者客户端软件，有助于分离生产者和消费者的开发工作流程。这后来被证明是数据治理和数据质量控制的一个重要方面。团队从微服务单一职责的原则出发，将整个基础架构分为消息（流）、处理（流）和控制平面。分离组件职责使团队能够尽早确保一致的界面，同时通过专注于不同的部分来释放生产力。除了资源限制和不成熟的生态系统之外，团队最初不得不面对这样一个事实，即分析问题与运营问题不同。分析型流处理侧重于正确性和可预测性，操作型流处理更侧重于成本效益、延迟和可用性。此外，云原生弹性问题对于具有状态数据的平台来说有些棘手。在第1阶段开始时，Netflix已经在AWS云上运行了数年。然而，它是第一家将有状态数据平台迁移到容器化云基础设施的公司，这带来了重大的技术挑战。在交付最初的Keystone最小可行产品(MVP)并迁移了几个内部客户后，Xu的团队逐渐获得了其他工程团队的信任和支持。流媒体在Netflix变得流行，因为它很容易移动日志进行分析处理，根据需要获得运营洞察力。现在是为普通客户扩展规模的时候了，这带来了一系列新的挑战。第一个挑战是增加的运营负担。最初，他们为新用户提供细致入微的帮助，但随着需求激增，这很快就变得不可持续了。MVP必须与时俱进，支持十几个客户是不够的。第二个挑战是多样化需求的出现和两大客户群体的出现。一组人更喜欢完全托管服务的易用性，而另一组人则更喜欢稍微灵活一些，并且需要复杂的计算能力来解决更高级的业务问题。徐指出，很难同时兼顾这两个客户群的需求。第三个挑战是，由于其庞大的规模，该团队一度中断了它所依赖的几乎所有服务：从亚马逊的S3到ApacheKafka和ApacheFlink。然而，早期做出的战略选择之一是与技术合作伙伴一起成长，即使他们并不理想成熟。这些合作伙伴包括很多在业界引领流处理的品牌，比如LinkedIn，ApacheKafka和Samza两大项目就诞生于此，Kafka也被他们商业化；此外，还有DataArtisans，更名为Ververica，将ApacheFlink商业化。选择协作路径使团队能够在利用社区努力的同时按需为开源软件做出贡献。该团队与Titus团队合作应对与容器化云基础设施相关的挑战。Xu还详细介绍了早期做出的更多关键决策，例如构建专注于少数早期客户的MVP产品。在探索最初的产品市场契合度时，很容易分心。然而，他们决定帮助一些高优先级、急需数据的内部客户，并考虑在以后扩大他们的客户群。阶段3：支持自定义需求，扩展海量用例（2017-2019）在整个阶段2中，徐的团队再次做出了一些对他们有很大好处的关键决策。他们没有将基础设施的复杂性暴露给用户，而是选择首先关注简单性，因为这让团队能够支持大多数数据移动和简单的流式ETL用例，同时让用户专注于业务逻辑。他们没有继续提供细致入微的人工支持，而是决定投资于完全托管的多租户自助服务。在第一阶段，他们选择投资构建一个预测故障并监控所有操作的系统，而不是延迟投资。在第二阶段，他们继续投资于DevOps，目标是每天根据需要多次发布平台变更。2017年左右，该团队感到稳固的运营基础已经到位：客户在待命期间很少收到通知，所有基础设施问题都由平台团队密切监控和处理。强大的交付平台已到位，可帮助客户在几分钟内将变更投入生产。Xu特别指出，他们的Keystone产品在实现其最初愿景方面做得非常出色：一个易于使用、几乎可以无限扩展的流数据路由平台。然而，很明显，流处理的全部潜力远未实现。徐的团队不断遇到新的需求，需要对复杂的处理能力进行更细粒度的控制。徐写道，Netflix拥有独特的自由和责任文化，每个团队都有权做出自己的技术决策。该团队决定扩大平台的范围，同时遇到一些新的挑战。第一个挑战是自定义用例需要不同的开发人员和运营经验。例如，Netflix的推荐范围可以从观看内容到个性化艺术作品到展示它们的最佳地点。这些用例需要更高级的流处理功能，例如复杂的事件/处理时间和窗口语义、允许的延迟和大型状态检查点管理。他们还需要更多的操作支持、更灵活的编程接口以及能够跨TB数据管理本地状态的基础设施。第二个挑战是平衡灵活性和简单性。对于所有新的自定义用例，团队必须合理控制曝光级别。此外，支持自定义用例需要增加平台自由度，这是第三个挑战：增加操作复杂性。最后，团队的作用是提供一个中心化的流处理平台。但由于之前的策略侧重于简单性，一些团队已经致力于使用不受支持的技术来支持他们的原生流媒体平台——“用Netflix的话说，‘远方求索’。”徐的团队不得不说服他们回到托管平台。这是还有第四个挑战：中心化平台和本地平台的较量。在第三阶段，Flink由徐的团队引入和管理。他们没有孤立地构建新产品，而是决定构建一个新的产品切入点，这是一个现有架构的重构。Flink作为这个切入点，重构有助于最小化冗余问题。另一个关键决定是首先从流式ETL和可观察性用例开始，而不是一次解决所有自定义用例。由于这些用例的难度、规模和挑战，徐觉得首先解决最困难的问题并从中学习是明智的。此时要做出的最终关键决定是最初与客户分担运营责任，然后随着时间的推移，逐步协作创新以减轻负担。早期采用者是自给自足的，细致入微的支持帮助那些不能自给自足的人。随着时间的推移，自动扩展和托管部署等运营投资也已经到位。阶段4：流处理职责的扩展（2020年至今）随着流处理用例扩展到Netflix的所有部门，发现了新的模式并且团队看到了早期的成功。但随着Netflix继续探索新领域并在内容制作和游戏方面投入巨资，一系列新的挑战也随之而来。第一个挑战是团队自治的缺点。由于团队有权做出自己的决定，Netflix的许多团队使用各种数据技术，而不同的数据技术使得协调变得困难。徐写道，有这么多技术可供选择，人们自然而然地对技术进行分类，而类别的存在阻碍了组织向前发展。第二个挑战是学习难度更大。随着可用数据工具数量的增加和专业化程度的提高，用户很难学习和决定哪种技术适合特定用例。Xu特别指出，第三个挑战是机器学习实践没有充分利用数据平台的力量。所有上述挑战都对机器学习实践有影响。数据科学家的反馈循环很长，数据工程师的生产力受到影响，产品工程师面临共享有价值数据的挑战。最终，很多企业失去了抓住瞬息万变的市场的大好机会。第四个挑战是中央平台模型的规模限制。特别是，Xu指出，由于中央数据平台以超线性速率扩展用例，因此通过单点联系来支持它们是不可持续的。现在是评估专注于支持在中央平台上构建的本地平台的模型的最佳时机。Xu在此过程中吸取了宝贵的教训，其中一些可能为产品所有者所熟悉，并且适用于流数据之外的领域。比如营造一种可以失败的氛围，决定哪些内容不开发，鼓励用户成为平台的忠实粉丝，在压力下保持冷静。感兴趣的读者可以参考（https://zhenzhongxu.com/the-four-innovation-phases-of-netflixs-trillions-scale-real-time-data-infrastructure-2370938d7f01）。在第4阶段及以后，徐还看到了实时数据处理的特殊机会。数据流可以连接世界，并可以通过结合简单性和灵活性来提高抽象性，以更好地满足机器学习的需求。
