推荐系统是今年的主要工作之一
整体架构
推荐系统可以说是一个闭环的生态系统了。从整体架构图中，我们就可以看出来，推荐列表从RankServer产生，用户点击推荐列表产生的日志又反作用于画像系统的更新，模型训练，新的推荐算法的实验，以及BI报表的生产，而这些又都是RankServer依赖的模块。
Rank Server
各部分说明
Rank Server是推荐系统最为关键的一环，下面我们将详细介绍各个模块的功能。
ABTest:
ABTest主要包含了下列几点功能：
支持定向策略
支持多种实验
支持灰度发布
支持
Rolling Update
为用户/内容打标签，包括召回，配比，排序三个参数。具体做法可以利用uuid将用户/内容切分为多个bucket。每个bucket分配不同的策略。非法id随机分配。添加配置白名单，方便测试。
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+倍的性能提升。
- 排序模型评估
离线部分：上线之前需要计算AUC/MAP，达到上线标准之后，方可手动上线。
在线部分：通过ABtest观察一段时间，对比实际效果。
黑名单
黑名单由两部分组成，一部分是用户浏览的历史记录，一部分是运营人员定义的人工规则。
重复推荐可能对推荐结果带来影响，以及不好的用户体验，所以有必要过滤掉最新点击的topN用户/内容。
运营人员可能需要屏蔽一些用户/内容。
推荐系统指标
由于推荐系统依赖众多的外部服务，这就增加了系统维护的复杂性，确定一个推荐系统是否健康指标，我们可以将其分为两大类，程序指标和数据指标。
程序指标
程序指标我们收集的比较简单，包括CPU,Memory使用率和GC相关指标。
数据指标
数据指标比较复杂，这里我就放出一些关键的指标数据。
Reference
- [1]美团排序线下篇
- [2]美团排序线上篇
- [3]达观搜索引擎排序案例
- [4]job recommendation
