回顾经典，Netflix的推荐系统架构

这里是「王喆的机器学习笔记」的第三十一篇文章。最近因为忙着书出版和DLP-KDD Workshop的事情，没太多时间更新专栏，等过了这段时间再跟大家多聊聊。

这篇文章我们回顾一篇经典博客，Netflix官方博客介绍的推荐系统架构，虽然文章发布已有六年， 但是现在回看起来我自己还是蛮惊讶的，因为Netflix的推荐系统架构居然到现在依然是主流。

当然，框架中的诸多技术在不断的迭代更新，因为近期与Netflix的很多同行有过交流，也可以更新一下框架中一些模块的最新进展。

Netflix推荐系统架构图

Netflix推荐系统架构图

Netflix的推荐系统从上至下依次分为离线（offline）、近线（nearline），在线（online）三部分。

离线（offline）

存储离线数据，利用大数据查询工具进行数据查询和处理，离线模型训练。离线部分对于数据数量和算法复杂度限制很少，以批量方式完成数据处理，但是数据处理的实时性非常差，无法做到数据和模型的即使更新。

可以看到当时还是hive，pig等工具的天下，现在spark 是主流，但也有越来越多的offline job被合并到near line之中，可以说当前的offline和nearline的界限日渐模糊了。

近线（near line）

基于数据消息队列，利用一些流计算平台进行数据的准实时处理。它居于离线和在线之间，既可以以分钟级别甚至秒级的延时来准实时地处理数据，也有一定的数据批量处理能力。

nearline可以说是近几年大数据架构发展的重中之重了。当时Netflix开发了自己的流处理框架Manhattan，但现在已经是Flink一统天下的时候，Netflix内部的Flink平台每天会运行上千个不同的流处理任务。涵盖了特征实时计算、数据监控、BI、模型实时训练等等。越来越多的offline任务被替代，也许Kappa架构彻底替代Lambda架构的日子不太远了。

在线（online）

online部分的主要任务是进行用户请求的实时处理，模型的在线服务。在线部分需要更快地响应最近的事件和用户交互，因此对于延迟的要求比较苛刻，一般都要求在100ms以内完成所有处理，这会限制所用算法的复杂性和可处理的数据量。

正是online部分极高的响应延迟要求和相比离线、近线较弱的数据处理能力，要求online部分采用不同的高效的model serving方法去支持个性化推荐服务。这也是前段时间我们专栏花了几篇文章介绍model serving的原因。

从阿里的User Interest Center看模型线上实时serving方法

如何解决推荐系统工程难题——深度学习推荐模型线上serving？

AWS

大家要注意架构图右上角的AWS的标志，它意味着Netflix的所有服务器和大数据设施都是架构在amazon的云平台上的，而且一直沿用至今。作为AWS的第一大用户，Netflix服务的云化还是非常彻底的。

有的时候我也挺佩服美国这些互联网公司的选择，像Netflix、Pinterest这些公司，已经是不折不扣的互联网巨头，居然非常放心的使用AWS，AWS确实能够提供非常专业安全的云服务。这样开放的精神还是让我挺感慨的。国内的阿里云发展当然也非常好，但是巨头级别的公司完全依赖阿里云的案例还是不多，从这一点上，国内和国外整个互联网的氛围还是有一些微妙的区别。

不同层之间的配合与系统的整体性

可以看到，从离线到在线，数据的实时性从上到下依次增强，而数据规模和处理能力从上到下依次减弱。

但作为同一个系统之中的不同功能层，只有整合发挥不同层的优势，才能够让系统整体发挥出最大的作用。所以我们可以在架构图中看到很多跃层的调用。

比如从online 到nearline和offline通过用户消息队列（User Event Queue，现在基本都使用Kafka）来缓存数据流，这是连接online和其他层的接口。

而从nearline和offline中连接online的接口则是algorithm service，online data service，以及model到online层的接口。他们分别存储了算法结果，数据特征和模型文件。

在架构图正中央的存储部分，也有不同的数据库作为数据中心作为不同模块的数据交换接口。比如cassandra更适宜存储大数据量的nosql数据，mysql当然是适合结构化的小数据量数据，而EVcache则作为内存数据库当作数据缓存使用。当然，技术的发展使得现在已经有更合适的技术选型，AWS的dynamoDB，以及redis都可以作为更好的替代方案。

总结

最后的总结就直接用netflix官方博客的总结吧。

We want the ability to use sophisticated machine learning algorithms that can grow to arbitrary complexity and can deal with huge amounts of data. We also want an architecture that allows for flexible and agile innovation where new approaches can be developed and plugged-in easily. Plus, we want our recommendation results to be fresh and respond quickly to new data and user actions. Finding the sweet spot between these desires is not trivial: it requires a thoughtful analysis of requirements, careful selection of technologies, and a strategic decomposition of recommendation algorithms to achieve the best outcomes for our members.

我们需要具备使用复杂机器学习算法的能力，这些算法要可以适应高度复杂性，可以处理大量数据。我们还要能够提供灵活、敏捷创新的架构，新的方法可以很容易在其基础上开发和插入。而且，我们需要我们的推荐结果足够新，能快速响应新的数据和用户行为。找到这些要求之间恰当的平衡并不容易，需要深思熟虑的需求分析，细心的技术选择，战略性的推荐算法分解，最终才能为客户达成最佳的结果。

能让我拍案叫绝的技术经验不多，上面的标黑部分算是一句，写的多好，我几乎可以认为这是一个工程师乃至架构师的最高境界，与大家共勉。

照例跟大家讨论一个问题：

Netflix的架构从大框架上看过时了吗？业界还有其他的推荐系统工程架构方案吗？

参考资料：

https://netflixtechblog.com/system-architectures-for-personalization-and-recommendation-e081aa94b5d8

https://www.infoq.cn/article/2013%2F04%2Fnetflix-ml-architecture

最后欢迎大家关注我的微信公众号：王喆的机器学习笔记（wangzhenotes），跟踪计算广告、推荐系统等机器学习领域前沿。

也欢迎大家购买我的新书《深度学习推荐系统》，下面的链接应该还是满100减50，期待与大家交流，也欢迎大家的批评指正。

《深度学习推荐系统（全彩）》(王喆)【摘要 书评 试读】- 京东图书

—END—

每周关注计算广告、推荐系统和其他机器学习前沿文章，欢迎关注王喆的机器学习笔记