京东个性化推荐系统实战（下）

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

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

       前边有人问到是怎样实现通用化？好问题，当时答得不太好，如今梳理总结一下，分类平台经过配置品类、分类信息，

配置选取个数、配置过滤品类信息，经过每一种配置状况构建分类信息，分类信息彻底由配置文件构成。

 

       召回品类扩展QueryInfo对象构成QueryInfoExtern对象，为下一步进行素材、特征召回作准备，由于品类、分类数据量

少，传输时不会由于数据量消耗太多时间，而素材、特征召回量极大，可经过分布式形式将素材进行召回，此时召回量最大

可知足线上服务要求，召回以后，每组分别进行打分计算，打分以后进行取前边数据进行返回。

       再由品类召回节点合并将高分素材进行返回，熟悉ElasticSearch同窗，会发现和ElasticSearch集群架构很像，其实推

荐自己和搜索就有不少类似之处，研究搜索引擎对于推荐引擎构建也会大有益处。

 

       数据返回以前由排序服务对数据按展现效果进行商品按照品类、分类进行分隔，文章内容按标签、主题进行分隔。分隔

目的是为了好的展现效果，提高用户体验，经过上面这一系列过程构建成推荐系统大体过程。

 

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

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

反馈手段。

       

 

       上报特征自己经过JDQ消息队列进行上报，上报异步进行，经过先写日志文件再上报日志文件内容，来达到异步上报，

以免同步上报致使线上服务性能受影响。JDQ自己基于开源kafka打造。

       JDQ自己为了资源状况限制上报速度为5M/s,为了更好利用上报机器资源，会构建内存队列，充分利用内存资源来控制发

送速度，而不是一味经过扩容来解决问题。

 

       日志白名单自己按照服务、属性、关键字进行存储，在ElasticSearch中可方便按属性、关键词检索使用，经过图形化界

面展现，方便快速定位线上问题。

       监控自己除了Ump对系统功能、性能、可用性进行监控，引擎自己就要配备全面监控避免程序某个分支存在问题，致使

线上服务正确性、可用性存在问题，再有由于程序不少由配置文件动态构成，性能也要进行全面监控。

 

       对于线上效果，线上模型与分支进行绑定，当分支A效果实时效果好于B效果，要将线上模型进行更新调整，监控时间

以几个小时效果为准。线上效果也要进行相应监控，如效果很差要对效果进行报警，以便算法人员对状况进行处理。

       推荐系统自己涉及算法层、数据层、业务层、线上服务多个层，实际也会涉及多个组，怎样沟通效率以及开发效率以及

整个系统架构开发灵活性也是每一个参与其中的人应该去思考的。其余公司同窗也遇到相似问题，咱们也进行相应沟通，可以

效率最大化沟通就是咱们一致的目标。

       推荐系统抽象性须要对推荐业务有足够理解，并能跳脱推荐业务站在更高层次，将系统进行组件式、动态式、配置化设计

以及实现。一是避免重复开发，一是留有更多时间去思考如何去作更有价值的事。

       

       推荐系统不仅仅是去不断提高转化率、点击率、gmv，同时咱们也要多考虑考虑怎么样给用户带去更多有价值内容，有价

值信息，不仅仅是推荐一些低俗无底线内容来达成kpi，若是工做所有以kpi为导向，咱们最终能得到多少提高呢？

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

            扫码关注