从Netflix的推荐系统架构中我们可以学习到什么？

你是否常常被乱花渐欲迷人眼的推荐算法绕得如坠云中，觉得好像算法就是推荐系统的全部，哪怕就算不是全部，也肯定至少是个嫡生的长子。

然而，实际上工程实现才是推荐系统的骨架，如果没有很好的软件实现，算法不能落地产生效果，产品不能顺畅地服务用户，不能顺利地收集到用户的反馈，更不能让推荐系统往更好的方向进化。

一个好的推荐系统不仅仅是在线下模型评测指标多么好，也不仅仅是在某个时刻像是灵光乍现一样击中了用户某个口味，而是随着用户的不断使用，产品和用户一起变好，产品背后的人得到进步，用户也越来越喜欢产品。

虽然影响是否用户产品的因素有很多很多，但是能否流畅地给用户提供服务是一个最基本的标准。

更多推荐系统内容，可订阅极客时间热门专栏 --- 资深算法专家刑无刀的《推荐系统 36 式》专栏，限时优惠价￥58。他已经系统深入地为你整理了推荐系统的相关知识和常识，部分文章还针对架构方面为你提供案例分析与解决方案，帮你解决系统起步阶段 80% 的问题。

一个好的推荐系统架构应该具有这些特质：

• 实时响应请求；

• 及时、准确、全面记录用户反馈；

• 可以优雅降级；

• 快速实验多种策略。

本文中我要介绍一种符合经典推荐系统的架构，它就是著名的流媒体 Netflix 的推荐系统架构。

通过这篇文章，我会为你介绍，实现一个简化版的推荐系统架构应该至少包含哪些元素，同时，我会带你一起总结出，一个经典推荐系统架构应该有的样子。

经典架构

好了，废话少说，我先上图。下面这张图就是 Netflix 的推荐系统架构图。

我先整体看一下这个架构，一共分成三层：在线、近线、离线。

你是不是也发现似乎有一个不太熟识的词出现：近线。对，这个近线是通常不太提的一个概念，或者通常就把它归入了在线的范畴。

实际上，可以这样定义这三个层级：

1. 离线：不用实时数据，不提供实时服务；

2. 近线：使用实时数据，不保证实时服务；

3. 在线：使用实时数据，要保证实时服务。

我和大家一一详细介绍每个部分。

1. 在线层

在线层的触发时机是当用户发出请求，也就是用户进入一个推荐场景，推荐位等着展示推荐结果时，这个时候需要承担责任就是在线层。在线层就是实时响应用户请求。简单说，在线层的特点就是“使用实时数据，要保证实时服务”。

在线层的优势有：

• 直接首次接触到大多数最新数据；

• 对用户请求时的上下文了如指掌；

• 只需计算必须的信息，不需要考虑所有的信息。

在线层也有严格的制约：

• 严格的服务响应时间，不能超时，或者让用户等太久；

• 服务要保证可用性，稳定性；

• 传输的数据有限。

2. 离线层

讲完在线层，再来看看离线层。离线层就是躲在推荐系统的大后方，批量、周期性地执行一些计算任务。其特点是“不用实时数据，不提供实时服务”。

离线层的示意图如下：

离线阶段主要面对的数据源就是 Hadoop，实质上是 HDFS。收集到的所有日志都存在这里面，是一个全量的数据中心。

通过 Pig 或者 Hive 等工具，从全量日志中按照算法要求抽取出不同的数据，再加上其他数据变成了不同算法所需的数据源。

在 Netflix 内部，承担这个管理任务的工具叫做 Hermes，类似 Kafka，但是又有不同的内部工具。

离线阶段有以下这么几个好处：

• 可以处理最大的数据量；

• 可进行批量处理和计算；

• 不用有响应时间等要求。

当然坏处也是明显的：

• 无法及时响应前端需求；

• 面对的数据较静态，无法及时反应用户的兴趣变化。

大多数推荐算法，实际上都是在离线阶段产生推荐结果的。离线阶段的推荐计算和模型训练，如果要用分布式框架，通常可以选择 Spark 等。

3. 近线层

最后，我来讲讲近线层。近线层的特点是“使用实时数据，不保证实时服务”，这实在是一个很不讲道理的计算层，因为把它的特点翻译得直白点就是：喂给我最新鲜的牧草，但是我不保证能马上给你挤奶。

虽然这看上去蛮不讲理，但实际上这是一个非常重要的一层，它结合了离线层和在线层的好处，摒弃了两者的不足。

近线层，也叫做准实时层，所谓“准实时”，就是接近实时，但不是真的实时。

从前面的架构图中也可以看出，这一层的数据来源是实时的行为事件队列，但是计算的结果并不是沿着输入数据的方向原路返回，而是进入了在线数据库中，得到用户真正发起请求时，再提供服务。

简化架构

Netflix 是为全球多个国家同时提供在线服务的，因此推荐系统的架构略微复杂。倘若你现在刚刚接手一个新产品，要从 0 开始搭建一个推荐系统，那么可以以 Netflix 的架构作为蓝本，做一定的简化。

关键简化有两点：

• 完全舍弃掉近线层；

• 避免使用分布式系统。

其中第二点，在一个新产品的场景下， 当数据量还没有那么大时，使用分布式存储或者计算框架，非常不划算。

如果性能不足，请升级单机配置。根据经验，一个几千万用户，几十万到百万的物品的协同过滤或者矩阵分解，如果充分发挥单机的性能，综合效率会远远优于在 Spark 上运行。

另外在一个推荐系统刚从 0 开始的阶段，离线阶段的算法也没有那么多，很多情况甚至都只有协同过滤结果，这时候线上融合模型也不必那么复杂，一个简单的加权融合就可以了，因此在线层也不必复杂。

总结

本文我以 Netflix 架构为原型，向你介绍了一个经典的推荐系统架构长什么样子。关于这个架构你只需要记住一点：它有三层，三层分别是离线，近线，在线。

我用如下的表格将这三层综合对比，并且简单举例，我们看看每一层分别放哪些任务。

以上就是对这个架构的宏观总结对比。如前所说，其实架构都是进化出来的，你千万不必在一开始就追求完美的架构，满足最低要求就好。

若喜欢我的分享，欢迎订阅我的专栏《推荐系统 36 式》，限时优惠价￥58。扫码，即可拥有推荐系统 36 课的内容，和 3500+ 技术人、产品人共同学习，从产品、技术、商业等各个维度带你理解并适当运用推荐系统。

双重福利：

• 福利一：限时￥58，明天（5 月 12 日）调至￥68。

• 福利二：现每邀请一位好友，你可获得 12 元，好友也将获得 6 元现金，多邀多得，上不封顶，立马提现！

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/