魅族推荐平台架构
摘要
魅族是一家智能手机研发公司，也是一家互联网公司，拥有超大规模的用户量及海量数据量，魅族推荐平台实现了在海量的数据中对算法模型进行在线及离线训练，在高并发的场景下实时进行预测为用户推荐更感兴趣的信息。同时支撑多算法组合A/B测试，以供算法进行在线实验，并能在线进行动态机器资源分配以达到资源的最大化利用。
推荐介绍
推荐能做什么
推荐可以在合适的场景或时机，通过合适的渠道，把相关内容推荐给合适的用户。
推荐的作用
推荐可以提升整体的系统目标，增加用户粘性，提高用户忠诚度，发现长尾。
推荐在魅族中的应用
推荐效果
与人工编辑相比，推荐的优势非常明显；而与行业内的一线公司相比，我们有超越他们的地方，也有还需要努力的部分。
魅族推荐平台架构演进
推荐平台需要做的事
平台的核心需求：
支撑5个以上的大产品线的不同场景的推荐业务需求，保证业务稳定运行，可用性达到99.9%，推荐场景当次请求响应在100毫秒以内，一天需要支撑亿级别的PV量。
技术难点：
1、针对于每一个用户的一次推荐需要从万级甚至是十万级别以上的物品中进行挑选用户可能感兴趣的物品。
2、每一次推荐需要同时计算十个甚至是数十个算法数据，一个算法需要计算成百上千个维度。
3、一天需要实时处理上亿条行为日志，进行百亿到千亿次计算。
4、每天需要访问数据存储上十亿次以上。
5、每天需要支撑上百个数据模型在线更新及实验。
推荐平台第一代架构——存在的问题
离线计算量大，需要将所有用户的数据进行结果计算，同时浪费机器资源；
结果数据更新困难，大批量数据更新对数据库冲击大，可能直接造成用户访问超时，服务不可用；
数据更新延时大，超大数据量计算基本上只能实现T+1的方式进行数据更新，所以数据推荐都是基于旧行为数据进行预测；
数据库的瓶颈直接影响算法结果数据输出频率，算法调优困难；
扩展困难，所有结果数据已经固定输出，很难插入一些业务上特定的需求。
推荐平台第二代架构——优势
用户推荐数据实时根据用户请求进行计算，减少离线计算量及减少数据存储空间；
原始模型的输出到线上比起结果数据输出更轻便，对线上性能影响更小，更方便于算法在线调优；
模块分离，业务各性化处理与模型计算分离，系统更抽象化，可复用度越高，可扩展性越好。
推荐平台第二代架构——存在的问题
模型离线训练，用户实时产生的行为无法反馈到模型当中；
业务混布，各业务之间相互影响；
由于把离线的部分计算放到线上进行计算，在请求过程中计算量增大，系统相应时长挑战增大；
业务接入越多，模型会越来越多，单台机器已经无法装载所有的模型。
魅族推荐平台现状
三代架构的核心需求
集群资源动态管理，解决模型存储及计算资源利用率问题；
用户行为数据能够实时的进行计算，并最终反馈到模型，提高推荐结果的准确性；
优法算法模型训练过程，将大部分工作能通过可视化的方式完成，提高工作效率；
解决业务之间的互相影响，优化高效的性能及稳定性。
推荐平台架构分层
推荐系统被分为三层。
Offline运算层：该层主要是离线对海量的数据进行建模加工，生产有价值的数据，如Item相似库、user相关库、CF离线推荐结果等。
Nearline运算层：该层主要是利用流式处理的技术对用户实时产生的行为日志进行加工，利用一些高效、高性能的算法生产有价值的数据。
Online运算层：该层主要处理一些相对简单的运算逻辑，在线进行计算。
在线模块——OpenAPI
统一接入规范：所有应用接入按照统一规范进行接入，所有提供出去的接口模式统一，这样大大降低接入方的难度。
路由：根据用户标识、版本、服务器IP以及权重规则路由到不同的Online计算插件服务。这样一来可以实现流量分流、A/B Test、灰度发布的目的、接口代理。
接入权限管理：统一管理接口调用权限。
统一监控：统一进行业务设用监控，如业务调用量、QPS、响应时长、业务设用失败告警等。
A/B测试模块
在推荐平台中最重要的一个功能就是A/B测试，A/B测试主要是对用户进行抽样分流道不同的算法组合当中，最后通过评估数据来驱动算法工程师对算法效果不断的进行调优。
A/B测试效果评估过程
用户请求数据后，APP端及Web端对用户看到的推荐数据所产生的一系列行为进行上报，数据采集服务端对日志数据进行收集并通过流平台将数据进行归并，同时对部分的实时数据进行在线统计分析，最终产生效果评估数据。
在线模块——计算模块
业务策略计算主要是处理业务相关的一些排序、过滤、人工干预竞价排名等与具体业务相关的逻辑，不同的业务各性化需求采用插件化的方式进行接入。
初始化模块主要处理算法模型的管理（模型加载、卸载，存储等等）、模型计算。
推荐一般性的数据处理过程从召回阶段到预测再到业务重排阶段，数据量依次减少。
精选阶段的数据是来源于召回的数据，有可能同时存在几个或者十几个召回算法，对不同召回的数据及相关的资源可能存储在不同的机器上或数据库中，所以请求接收点结在接收请求后，需要根据配置将不同的处理请求分发到不同的机器上进行计算，然后再归并返回。
近线模块
该层主要是利用流式处理的技术对用户实时产生的行为日志进行加工，利用一些高效、高性能的算法生产有价值的数据，如处理算法数据召回、实时数据统计等等。
资源管理调度
机器动态划分分组，可以按业务进行划分，也可以按照模型资源情况进行划分。
解决业务之间相互影响，按照业务对性能的要求及复杂度分配不同的硬件机器。同时能够整合资源，不同大小的配置都可以在集群中得到应用。
解决内存模型存储限制问题，将模型分散到不同的集群中进行横向扩展。
在请求过程中，请求根据master进行动态调度，大型资源加载过程中机器请求自动调度到其它机器，解决大型资源加载过程中对业务的影响。
在线模块——存储
在存储上多样性，不同类型的组合使用，根据不同的场景与性能指标采用不同的存储组合。
LocalCache：一般用来处理一次请求中访问数据频次超高但数据容量不需要太大的数据，如LR模型数据。
Mysql、Hbase、Redis：这三种存储的选择一般从性能和各自的特性出发点来选择是最合适的，各自都是集群的方式，Mysql可以按业务数据进行拆分成不同的集群进行访问。
离线——机器学习平台
提供特征工程、统计、训练、评估、预测和模型发布等功能，覆盖机器学习全流程，可以通过拖拽的方式完成模型训练和评估。
模型训练及评估界面化，与调度平台无缝集成，使得算法离线模型处理及模型发布上线等更加高效简单。
系统集成多种算法可进行逻辑回归LR、聚类Kmeans、模型LDA、协同过滤CF等多种模型训练。
进行分布式数据处理与计算。
监控告警
细粒度性能监控，可以细粒度到具体的业务请求接口，从业务QPS、PV量、响应时长等等；
应用服务器及操作系统各项指标监控；
业务指标监控，如算法效果及其它业务指标监控；
监控指标可根据具体的需求扩展。
魅族推荐平台挑战和愿景
挑战10亿/每天以上在线实时计算请求PV数；
支撑起百亿条/每天的日志进行实时计算，毫秒级别地进行用户模型更新；
支撑更多的特征集计算，同时在线计算响应时长更短；
支撑更多的魅族产品线业务；
推荐平台对外开放，能为行业其它的企业提供专业的推荐服务；
深度学习集成。
今天的分享到此结束，谢谢大家！