推荐系统三十六式
刑无刀
“贝壳找房”资深算法专家，8年推荐系统工程师
立即订阅
11436 人已学习
课程目录
已完结 39 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 用知识去对抗技术不平等
免费
第1章 概念篇 (3讲)
【概念篇】你真的需要个性化推荐系统吗?
【概念篇】个性化推荐系统那些绕不开的经典问题
【概念篇】这些你必须应该具备的思维模式
第2章 原理篇 (20讲)
【内容推荐】画鬼容易画人难：用户画像的“能”和“不能”
【内容推荐】从文本到用户画像有多远
【内容推荐】超越标签的内容推荐系统
【近邻推荐】人以群分，你是什么人就看到什么世界
【近邻推荐】解密“看了又看”和“买了又买”
【近邻推荐】协同过滤中的相似度计算方法有哪些
【矩阵分解】那些在Netflix Prize中大放异彩的推荐算法
【矩阵分解】Facebook是怎么为十亿人互相推荐好友的
【矩阵分解】如果关注排序效果，那么这个模型可以帮到你
【模型融合】经典模型融合办法：线性模型和树模型的组合拳
【模型融合】一网打尽协同过滤、矩阵分解和线性模型
【模型融合】深度和宽度兼具的融合模型 Wide and Deep
【MAB问题】简单却有效的Bandit算法
【MAB问题】结合上下文信息的Bandit算法
【MAB问题】如何将Bandit算法与协同过滤结合使用
【深度学习】深度学习在推荐系统中的应用有哪些?
【深度学习】用RNN构建个性化音乐播单
【其他应用算法】构建一个科学的排行榜体系
【其他应用算法】实用的加权采样算法
【其他应用算法】推荐候选池的去重策略
第3章 工程篇 (10讲)
【常见架构】典型的信息流架构是什么样的
【常见架构】Netflix个性化推荐架构
【常见架构】总览推荐架构和搜索、广告的关系
【关键模块】巧妇难为无米之炊：数据采集关键要素
【关键模块】让你的推荐系统反应更快：实时推荐
【关键模块】让数据驱动落地，你需要一个实验平台
【关键模块】 推荐系统服务化、存储选型及API设计
【效果保证】推荐系统的测试方法及常用指标介绍
【效果保证】道高一尺魔高一丈：推荐系统的攻防
【开源工具】和推荐系统有关的开源工具及框架介绍
第4章 产品篇 (3讲)
【产品篇】推荐系统在互联网产品商业链条中的地位
【产品篇】说说信息流的前世今生
【团队篇】组建推荐团队及工程师的学习路径
尾声与参考阅读 (2讲)
推荐系统的参考阅读
【尾声】遇“荐”之后，江湖再见
推荐系统三十六式
登录|注册
【常见架构】Netflix个性化推荐架构
刑无刀 2018-04-30
你是否常常被乱花渐欲迷人眼的推荐算法绕得如坠云中，觉得好像算法就是推荐系统的全部，哪怕就算不是全部，也肯定至少是个嫡生的长子。
然而，实际上工程实现才是推荐系统的骨架，如果没有很好的软件实现，算法不能落地产生效果，产品不能顺畅地服务用户，不能顺利地收集到用户的反馈，更不能让推荐系统往更好的方向进化。
一个好的推荐系统不仅仅是在线下模型评测指标多么好，也不仅仅是在某个时刻像是灵光乍现一样击中了用户某个口味，而是随着用户的不断使用，产品和用户一起变好，产品背后的人得到进步，用户也越来越喜欢产品。
虽然影响是否用户产品的因素有很多很多，但是能否流畅地给用户提供服务是一个最基本的标准。
架构的重要性
推荐系统向来是一个锦上添花的东西，因此传统的观点是推荐系统更加注重线下的模型效果，而非线上的服务质量。但是你也知道，时至今日，推荐系统不再只是锦上添花，而是承担了产品的核心功能。因此，对推荐系统架构的要求也高了很多。
一个好的推荐系统架构应该具有这些特质：
实时响应请求；
及时、准确、全面记录用户反馈；
可以优雅降级；
快速实验多种策略。
上一篇专栏文章介绍的是当下最热门的推荐系统产品形式——信息流的架构，信息流并不是传统意义上的推荐系统，今天我要介绍一种更符合经典推荐系统的架构，这就是著名的流媒体 Netflix 的推荐系统架构。
通过这篇文章，我会为你介绍，实现一个简化版的推荐系统架构应该至少包含哪些元素，同时，我会带你一起总结出，一个经典推荐系统架构应该有的样子。
经典架构
好了，废话少说，我先上图。下面这张图就是 Netflix 的推荐系统架构图。
我先整体看一下这个架构，一共分成三层：在线、近线、离线。
你是不是也发现似乎有一个不太熟识的词出现：近线。对，这个近线是通常不太提的一个概念，或者通常就把它归入了在线的范畴。
实际上，可以这样定义这三个层级：
离线：不用实时数据，不提供实时服务；
近线：使用实时数据，不保证实时服务；
在线：使用实时数据，要保证实时服务。
在具体介绍这些内容之前，我先来说说数据流的情况。
1. 数据流
用户在产品 UI 上使用产品，消费展示的内容，产生行为事件数据，实时地被收集走，一边进入分布式的文件系统中存储，供离线阶段使用，另一边流向近线层的消息队列，供近线阶段的流计算使用。
离线存储的全量数据被抽取出来，组成离线计算所需的训练数据，这些训练数据被一个管理数据生成和发布的组件统一管理，要使用数据的下游，比如模型训练会在离线数据生成时得到这个组件的通知，从而开始训练，训练得到的模型用于进一步为用户计算推荐结果。
离线阶段的推荐结果或者模型在近线阶段被更新，进一步在在线阶段被直接使用，产生最终的推荐结果，呈现给用户。
这是整个数据流情况。下面我一一详细介绍每个部分。
2. 在线层
在线层的触发时机是当用户发出请求，也就是用户进入一个推荐场景，推荐位等着展示推荐结果时，这个时候需要承担责任就是在线层。在线层就是实时响应用户请求。简单说，在线层的特点就是“使用实时数据，要保证实时服务”。
在线层的优势有：
直接首次接触到大多数最新数据；
对用户请求时的上下文了如指掌；
只需计算必须的信息，不需要考虑所有的信息。
在线层也有严格的制约：
严格的服务响应时间，不能超时，或者让用户等太久；
服务要保证可用性，稳定性；
传输的数据有限。
在线层常常展现出的形式就是 Rest API 形式，后端则通常是 RPC 服务内部互相调用，以用户 ID、场景信息去请求，通常就在 ms 响应时间内返回 Json 形式的推荐结果。那么哪些计算逻辑适合放在在线层呢？
简单的算法逻辑；
模型的预测阶段；
商业目标相关的过滤或者调权逻辑；
场景有关的一些逻辑；
互动性强的一些算法。
在线阶段要处理的对象一般是已经预处理后的推荐结果，是少量物品集合。
比如说当用户访问一个物品详情页，需要做相关推荐，那么在线阶段给在线服务的 Rest API 传入用户身份以及当前的物品 ID，实时地取出物品 ID 对应的相关物品 ID，再根据用户信息对这些物品 ID 做一些重排和过滤，就可以输出了，整个过程都是在 ms 级别完成。
这个实时响应的过程中，如果发生意外，比如说这个物品 ID 就没有相关的物品，那么这时候服务就需要降级，所谓的降级就是不能达到最好的效果了，但是不能低于最低要求，这里的最低要求就是必须要返回东西，不能开天窗。
于是，这就降级为取出热门排行榜返回。虽然不是个性化的相关结果，但是总比开天窗要好。这就是服务的可用性。
在线阶段还要实时地分发用户事件数据，就是当用户不断使用产品过程产生的行为数据，需要实时地上报给有关模块。这一部分也是需要实时的，比如用于防重复推荐的过滤。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《推荐系统三十六式》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(13)
- kee2“如果性能不足，请升级单机配置。根据经验，一个几千万用户，几十...”
请问你说的几千万用户这种场景单机配置大概是怎样的，谢谢作者回复: 请看最后一篇。关于团队。那里有回答。
2018-09-01 1 - 明华老师您好，想问如果我在离线训练阶段使用了逻辑回归训练出了模型，在在线预测时对单个用户调用api预测，但如果是单个用户怎么做例如归一化之类的数据预处理操作呢?2018-07-24 1
尹士果性能不足，请升级单机配置。根据经验，一个几千万用户，几十万到百万的物品的协同过滤或者矩阵分解，如果充分发挥单机的性能，综合效率会远远优于在 Spark 上运行。
你好，刀哥，如何充分发挥单机性能，我能想到的只有算法优化和多进程，按照千万用户和五十万物品算，采用物品的协同过滤，每个物品有十个纬度的特征，每个用户有十个纬度特征，我觉得这个量太大，单机实时推荐物品无法做到，想听一下你的高见2018-05-02 1
hqzhao每期都听，自己的研究方向就是RS，听完发现同样的问题站在不同的角度去理解会发现一片新天地。很感谢刑前辈！2018-05-01 1
林彦Bandit算法需要根据场景反馈调试模型的参数值，适合还没有任何模型效果数据的冷启动。当候选臂的数量不大时，可以直接应用到在线计算中。也可以作为其他离线模型推荐结果的在线优化模型使用。2018-05-01 1- Geek_00437c两个问题：
1、如果一个用户足够活跃，把离线召回的item都用完了，这时候近线层的召回补充就发挥很大作用了？
2、您的github是啥，网上没找到~2019-11-18 
Warner老师，近线层中的"在线数据"是怎么产生的？在线层输出的吗？2019-07-23- shangqiu86bandit算法主要解决EE问题和冷启动问题，我觉得应该放到在线层，作为融合排序的一部分2019-05-06
Better Life老师，实时I2I有干货可以分享一下吗？git上面有demo可以学习的吗作者回复: Itembased的代码见我的github。
2018-12-23
帅帅Another option is to precompute part of a result with an offline process and leave the less costly or more context-sensitive parts of the algorithms for online computation。
在原文看到了这句话，可以将一部分预计算好放到cache里服务，将少量的有价值或者对环境敏感的算法部分可以在线计算2018-09-26- 帅帅感觉在线部分调用融合排序模型，也不绝对这样的；
比如一个网站，内容更新比较慢，那每个用户都预计算好预排序好推荐列表就可以，没必要每次排序，毕竟排序还是调用模型性能耗费大2018-09-24 - 帅帅在多篇文章中看到作者对分布式计算的降级，认为会提升成本；
其实spark是支持standalone单机版本的，并且在单机上无缝使用多核计算，即使将来不能满足需求了，把--master从local改成yarn就变成了分布式~~~~2018-09-13 
梦露结合上下文和协同过滤能降低臂个数的Bandit可以用于在线部分，纯Bandit适合在离线部分，保证长尾物品的曝光2018-06-06
收起评论