京东个性化推荐系统实战(下)



转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com

AIQ 机器学习大数据 知乎专栏 点击关注

转载自微信公众号: 杉枫 互联网开发者 Club

推荐系统架构,推荐系统由品类平台,素材、特征召回平台、模型计算打分服务,排序服务构成。

       将请求封装成 QueryInfo 对象,通过对象来向下完成一步步数据召回。首先是通过 QueryInfo 对象召回品类、分类信息。

       前边有人问到是怎样实现通用化?好问题,当时答得不太好,现在梳理总结一下,分类平台通过配置品类、分类信息,配置选取个数、配置过滤品类信息,通过每一种配置情况构建分类信息,分类信息完全由配置文件构成。

       召回品类扩展 QueryInfo 对象构成 QueryInfoExtern 对象,为下一步进行素材、特征召回做准备,因为品类、分类数据量少,传输时不会因为数据量消耗太多时间,而素材、特征召回量极大,可通过分布式形式将素材进行召回,此时召回量最大可满足线上服务要求,召回之后,每组分别进行打分计算,打分之后进行取前边数据进行返回。

       再由品类召回节点合并将高分素材进行返回,熟悉 ElasticSearch 同学,会发现和 ElasticSearch 集群架构很像,其实推荐本身和搜索就有很多相似之处,研究搜索引擎对于推荐引擎构建也会大有益处。

       数据返回之前由排序服务对数据按展示效果进行商品按照品类、分类进行分隔,文章内容按标签、主题进行分隔。分隔目的是为了好的展示效果,提升用户体验,通过上面这一系列过程构建成推荐系统大致过程。

       除了上边架构逻辑,还存在存储以及数据流转体系。分类、素材、特征存储在 redis、HBase 中供服务读取使用。

       对于实时反馈,用户点击、浏览会通过存储在 redis 中用于过滤,以及调整后续推荐分类、素材权重,已作为一种最实时反馈手段。

       上报特征本身通过 JDQ 消息队列进行上报,上报异步进行,通过先写日志文件再上报日志文件内容,来达到异步上报,以避免同步上报导致线上服务性能受影响。JDQ 本身基于开源 kafka 打造。

       JDQ 本身为了资源情况限制上报速度为 5M/s, 为了更好利用上报机器资源,会构建内存队列,充分利用内存资源来控制发送速度,而不是一味通过扩容来解决问题。

       日志白名单本身按照服务、属性、关键字进行存储,在 ElasticSearch 中可方便按属性、关键词检索使用,通过图形化界面展示,方便快速定位线上问题。

       监控本身除了 Ump 对系统功能、性能、可用性进行监控,引擎本身就要配备全面监控避免程序某个分支存在问题,导致线上服务正确性、可用性存在问题,再有因为程序很多由配置文件动态构成,性能也要进行全面监控。

       对于线上效果,线上模型与分支进行绑定,当分支 A 效果实时效果好于 B 效果,要将线上模型进行更新调整,监控时间以几个小时效果为准。线上效果也要进行相应监控,如效果不好要对效果进行报警,以便算法人员对情况进行处理。

       最近一段时间对于推荐系统一点总结,以便后续查看,如对读者有些帮助,就更好了。


更多高质资源 尽在AIQ 机器学习大数据 知乎专栏 点击关注

转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com