推荐系统三十六式
刑无刀
“贝壳找房”资深算法专家,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
  • shangqiu86
    bandit算法主要解决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
收起评论
13
返回
顶部