首页 > 代码库 > 倪江利：魅族推荐平台的架构演进之路
倪江利：魅族推荐平台的架构演进之路
摘要：魅族拥有超大规模的用户量及海量数据，魅族推荐平台实现了在海量的数据中对算法模型进行在线及离线训练，在高并发的场景下实时进行预测为用户推荐更感兴趣的信息。同时支撑多算法组合A/B测试，以供算法进行在线实验，并能在线进行动态机器资源分配以达到资源的最大化利用。
魅族整个产品线都有用到推荐，包括资讯、视频、应用中心、个性化中心、广告等业务，魅族的推荐平台在其中起到了关键的作用，下文将会全面分析从开始到现在的架构演进，以及其中涉及的技术难点分析，以期给读者带来更多的思考。
一、魅族推荐平台架构演进
- 平台的核心需求
支撑5个以上大产品线在不同场景下推荐业务的需求； 保证业务稳定运行，可用性达到99.9%； 推荐场景当次请求响应在200毫秒以内； 广告预测场景当次请求响应在100毫秒以内； 一天需要支撑亿级别的PV量。 2. 技术难点：
针对于每一个用户的一次推荐需要从万级甚至是十万级别以上的物品中进行挑选用户可能感兴趣的物品； 每一次推荐需要同时计算十个甚至是数十个算法数据，一个算法需要计算成百上千个维度； 一天需要实时处理上亿条行为日志，进行百亿到千亿次计算； 每天需要访问数据存储上十亿次； 每天需要支撑上百个数据模型在线更新及实验。 三、魅族推荐平台架构的演变过程
3.1 第一代架构
[+]查看原图
上图展示的是我们的第一代架构，在这个图里可以看到整个过程比较简单，可以通过这个一线模型计算，计算以后整个用户的数据通过这个模型直接写到库里。
第一代架构存在的问题
这个架构能够满足网站用户访问量在几十万或者几百万规模的数据处理需求。但是当用户访问量呈现大规模增长，问题就暴露出来了。
离线计算量大，需要将所有用户的数据进行结果计算,同时浪费机器资源； 结果数据更新困难，大批量数据更新对数据库的冲击大，可能直接造成用户访问超时,服务不可用； 数据更新延时大，超大数据量计算基本上只能实现T+1的方式进行数据更新，所以数据推荐都是基于旧行为数据进行预测； 数据库的瓶颈直接影响算法结果数据输出频率，算法调优困难； 扩展困难，所有结果数据已经固定输出，很难插入一些业务上特定的需求。
3.2 第二代架构
[+]查看原图
从图中可以看到，第二代架构开始有了清晰的分层。
整个架构分为两层：
第一层是离线，离线是处理大批量的模型计算，根据离线日志，计算只会产生数据算法的模型。也就是说这个计算只产生了数据模型，而不会计算所有用户并推荐内容，所以比实际推荐结果要小很多，可能只有几百兆或几个G的内容，存储量减少。 第二层是在线，我们把在线模块切割成3个板块：OpenAPI、业务策略计算、实际模型计算。
针对于模型计算板块这个架构的有很多优势。因为从这一代开始变成实时计算，都是基于模型实时在线计算出来，原始的模型推荐的实际数据处理起来方便很多，难度也会减少。
总结起来第二代架构的优势有：
用户推荐数据实时根据用户请求进行计算，减少离线计算量及减少数据存储空间； 模块分离，业务各性化处理与模型计算分离，系统更抽像化，可复用度越高及可扩展性越好； 原始模型的输出到线上比起结果数据输出更轻便，对线上性能影响更小，更方便于算法在线调优。 当然也还是存在一些问题：
模型离线训练，用户实时产生的行为无法反馈到模型当中，可能造成推荐结果数据的延迟； 业务混布，各业务之间相互影响； 由于把离线的部分计算放到线上进行计算，在请求过程中计算量增大，系统响应时长挑战增大； 业务接入越多，模型会越来越多，单台机器已经无法装载所有的模型。
二、魅族推荐平台现状
- 第三代架构的核心需求
为了解决上述问题，我们对魅族推荐平台架构进行了优化。根据业务需要以及对一二代架构优缺点的总结，我们首先确定了第三代架构的核心需求：
集群资源动态管理，解决模型存储及计算资源利用率的问题 用户行为数据能够实时的进行计算，并最终反馈到模型，提高推荐结果的准确性 优法算法模型训练过程，将大部分工作能通过可视化的方式完成，提高工作效率 解决业务之间的相互影响 优化高效的性能及稳定性
2、推荐平台数据处理模型 上图是推荐平台数据处理的模型，我们把整个流程切割成几块，离线、近线、在线部分，不同的阶段处理不同的事情，处理数据量级别及复杂度也在各阶段不断的减少.
3、 推荐平台现有架构
[+]查看原图 上图是推荐平台现有架构图，我们有一些资源管理和在线计算，还有机器学习平台解决离线计算的问题。
3.1 推荐平台架构分层
看架构主要看里面的层次。魅族推荐平台现有架构分为三层：
offline运算层（离线计算）：该层主要是离线对海量的数据进行建模加工，生产有价值的数据，如Item相似库、user相关库、CF离线推荐结果等。 nearline运算层: 该层主要是利用式处理的技术对用户实时产生的行为日志进行加工，利用一些高效、高性能的算法生产有价值的数据 online运算层: 该层主要处理一些相对简单的运算逻辑，在线进行计算。 3.2 推荐架构各模块的实现原理
3.2.1 在线模块-OpenAPI
首先，统一接入规范 所有应用接入按照统一规范进行接入，所有提供出去的接口模式统一，这样大大降低接入方的难度。
其次，路由 根据用户标识、版本、服务器IP以及权重规则路由到不同的Online计算插件服务。这样一来可以实现实现流量分流、A/B Test、灰度发布的目的、接口代理。
第三，接入权限管理 统一管理接口调用权限。
第四，统一监控 统一进行业务设用监控，如业务调用量、QPS、响应时长、业务设用失败告警等。
3.2.2 A/B测试模块
在推荐平台中最重要的一个功能就是A/B测试，A/B测试主要是对用户进行抽样分流到不同的算法组合当中，最后通过评估数据来驱动算法工程师对算法效果不断的进行调优。它的好坏直接决定了算法以及对模型优化的难度。
在做A/B测试的时候我们会通过一定的抽样方式选取目标人群，根据一定的规则做配置，让他们访问不同的算法组合，我们再根据不同的组合做评估，上图中我只写了一个转化率，真正的评估数据不只这些。
3.2.3 A/B测试效果评估过程： [+]查看原图
用户请求数据后App端及Web对用户看到的推荐数据所产生的一系例行为进行上报，数据采集服务端对日志数据进行收集并通过流平台将数据进行归并，同时对部分的实时数据进行在线统计分析最终产生效果评估数据。
[+]查看原图
上图是截取的一个A/B测试效果评估图。真正的效果评估也不只这些，每一组业务场景的效果评估都是不一样的。
3.2.4 在线模块-计算模块
[+]查看原图
计算模块分为两大块：
第一大块是业务策略计算，主要是处理业务相关的一些排序、过滤、人工干预竞价排名等于具体业务相关的逻辑，不同的业务个性化需求采用插件化的方式进行接入；
第二大块是初始化模块，主要是对物品进行精选相关的计算，同时管理对新的算法的支持及模型的存储。
[+]查看原图
从图中看出，推荐一般性的数据处理过程从召回阶段到预测再到业务重排阶段数据量依次减少。
精选阶段的数据是来源于召回的数据，有可能同时存在几个或十几个召回算法，对不同召回的数据及相关的资源可能存储在不同的机器上或者数据库中，所以请求接收点结在接收请求后需要根据配置将不同的处理请求分发到不同的机器上进行计算然后再归并返回。
3.2.5 近线模块
[+]查看原图
该层主要是利用流式处理的技术对用户实时产生的行为日志进行加工，利用一些高效、高性能的算法生产有价值的数据,如处理算法数据召回、实时数据统计等等。
[+]查看原图
如图，近线模块-流式日志数据传输分为以下几个部分：
数据通过Uxip从移动端、Web端进行收集； 收集后的数据通过Agent转发到Flume进行专线或公网等网络传输； 在中心机房的Flume将日志数据等进行归并传输到MetaMq； 基于MQ消息可以对数据进行流式处理如实时计算、数据落地等等。 3.2.6 资源调度管理
如下图，机器动态划分分组，可以按业务进行划分，也可以按照模型资源情况进行划分。
资源调度管理的作用在于：
解决单机重组问题，降低业务之间的相互影响,按照业务对性能的要求及复杂对分配不同的硬件机器。同时能够整合资源，不同大小的配置都可以在集群中得到应用； 解决内存模型存储限制问题，将模型分散到不同的集群中进行横向扩展； 在请求过程中请求根据Master进行动态调度，大型资源加载过程中机器请求自动调度到其它机器，解决大型资源加载过程中对业务的影响 3.2.7 在线模块-存储
在存储上实现多样性，根据不同的场景与性能指标采用不同类型的存储组合，实现业务隔离，根据模型的存储情况划分结果，实时调动管理所有分配数据。
LocalCache：一般用来处理一次请求中访问数据频次超高但数据容量不需要太大的数据，如LR模型数据。
Mysql、Hbase、Redis：这三种存储的选择一般从性能和各自的特性出发点来- 选择最合适的，各自都是集群的方式，MySql可以按业务数据进行拆分成不同的集群进行访问。
3.2.8 离线-机器学习平台
[+]查看原图
我们的离线-机器学习平台可以呀提供特征工程、统计、训练、评估、预测和模型发布等功能，覆盖机器学习全流程，算法同学可以通过拖拽的方式就能完成模型训练和评估。
其优势在于：
模型训练及评估界面化，与调度平台无缝集成，使得算法离线模型处理及模型发布上线等更加高效简单； 系统集成多种算法可进行逻辑回归LR、聚类Kmeans、模型LDA、协同过滤CF等多种模型训练； 分布式数据处理与计算。 3.2.9 监控告警
[+]查看原图
整个模型和训练的过程都是处于离线和分布式环境下，监控在整个系统中必不可少。我们的监控告警系统的特点是：
细粒度性能监控，可以细粒度到具体的业务请求接口，从业务QPS、PV量、响应时长（P50.P70,P99,P999…）等； 应用服务器及操作系统各指标监控； 业务指标监控，如算法效果及其它业务指标监控； 监控指标可根据具体的需求扩展。
三、魅族推荐平台挑战和愿景
挑战10亿/每天以上在线实时计算请求PV数； 支撑起百亿条/每天的日志进行实时计算，毫秒级别的进行用户模型更新； 支撑更多的特征集计算，同时在线计算响应时长更加的短； 支撑更多的魅族产品线业务； 推荐平台对外开放，能为行业其它的企业提供专业的推荐服务； 深度学习集成。
本文来自由魅族和麦思博（msup）联合主办的魅族技术开放日第七期——数据探索，邀请了腾讯、华为等企业的4位技术专家，深入剖析了企业如何利用数据以及将数据转化为有价值的信息。
倪江利：魅族推荐平台的架构演进之路