02｜Netflix推荐系统：企业级的推荐系统架构是怎样的？

作者回复: 答：同学你好，你的理解是完全正确的。另外，近似在线层也可以使用Redis这类的数据库，主要是看你的近似在线层对实时性的要求有多高。

作者回复: 同学你好，我来回答你的这几个问题： 1、课程中所说的开放，指的是他们的论文，而不是开源，就是Netflix已经发表了论文，详细地说明了这一套是怎么做的； 2、我是这么理解的，近似在线层是在召回层之后，实际上是对召回层的数据根据用户的信息再一次做筛选，因此可以理解为是更精细的召回，但是相对于排序来说，它的内容还是太多，所以是粗排序； 3、在线层依赖于近似在线层的结果，但是近似在线层实际上是对用户最近几分钟的历史行为来做更新，我们主要是取近似在线层更新的结果，所以，近似在线层的计算耗时并不影响在线层取内容； 4、Netflix的三层架构基本上现在的推荐系统都是这么来做的，相对通用； 5、推荐系统对大数据的依赖可大可小，主要看用户和内容的规模，因此，大数据框架出现之前，实际上也是可以利用其它的存储方式来获取数据进行计算，而且在大数据出现之前，一般业务量也不会特别大，所以，我认为，这个是时代发展的结果。

作者回复: 同学你好，你的这个理解稍微有一点点偏差。首先在线层没有做存储功能，只是去收集实时数据，然后给到近似在线层和离线层。离线层存储的有2个，一个是历史轨迹，一个是本地信息，比如用户画像、用户数据、内容数据、内容画像等，kafka的消息队列，不做存储，你可以理解为一个管道，kafka只是这根管子，数据是在这里面排队的。 这些数据会经历离线的召回、近似在线层的排序和在线层的重排序，然后给到用户。 如果需要做降级的话，我们一般可以把近似在线层的值同时存入到两种数据库，比如MongoDB和Redis，如果Redis取不到就从MongoDB中取。层与层之间也是这样。