SEO外包平台,我们为您提供专业的企业网站SEO整站优化外包服务 SEO设置

SEO外包平台

专注于企业网站SEO整站优化外包服务

推荐系统架构的“三足鼎立”

作者:jcmp      发布时间:2021-04-29      浏览量:0
“谈我心目中的推荐系统架构”是对架

“谈我心目中的推荐系统架构”是对架构的详细说明,本文是从另一个视角思考 系统架构的总结。

按逻辑分层的架构图

为了对比重新贴了之前的架构如图1,按逻辑分层的架构如图2。

所谓“三足鼎立”就是图中的离线层,近线层和在线层:

在线层 :几乎对应图1大虚线框内的部分,直接处理线上请求。

近线层 :图1中处理实时数据的的部分。

离线层 :图1中使用spark/tf处理天级或更长周期数据的部分。

互联网就是新名词层出不穷,“近线”就是我最近才听说的,也不知道什么时候由谁创造出来的。但这个词还挺贴切。另外这种分层表达的方式也不是我原创的,但我以前没有太重视,直到最近遇到一些实际情况才醒悟分层有利于整体的思考。后面还将以一些实例说明“越层”带来的问题。


分层思考系统架构的好处

好处至少有一个,就是更有利于思考如何让“三足鼎立”达到平衡,让推荐系统架构更合理,运行得更顺畅。这个问题似乎不值一提,因为几乎没有人蠢到把离线任务搬到在线,反之亦然。但总会有人因为缺乏经验或思考而犯错,当没有人站在全局把控架构时,情况会更严重。把离线和在线之间搞乱的情况毕竟少数,但有了近线层后就不一样的。有的架构没有这一层,这种架构几乎不可能是实时的(除非系统数据量小,能很快更新)。有的架构这层不完善,虽然像模像样也能做些实时任务,但又把本可以放到近线层的任务放到了在线层,白白地浪费了线上资源,接踵而来的是线上耗时严重、超时报警。

忍不住插一句:优化有很多级,从指令级,到多线程,到算法,一直到系统架构。如果系统架构出了问题,还妄想在模块级优化不就是徒劳吗?这时该优化的不是系统而是思维吧?)


各层功能划分的一个原则

上面的分层图上窄下宽,这是有意这样画的---越往上层对耗时要求越严格,例如离线层耗时一般是小时级、天级;近线层可能是ms级,秒级,也可能分钟级;在线层一般是几十到几百ms。所以一个功能划分原则就是尽量 “功能下移 ”,能放到近线、离线的就不要放到在线,这样就能保证线上逻辑简单运行高效,也有利于算法团队和架构团队的分工,就是说算法团队负责在离线和近线生产数据,架构团队负责在线服务的稳定。这也暗合前文说的算法和架构团队以“数据”为接口的思路。


下面看些实例。

ICF算法的实现

ICF指物品协同过滤,是最基本的推荐算法之一,大致思路如下:假设喜欢物品A的用户集合为Sa,相应物品B的为Sb,通常以皮尔逊距离作为物品A和物品B的相似度距离。计算所有物品两两之间的相似距离就能得到一个相似度矩阵,这样当一个用户喜欢物品W就能从矩阵中找出与W相似的物品推荐给用户。

ICF在架构上怎么实现?个人认为 放到近线层是最合理 的:

1)通过消息队列实时回传用户U喜欢物品W的信息(U,W)

2)storm/flink/spark订阅并处理该信息,这里可能需要访问线上服务拿到用户画像和物品的详细信息,最后得到ICF算法的推荐结果

3)将计算结果存储起来,比如放到redis/memcache

4)当该用户再次访问时,ICF召回服务直接从存储中拿到候选结果,进行必要处理如曝光过滤,就能返回给用户了。

可以看到耗时的1)~3)都是在近线层处理,4)中只有简单的过滤,不难想像这样既能保证算法效果又能将极大降低线上延时,一举两得。

一种 反面教材 是将1)~4)统统搬到线上。假设计算要使用用户最近喜欢的X个物品,再假设每个物品平均有Y个相似的物品,这样候选物品就有X*Y个。一方面,为了保证算法效果X,Y不能太小,另一方面X,Y太大又容易增加线上服务延时,进退维谷骑虎难下说的就是这个,然后再在这个基础上搞的什么优化必然是治标不治本。

由此可见放到近线层是合理的,当前能这样做的前提是物品相似关系的相对稳定性。


UCF算法的实现

UCF算法与ICF非常类似,只不过要预先计算用户相似度矩阵。 它也应该放到近线层 ,虽然过程稍有不同:

1)通过消息队列实时回传用户U喜欢物品W的信息(U,W)

2)将W加入U喜欢的物品集合L(U)

3)从相似度矩阵拿到与U相似的用户集合S(U)

4)拿到S(U)中所有用户喜欢的物品集合(这里只是说明原理,算法应该有更精细的筛选),并入集合C

5)C-L(U)就是用户U的推荐候选集

可以想像这同样也是一个相当耗时的过程,如果放到线上层那你就每天专门侍候召回的超时告警吧!

UCF能放到近线的前提是用户相似关系的相对稳定,也就是3)中的S(U)短期内变动不大。


稍微隐蔽的例子

工作的原因,我需要把问题抽象一下。假设有一个服务维护着一批个人信息,包含名称,年龄,住址,身高和工作等,再假设每个用户的信息都串联到一起组成一个大字符串如“Tom,27,Beijing,175,Google",“Goodenough,80,America,180,University”等。另一方面,不同的用户可能只需要完整信息的子集,例如这个子集可能是名称和身高,也可能是名称和工作等。为了高效,服务器只应该返回用户需要的子集信息,而不是完整信息。

一种显然的解法是完全由 在线层处理 :在线服务遍历用户信息大字符串,根据请求拷贝相应字段并返回。但其实熟悉搜索尤其是索引的人可能早就看出应该 放到离线去处理 ,以空间换时间,具体就是离线对大字符串建立一个数组,数组长度为用户信息维度,数组每个元素记录大字符串中每维信息的起始位置。对于上述例子,需要一个长度为5的数组,分别记录名称,年龄,住址,身高和工作在“Tom,27,Beijing,175,Google”中的起始位置:[0,4,7,15,19]。这样当用户请求名称和身高时,服务就能直接从0和15开始读取相应信息,免去了耗时的遍历。

这个例子直接将线上耗时的操作转移到了线下,是不是有点意思?


一个不该存在的例子

这是一个不该存在的例子,因为我真的遇到了将本应放到离线的耗时操作放到了线上,然后就要花很大很大的力气去改造这个架构和服务。不过就像面对离开的人留下的一堆bug一样,我喜欢从“乐观”的角度去思考看待,那就是这毕竟为我们创造了就业机会。这个例子不想说了。

我相信在一个不太合理的架构中,能按这种分层架构思想去优化的点会有很多,尤其是传统的后台开发集中在离线在线,没有太在意“近线层”的存在,也许需要改一改了。

总结

1)一定要有意识地从全局去思考,这大概是为什么“不想当将军的士兵不是好士兵”。

2)不懂点算法可能干不好工程。最怕算法团队提出冠冕堂皇的不合理需求,架构团队却看不穿。

3)没有工程意识也搞不好算法,在各层之间胡乱实现,搞得线上超时报警,这算法效果能有保证吗?

4)“三足鼎立”稍有标题党,但通过实例看到,只有合理地在三者之间权衡规划才能达到相对较优的系统实现。

想获取更多内容,请关注海数据实验室公众号。

本期分享到这里,我们会每天更新内容,咱们下期再见,期待您的再次光临。有什么建议,比如想了解的知识、内容中的问题、想要的资料、下次分享的内容、学习遇到的问题等,请在下方留言。如果喜欢请关注。

社群推荐

更多有关数据分析的精彩内容欢迎加入 海数据在线数据分析交流群 ,有什么想法或者疑问都可在里面提出,与同行零距离交流,共同成长进步,请识别下面二维码加火星小海马微信, 邀你进群。