slope实时推荐算法的系统设计思考

Posted 2021-04-29 南极鹅

首先我不是做推荐的，无意间看到这个算法觉得比较简单有趣，然后就执拗的想设计下如何在系统层面保证算法实时性。

Slope是一个能够做到在线实时计算的简单通俗推荐算法，其基本原理源自数学上线性关系。具体原理Google上随手一搜很多介绍和应用实例。本篇主要谈论从系统角度，如何将slope做成在线实时更新的推荐引擎。

根据slope的原理：用户对某个产品可能的兴趣取决于已有用户标签和物品之间的加权平均差值。主要应用于“猜你喜欢”、“换一批”等类似的TopK推荐。TopK的推荐一定是基于打分原则，通过可量化的指标和算法，得到某个用户user_id对某件物品的感兴趣程度，f(user_id, item_id) 。

可见slope的所有轮子启动取决于用户对某一件商品点下评分的那一瞬间。

一、从系统角度，这一瞬间发生了什么

1、用户-物品打分更新

2、物品间关联系数更新

3、TopK更新

二、这3个变动触发了哪些系统层次的设计

1、存储结构设计

（1）物品表 Items

item_id

Item_profile (复合结构)

（2）用户-物品-打分表 UserItemScores

user_id

item_id

score

（3）物品关联表 ItemRelations

item_id

ration_id

factor

total

cnt 

（4）用户-物品-预测表 UserItemPredicts

所有的业务流程围绕这4张表展开。

2、逻辑

（1）UserItemScores 增加一条用户打分记录；

(user_id, item_id, score)

（2）ItemRelations

UserItemScores中user_id对应的item_ids关联的(item_id, item_id’)的相关系数都需要做校正

（3）Top-K

三、场景分解和系统设计挑战

用户在线状态下打分处于高频状态，根据业务场景可以进行如下细化：

（1）同一user_id的打分处于低频状态

即一个用户不可能给多件物品同时打分；

（2）不同user_id在同一时刻打分处于高频状态

即多个用户在同一时刻打分；

（3）你不同user_id在同一时刻对同一item_id处于变化状态；

即物品的冷热程度不同，某一段时间可能某个物品非常热，多数物品都处于冷状态。

因此，通过场景归纳，关键问题在于：

（1）ItemRelations中(item(i), item(j))的差值在多用户打分更新的时候如何保证高并发量的写入操作；

（2）某个用户的推荐列表topK如何实时动态更新。

1、高并发写入

高并发更新数据的方法论在于：尽可能减少粒度，降低并发度冲突范围。这个问题也不例外，100个、1w个和100w个请求同时更新一个数据的处理时延是不一样的。

其次，这个问题分为水平和垂直两个方向，水平是指ItemRelations的全量数据集如何解决高并发更新；垂直是指某一数据如何解决高并发更新。

最后，个人理解推荐系统中所描述的实时性跟后台系统API的实时性的理解是一样的，API的实时性是毫秒级的，推荐系统能够在秒级甚至1分钟内完成都可以称之为实时。

（1）水平方向

基础的方法论：粒度放小，降低并发冲突率。这个问题也不例外。

最简单的做法是机械式分库分表，百库百表大法。

如果想做的好一点：冷热数据分离，冷数据集中，热数据单独处理。

还有经典的削峰理论：请求经过消息队列，相当于做一层平滑处理，将峰值降下来。

（2）垂直方向

高并发下如何更新同一个数据，解决方式取决于请求量级。

a、排队

简单即为美，最基础的排队方式就可以解决。更新数据的入口挂一层proxy将所有操作通过proxy排队，变并行为串行。

b、聚合+排队

机械排队可能延迟会有点大，变简单排队为聚合+排队。proxy层每收集n个请求将其聚合计算，比如每100次聚合一次请求更新一次，那么请求量就下降了100倍。

c、内存+异步更新+聚合+排队

这种场景在在线广告计费系统中应该遇到，曝光并发量很大的时候如何实时更新数据库内的计费。

解决之道的本质还是分离，变实时更新数据库为异步更新数据库，加一层内存级别的数据存储，在线系统经聚合后只更新内存，数据库异步更新完成。

2、Top-K的动态更新

上述高并发写入能够保证实时性后，Top-K完全可以在接口层做聚合。

（1）读取用户已有的打分列表和item_relations的关联factor将未打分列表计算后取Top-K。

（2）如果过程（1）慢，变为聚合方式，每n秒计算一次更新到结果存储，API直接取结果。

（3）如果（2）还是慢，每次计算完的结果取定长的5倍或者10倍top-k的数据作为中间数据用于计算真正的top-k，中间数据定期去更新。

物品的种类少说百万级，采用方案（3）的可能性最大。

没有什么问题是中间层解决不了的，如果不行就再来一层。

四、Slope的缺点

1、冷启动

没有用户评价物品的时候这个算法是不生效的。

2、数据稀疏性

多数用户是不评价的，那么有评价的数据占比很少，多数物品没有任何用户评价，那么有效数据是稀疏的。

这两个问题还是需要算法同学多想想办法了。