推荐系统总结6（系统架构）

23 内容架构

内容架构

日志收集、内容发布、机器学习、信息流服务、监控。

日志收集，是所有排序训练的数据来源，要收集的最核心数据就是用用户在信息流上产生的行为，用于机器学习更新排序模型；

内容发布，就是用推或者拉的模式把信息流的内容从源头发布到受众端；

机器学习，从收集的用户行为日志中训练模型，然后为每一个用户即将收到的信息流内容提供打分服务；

信息流服务，为信息流的展示前端提供 Rest API；

监控，这是系统的运维标配，保证系统的安全和稳定等。

24 系统架构

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

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

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

24.1 在线层

 在线层常常展现出的形式就是 Rest API 形式，后端则通常是 RPC 服务内部互相调用，以用户 ID、场景信息去请求，通常就在 ms 响应时间内返回Json 形式的推荐结果。那么哪些计算逻辑适合放在在线层呢.？

1.简单的算法逻辑；2.模型的预测阶段；3.商业目标相关的过滤或者调权逻辑；4.场景有关的一些逻辑；5.互动性强的一些算法。

比如说当用户访问一个物品详情页，需要做相关推荐，那么在线阶段给在线服务的 Rest API 传入用户身份及当前的物品 ID，实时地取出物品 ID 对应的相关物品ID 做一些重排和过滤，就可以输出了，整个过程都是在 ms 级别完成。这个实时响应的过程中，如果发生意外，比如说这个物品 ID 就没有相关的物品，那么这时候服务就需要降级，所谓的降级就是不能达到最好的效果了，但是不能低于最低要求，这里的最低要求就是必须要返回东西，不能开天窗。就降级为取出热门排行榜返回。虽然不是个性化的相关结果，但是总比开天窗要好。同时，还需要不断的使用产品过程中产生的用户行为，实时报送有关模块，例如不能重复推荐。

24.2 离线层

批量、周期性地执行一些计算任务。其特点是“不用实时数据，不提供实时服务”。

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

离线阶段的任务主要是两类：模型训练和推荐结果计算。通常机器学习类模型，尤其是监督学习和非监督学习，都需要大量的数据和多次迭代，这类型的模型训练任务最适合放在离线阶段。

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

24.3 近线层

近线层的特点是“使用实时数据，不保证实时服务”。虽然这看上去蛮不讲理，但实际上这是一个非常重要的一层，它结合了离线层和在线层的好处，摒弃了两者的不足。近线层，也叫做准实时层，所谓“准实时”，就是接近实时，但不是真的实时。

这一层的数据来源是实时的行为事件队列，但是计算的结果并不是沿着输入数据的方向原路返回，而是进入了在线数据库中，得到用户真正发起请求时，再提供服务。一个典型的近线计算任务是这样的：从事件队列中获取最新的一个或少许几个用户反馈行为，首先将这些用户已经反馈过的物品从离线推荐结果中剔除，进一步，用这几个反馈行为作为样本，以小批量梯度下降的优化方法去更新融合模型的参数。这两个计算任务都不会也不需要立即对用户做出响应，也不必须在下一次用户请求时就产生效果，就是说当用户实时请求时，不需要去等待近线任务的最新结果，因为两者是异步的。近线计算任务一个核心的组件就是流计算，因为它要处理的实时数据流。常用的流计算框架有 Storm，SparkStreaming，FLink 等，Netflix 采用的内部流计算框架 Manhattan，这和 Storm 类似。略有区别的是 Spark Streaming，实际上并不是实时流计算，而是小批量计算。

24.4 简化

完全舍弃掉近线层；避免使用分布式系统。

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

总结

25 数据采集

推荐算法形形色色，但是他们所需要的数据可以概括为两个字：矩阵。

基于这个分析，可以给要收集的数据归纳成下面几种。例如物品id，注意区分物品与物品之间的不同。

有几种方式可以获取数据

1.用SDK：友盟，google analytics，得到一些统计数据，但意义不大，可以自己仿照采集一些数据。

2.可视化：用开源的解决方案 mixpanel，指定收集

3.按自己自己方法

数据之外考虑的内容：

1.事件的设备信息，地理位置

2.从什么事件而来（上下文）

3.什么页面而来

4.事件发生的用户相关属性，物品相关属性。

总结，基本的推荐系统需要数据，如下，不会出错。