Original 杉枫、最初的信仰 探索互联网 2017-12-27 01:27 Posted on

       推荐系统核心任务是排序，从线上服务角度看，就是将数据从给定集合中数据选择出来，选出后根据一定规则策略方法进行排序。

       线上服务要根据一定规则进行架构设计，架构设计是什么？每一次权衡取舍都是设计，设计需要理解需求、深入理解需求基础上做权衡取舍。复杂系统架构需要需求方与研发人员反复沟通探讨。这需要技术领导者能理解并鼓励这种行为，才能有所谓技术驱动，否则光喊口号不会产生什么所谓的技术驱动。

       品类召回配置化，通过对每一个key进行配置管理，配置项包含偏好取得数量以及卡分配置、排序优先级等多个配置项。每一个配置生成一个配置对象，配置绑定到一个ABTest算法上。配置管理界面、配置管理服务构成配置管理平台。

       素材、特征召回配置化，根据分类召回素材，根据用户、分类、素材、设备、季节等多个条件拉取素材。素材与特征全部通过配置化进行实现，由人管理配置文件由xml构成、

       素材、特征召回这两项特点是召回量大，要注意有大量此类偏好数量，这种数据获取最好用线程池，设置超时如超时则这次请求有部分数据未请求到，并进行记录。

       特征上报，为了方便模型组进行模型训练，因为一些数据是比较散的，就是说这种情况下需要对数据进行进行响应处理，在进行上报，每一种数据处理方式是不同的，需要对特征进行分类处理。

      并且为了避免增加新特征或者修改特征就进行上线，这是与模型组探讨，根据需求设计可配置，或者说基于配置文件的特征计算。要建立一套与特征归一化相应多种计算规则，以支持多种类型特征配置归一化。

       分类召回级平台，素材、特征召回级平台，均存在一个配置更新后怎样获取问题。配置更新是一个通用问题，大概存在几种方式：一种是配置管理界面更新时更新服务配置信息，一种是定时更新方式，一种是通过通知方式，当有变更时发起更新。

       最简单方式就是，在管理平台修改后进行更新，但现在线上服务多为微服务集群，通过更新管理平台，同时更新多个微服务节点不是一种可行方式，在过去单体web系统中是可行的。

       定时更新方式实现简单，并且能保证比较好一致性，并且就算这次更新集群存在个别节点更新失败，下一次更新也会更新成功。但这种方式要注意不要用线上服务定时拉取数据库，因为会导致数据库压力过大，可以采取将数据库节点数据同步到redis方式，通过redis来支持定时更新，因redis能支持极大读qps。

       通知方式最优雅，即观察者模式。观察者订阅事件，事件发生时，各个订阅节点根据事件进行响应操作，当配置更新发生时，线上服务节点更新配置到最新，通过Zookeeper可以很容易实现此种配置方式，其实也需要比较懂zookeeper原理与编程。

      过滤建立职责链进行实现，扩展性强，可读性强。分类过滤，最近购买过分类，分类过滤白名单。过滤包括但不限于用户已购买、以曝光。在问答业务上，像我提问我已经回答，构建职责链逻辑清晰易理解。

       配置化，通过配置文件实现整个逻辑通用化，是小伙伴最初的梦想和模型组构建出来配置化召回素材以及特征架构，很给力。通过配置实现对于品类素材特征召回，并且支持分层ABtest,并且配置中包含对特征计算，特征计算主要是上报特征用于模型计算，但是有些数据需要进行归一化处理，以方便模型训练使用。并且给人编辑配置文件为xml，通过程序转换成json，并且通过json来支持程序使用，能够方便程序进行解析，xml对人友好，json对程序解析友好。

       特征归一化是特征上报很重要一环，他的特点是情况多，要根据数据分布情况做相应处理，就需要提前归纳总结多种情况，因为反射性能差线上服务是接受不了的，就需要提前对数据处理分成几类，提前想好处理逻辑，根据配置项选择相应逻辑进行处理。

       上报特征服务、日志白名单服务，上报特征服务将两部分特征进行上报，一部分是简单特征由服务本身进行配置上报，另一部分是复杂特征由其他服务计算后调用上报特征服务，两部分合并进行特征上报。

       日志白名单平台，服务可以配置相应用户信息，并且提供服务支持其他服务上报用户在白名单中进行相应记录，并且提供平台界面支持检索。这样可以方便定位线上服务问题，快速解决问题。

       推荐系统是个复杂系统，由多个模块构成，构建推荐引擎，我们在一步步探索。