推荐系统

整体架构

推荐系统架构

推荐系统可以说是一个闭环的生态系统了。从整体架构图中，我们就可以看出来，推荐列表从RankServer产生，用户点击推荐列表产生的日志又反作用于画像系统的更新，模型训练，新的推荐算法的实验，以及BI报表的生产，而这些又都是RankServer依赖的模块。

Rank Server

各部分说明

Rank Server是推荐系统最为关键的一环，下面我们将详细介绍各个模块的功能。

ABTest:

ABTest主要包含了下列几点功能：

支持定向策略
支持多种实验
支持灰度发布
支持Rolling Update

为用户/内容打标签，包括召回，配比，排序三个参数。具体做法可以利用uuid将用户/内容切分为多个bucket。每个bucket分配不同的策略。非法id随机分配。添加配置白名单，方便测试。

ABTest

1.召回:召回模型编号，配比：多个召回模型所占百分比，排序：排序算法编号。
2.AB测试元数据写zookeeper。（配置量小，实时生效）
召回配比排序元数据写mysql。

召回模型

从全量候选集直接获取召回模型所需数据往往不容易，可以通过标签检索来筛选初步数据。所以召回模块就是为了完成候选集范围缩小的目的。

召回模型主要分为两类：batch和streaming

批处理的召回模型对历史的数据做分析。召回结果写cache。如协同过滤，关联规则等。

流式计算对实时数据源（如最新，最热，优质）分析。（主题模型）

NOTE: 如果召回模型无法为当前用户/内容作出推荐时候，采用候补资源推荐

典型召回

上图显示是一个典型召回策略，我们会在用户画像中记录用户的兴趣标签及其权重，缓存服务存储了兴趣标签的实时推荐列表倒排索引，最后我们根据用户的兴趣标签召回对应的标签倒排索引。在具体实现时，我们采用了Elasticsearch，作为我们倒排索引存储服务。

排序

rerank模型也可以分为离线模型（如LR，GBDT等）和在线模型（如FTRL等）两种。
排序模块根据ab测试为推荐数据打的标签（排序字段），调用不同的排序模型服务对召回结果集进行排序，获得最终有序结果集。

排序模块可能涉及多种类型特征，特征获取和计算关系到Rank Server整体的响应速度。

NOTE: 在具体实现过程中，rerank模块也是我们遇到问题比较多的一个模块。这里我总结几个关键点：

并行特征获取。 正如我们上述中提到的，往往一次排序，我们可能就需要获取多达上千篇内容的多维特征，所以并行特征获取是提升整体相应时间的关键一步。在具体实现上，参考了1的设计，采用akka进行并行特征获取。

利用GPU加速排序计算。 排序模型往往涉及到高纬矩阵计算，一开始我们将tensorflow模型放在了cpu服务器上，实验发现效果相当不理想，最终我们选择了gpu服务器，得到了10+倍的性能提升。