推荐系统架构,推荐系统由品类平台,素材,特征召回平台,模型计算打分服务,排序服务构成.
将请求封装成 QueryInfo 对象,通过对象来向下完成一步步数据召回.首先是通过 QueryInfo 对象召回品类,分类信息.
前边有人问到是怎样实现通用化?好问题,当时答得不太好,现在梳理总结一下,分类平台通过配置品类,分类信息,
配置选取个数,配置过滤品类信息,通过每一种配置情况构建分类信息,分类信息完全由配置文件构成.
召回品类扩展 QueryInfo 对象构成 QueryInfoExtern 对象,为下一步进行素材,特征召回做准备,因为品类,分类数据量
少,传输时不会因为数据量消耗太多时间,而素材,特征召回量极大,可通过分布式形式将素材进行召回,此时召回量最大
可满足线上服务要求,召回之后,每组分别进行打分计算,打分之后进行取前边数据进行返回.
再由品类召回节点合并将高分素材进行返回,熟悉 ElasticSearch 同学,会发现和 ElasticSearch 集群架构很像,其实推
荐本身和搜索就有很多相似之处,研究搜索引擎对于推荐引擎构建也会大有益处.
数据返回之前由排序服务对数据按展示效果进行商品按照品类,分类进行分隔,文章内容按标签,主题进行分隔.分隔
目的是为了好的展示效果,提升用户体验,通过上面这一系列过程构建成推荐系统大致过程.
除了上边架构逻辑,还存在存储以及数据流转体系.分类,素材,特征存储在 redis,HBase 中供服务读取使用.
对于实时反馈,用户点击,浏览会通过存储在 redis 中用于过滤,以及调整后续推荐分类,素材权重,已作为一种最实时
反馈手段.
上报特征本身通过 JDQ 消息队列进行上报,上报异步进行,通过先写日志文件再上报日志文件内容,来达到异步上报,
以避免同步上报导致线上服务性能受影响.JDQ 本身基于开源 kafka 打造.
JDQ 本身为了资源情况限制上报速度为 5M/s, 为了更好利用上报机器资源,会构建内存队列,充分利用内存资源来控制发
送速度,而不是一味通过扩容来解决问题.
日志白名单本身按照服务,属性,关键字进行存储,在 ElasticSearch 中可方便按属性,关键词检索使用,通过图形化界
面展示,方便快速定位线上问题.
监控本身除了 Ump 对系统功能,性能,可用性进行监控,引擎本身就要配备全面监控避免程序某个分支存在问题,导致
线上服务正确性,可用性存在问题,再有因为程序很多由配置文件动态构成,性能也要进行全面监控.
对于线上效果,线上模型与分支进行绑定,当分支 A 效果实时效果好于 B 效果,要将线上模型进行更新调整,监控时间
以几个小时效果为准.线上效果也要进行相应监控,如效果不好要对效果进行报警,以便算法人员对情况进行处理.
推荐系统本身涉及算法层,数据层,业务层,线上服务多个层,实际也会涉及多个组,怎样沟通效率以及开发效率以及
整个系统架构开发灵活性也是每个参与其中的人应该去思考的.其他公司同学也遇到类似问题,我们也进行相应沟通,能够
效率最大化沟通就是我们一致的目标.
推荐系统抽象性需要对推荐业务有足够理解,并能跳脱推荐业务站在更高层次,将系统进行组件式,动态式,配置化设计
以及实现.一是避免重复开发,一是留有更多时间去思考如何去做更有价值的事.
推荐系统不单单是去不断提升转化率,点击率,gmv,同时我们也要多考虑考虑怎么样给用户带去更多有价值内容,有价
值信息,不单单是推荐一些低俗无底线内容来达成 kpi,如果工作全部以 kpi 为导向,我们最终能获得多少提升呢?
最近一段时间对于推荐系统一点总结,以便后续查看,如对读者有些帮助,就更好了.
来源: https://www.cnblogs.com/freedommovie/p/8267855.html