26. Netflix个性化推荐架构.pdfVIP

你是否常常被乱花渐欲迷人眼的推荐算法绕得如坠云中，觉得好像算法就是推荐 系统的全部，哪怕就算不是全部，也肯定至少是个嫡生的长子。 然而，实际上工程实现才是推荐系统的骨架，如果没有很好的软件实现，算法不 能落地产生效果，产品不能顺畅地服务用户，不能顺利地收集到用户的反馈，更 不能让推荐系统往更好的方向进化。 一个好的推荐系统不仅仅是在线下模型评测指标多么好，也不仅仅是在某个时刻 像是灵光乍现一样击中了用户某个口味，而是随着用户的不断使用，产品和用户 一起变好，产品背后的人得到进步，用户也越来越喜欢产品。 虽然影响是否用户产品的因素有很多很多，但是能否流畅地给用户提供服务是一 个最基本的标准。 架构的重要性 推荐系统向来是一个锦上添花的东西，因此传统的观点是推荐系统更加注重线下 的模型效果，而非线上的服务质量。但是你也知道，时至今日，推荐系统不再只 是锦上添花，而是承担了产品的核心功能。因此，对推荐系统架构的要求也高了 很多。 一个好的推荐系统架构应该具有这些特质： 1. 实时响应请求； 2. 及时、准确、全面记录用户反馈； 3. 可以优雅降级； 4. 快速实验多种策略。 上一篇专栏文章介绍的是当下最热门的推荐系统产品形式——信息流的架构，信 息流并不是传统意义上的推荐系统，今天我要介绍一种更符合经典推荐系统的架 构，这就是著名的流媒体 Netflix 的推荐系统架构。 通过这篇文章，我会为你介绍，实现一个简化版的推荐系统架构应该至少包含哪 些元素，同时，我会带你一起总结出，一个经典推荐系统架构应该有的样子。 经典架构 好了，废话少说，我先上图。下面这张图就是 Netflix 的推荐系统架构图。 我先整体看一下这个架构，一共分成三层：在线、近线、离线。 你是不是也发现似乎有一个不太熟识的词出现：近线。对，这个近线是通常不太 提的一个概念，或者通常就把它归入了在线的范畴。 实际上，可以这样定义这三个层级： 1. 离线：不用实时数据，不提供实时服务； 2. 近线：使用实时数据，不保证实时服务； 3. 在线：使用实时数据，要保证实时服务。 在具体介绍这些内容之前，我先来说说数据流的情况。 1. 数据流 用户在产品 UI 上使用产品，消费展示的内容，产生行为事件数据，实时地被收 集走，一边进入分布式的文件系统中存储，供离线阶段使用，另一边流向近线层 的消息队列，供近线阶段的流计算使用。 离线存储的全量数据被抽取出来，组成离线计算所需的训练数据，这些训练数据 被一个管理数据生成和发布的组件统一管理，要使用数据的下游，比如模型训练 会在离线数据生成时得到这个组件的通知，从而开始训练，训练得到的模型用于 进一步为用户计算推荐结果。 离线阶段的推荐结果或者模型在近线阶段被更新，进一步在在线阶段被直接使用， 产生最终的推荐结果，呈现给用户。 这是整个数据流情况。下面我一一详细介绍每个部分。 2. 在线层 在线层的触发时机是当用户发出请求，也就是用户进入一个推荐场景，推荐位等 着展示推荐结果时，这个时候需要承担责任就是在线层。在线层就是实时响应用 户请求。简单说，在线层的特点就是“使用实时数据，要保证实时服务”。 在线层的优势有： 1. 直接首次接触到大多数必威体育精装版数据； 2. 对用户请求时的上下文了如指掌； 3. 只需计算必须的信息，不需要考虑所有的信息。 在线层也有严格的制约： 1. 严格的服务响应时间，不能超时，或者让用户等太久； 2. 服务要保证可用性，稳定性； 3. 传输的数据有限。 在线层常常展现出的形式就是 Rest API 形式，后端则通常是 RPC 服务内部互相 调用，以用户 ID、场景信息去请求，通常就在 ms 响应时间内返回 Json 形式 的推荐结果。那么哪些计算逻辑适合放在在线层呢？ 1. 简单的算法逻辑； 2. 模型的预测阶段； 3. 商业目标相关的过滤或者调权逻辑； 4. 场景有关的一些逻辑； 5. 互动性强的一些算法。 在线阶段要处理的对象一般是已经预处理后的推荐结果，是少量物品集合。 比如说当用户访问一个物品详情页，需要做相关推荐，那么在线阶段给在线服务 的 Rest API 传入用户身份以及当前的物品 ID，实时地取出物品 ID