rankserver

转自：https://www.jianshu.com/p/298f23b6caf6

 

整体架构

推荐系统架构

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

Rank Server

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. 并行特征获取。 正如我们上述中提到的，往往一次排序，我们可能就需要获取多达上千篇内容的多维特征，所以并行特征获取是提升整体相应时间的关键一步。在具体实现上，参考了1的设计，采用akka进行并行特征获取。
2. 利用GPU加速排序计算。 排序模型往往涉及到高纬矩阵计算，一开始我们将tensorflow模型放在了cpu服务器上，实验发现效果相当不理想，最终我们选择了gpu服务器，得到了10+倍的性能提升。

tensorflow模型在cpu/gpu服务器上的性能对比

• 排序模型评估

离线部分：上线之前需要计算AUC/MAP，达到上线标准之后，方可手动上线。
在线部分：通过ABtest观察一段时间，对比实际效果。

黑名单

黑名单由两部分组成，一部分是用户浏览的历史记录，一部分是运营人员定义的人工规则。

重复推荐可能对推荐结果带来影响，以及不好的用户体验，所以有必要过滤掉最新点击的topN用户/内容。
运营人员可能需要屏蔽一些用户/内容。

推荐系统指标

由于推荐系统依赖众多的外部服务，这就增加了系统维护的复杂性，确定一个推荐系统是否健康指标，我们可以将其分为两大类，程序指标和数据指标。

程序指标

程序指标我们收集的比较简单，包括CPU,Memory使用率和GC相关指标。

CPU/Memory/GC

数据指标

数据指标比较复杂，这里我就放出一些关键的指标数据。

召回过滤比例

召回率

召回排序分钟级别统计

Reference

• [1]美团排序线下篇
• [2]美团排序线上篇
• [3]达观搜索引擎排序案例
• [4]job recommendation

作者：我要大声告诉你
链接：https://www.jianshu.com/p/298f23b6caf6
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。