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

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

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

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

配置选取个数、配置过滤品类信息，通过每一种配置情况构建分类信息，分类信息完全由配置文件构成。

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

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

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

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

荐本身和搜索就有很多相似之处，研究搜索引擎对于推荐引擎构建也会大有益处。

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

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

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

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

反馈手段。

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

以避免同步上报导致线上服务性能受影响。JDQ本身基于开源kafka打造。

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

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

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

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

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

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

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

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

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

整个系统架构开发灵活性也是每个参与其中的人应该去思考的。其他公司同学也遇到类似问题，我们也进行相应沟通，能够

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

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

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

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

值信息，不单单是推荐一些低俗无底线内容来达成kpi，如果工作全部以kpi为导向，我们最终能获得多少提升呢？

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