如何搭建大规模机器学习平台？以阿里和蚂蚁的多个实际场景为例

最新推荐文章于 2024-07-24 14:16:22 发布

技术边城

最新推荐文章于 2024-07-24 14:16:22 发布

阅读量304

点赞数

分类专栏：互联网文章标签：大数据

互联网专栏收录该内容

13 篇文章 0 订阅

订阅专栏

导读：近年来，随着“大”数据及“大”模型的出现，学术界和工业界对分布式机器学习算法引起了广泛关注。针对这一刚需，本论文设计了一个独一无二的分布式平台——鲲鹏。它无缝的结合了分布式系统及并行优化算法，解决了大规模机器学习算法带来的一系列问题。鲲鹏不仅囊括了数据/模型并行、负载平衡、模型同步、稀疏表示、工业容错等特性，而且还提供了封闭好的、宜于调用的API供普通的机器学习者开发分布式算法，降低使用成本并提升效率。

本论文的实验在十亿级别的样本和特征数据上进行，结果表示，鲲鹏这一设计使得一系列算法的性能都得到了极大的提升，包括FTRL，Sparse-LR，以及MART。此外，鲲鹏在阿里巴巴双11狂欢购物节及蚂蚁金服的交易风险检测中体现出了其巨大的应用价值。

研究背景

现在是个大数据的时代，各个平台的数据量都与时俱进。举例而言，国外的Twitter每天新增5亿条Tweets，阿里巴巴每天有5000万个包裹，蚂蚁金服的支付宝交易峰会达到12万笔/秒，仅仅在2016年双11当天就产生了10.5亿条交易。如此大的数据量使得机器学习不得不面临着样本及特征规模巨大的挑战。例如，阿里巴巴内部的模型会达到千亿样本，百亿特征，TB-TP级的训练数据量。因此，如果搭建能够训练如此大规模数据的机器学习平台是工业界面临的一个巨大问题。

已有方法介绍

图1阿里某生产集群中MPI任务状态

目前，业界已经有一些比较成熟的分布式处理框架，如Hadoop，Spark，GraphLab和GraphX。虽然它们可以支持机器学习算法并行化，但它们很难让开发人员设计出更有效率且支持更大规模的机器学习算法。具体而言，Hadoop和Spark虽然提供了一些同步和粗粒度运算符（例如，Map，Reduce 和 Join 等），但主要还停留在解决中小规模机器学习的问题。

GraphLab/GraphX主要是为了图存储和计算，并不适用于普通的大规模机器学习算法。MPI虽然能够支持普通的分布式计算，但其缺乏容错机制。特别是在worker很大的情况下，MPI的运行成功率会大大降低，如图1所示。因此，如何设计更有效率且支持更大规模的机器学习算法成为一个业界难题。

鲲鹏的研究动机及创新性

鲲鹏取名自《庄子·逍遥游》,文中记载“北冥有鱼，其名曰鲲。鲲之大，不知其几千里也；化而为鸟，其名为鹏。鹏之背，不知其几千里也。怒而飞，其翼若垂天之云。”在我们的鲲鹏系统中，“鲲”即是超大规模分布式计算系统，它拥有超强的计算能力；而“鹏”即是超大规模分布式优化算法，它建立在“鲲”之上。“鲲鹏”即同时拥有超大规模分布式计算系统及超大规模分布式优化算法，合二为一使得它有“一飞冲天”的能力，如图2所示。

图2鲲鹏的研究动机及创新性

系统创新

鲲鹏的创新在于它拥有了以下功能：

强大的容错功能，甚至在复杂且忙碌的线上集群环境中
Backup Instancefor Straggler Management
支持有向无循环图形式的调度和同步，包括BSP/SSP/ASP
用户友好的界面和编程

算法创新

鲲鹏架构使得常用的机器学习算法的大规模化成为了可能，截止目前，已经有众多机器学习算法在鲲鹏上得以实现和应用，包括但不限于LR，FTRL，MART，FM，HashMF，DSSM，DNN，LDA。

鲲鹏的架构

总体架构

图3鲲鹏的架构

鲲鹏的架构如图3所示，它建立在阿里巴巴集团内部的大规模分布式 Apasra 平台上面，拥有Robust Failover、Backup Instance，以及 DGA for Scheduling &Synchronization等特性。图3中的核心模块包括以下几部分：

Server nodes：对模型做分片存储

Worker nodes：对训练数据做分片并计算

Coordinator：控制算法整体流程，如初始化，迭代，终止等

ML Bridge：使用脚本形式的工作流对数据进行预处理

PS-Core：核心的参数服务器组件(servers/workers/coordinator)

Fuxi：监控所有机器运行状态，必要时进行容错

用户视角

图4鲲鹏架构用户视角

鲲鹏系统的调用，对普通用户而言也非常简单。用户只需要使用简单的几行脚本形式的命令，即可完成整个算法的调度。整个过程主要包括：

数据预处理，准备成算法接受格式
构建算法的输入/出表
调用鲲鹏算法，ps_train -i demo_batch_input -o demo_batch_result -a xxAlgo -t
xxTermination;
评估算法效果
进行A/B测试

从图4中可以看出，整个流程对用户而言都是透明的，使用过程也“如丝般顺滑”，不用感知算法背后复杂的优化及调度过程。

开发者视角

图5鲲鹏架构开发者视角

鲲鹏架构对普通的机器学习算法开发者而言也非常简单。它将复杂的通信及调度过程包装成了API。如，Worker.PullFrom(Server)，开发者只需要这一行简单的代码即可把模型从server端pull到worker端。再如，SyncBarrier()，这开发者只需要这一行简单的代码即可完成server端模型的同步。

实验结果

与Spark和MPI的比较

图6鲲鹏与Spark和MPI训练时间及内存消耗对比

图6显示了在七个不同数据集上（D1-D7），鲲鹏与Spark和MPI的逻辑回归算法（LR）训练时间及内存消耗对比。如D1(460K,20M)指该数据集包含了46万特征，2000万样本。从中可以看出，Spark和MPI的LR在特征超大的情况下（D7）会出错，而鲲鹏的LR则可顺利训练成功。

Kunpeng-MART与XGBoost比较

图7 Kunpeng-MART与XGBoost内存消耗对比结果

图7显示了基于鲲鹏实现的MultipleAdditive Regression Trees（MART）与开源的XGBoost在四个不同数据集上的对比结果。从中可以看出，基于鲲鹏的MART内存使用情况要稳定的低于XGBoost。此外，我们在Ads CVR2数据上重复跑了10次XGBoost，但无一成功得到结果。图8显示了基于鲲鹏的MART和XGBoost在相同数据集上运行时间的对比，其中也可以看出基于鲲鹏的MART训练时间要优于XGBoost。

图8 Kunpeng-MART与XGBoost训练时长对比结果

Worker数量对算法的影响实验

图9 Worker数量与算法加速及单Worker内存使用关系

图9显示了Worker数量与算法加速及单Worker内存使用的关系。在该实验中，我们使用的是基于鲲鹏的稀疏LR算法，特征约有70亿个，样本约有180亿个。从中可以看出，25个worker就能训练这些数据。而且随着worker的增多，算法训练速度倍增，同时单机上的内存使用会倍降。

总结

本文所提出的分布式学习系统——鲲鹏，拥有强大的分布式计算能力和算法优化能力，同时也有用户友好的界面和接口。在实际的在线或离线任务中，它能接受百亿特征，千亿样本和万亿参数。同时，它在生产集群中，有着很好的健壮性、灵活性、扩展性及高效性。此外，它在阿里和蚂蚁众多实际场景中发挥出了巨大的优势。例如，在2015年“双11”中，鲲鹏系统上实现的“楼层”排序（LR算法）使得UV CTR提升了21%，GMV提升了10%。

再如，基于鲲鹏实现的GBDT+DNN算法应用在支付宝交易风险评估业务中，该算法上线以来，相同覆盖度的情况下，案件召回率从 91% 增加到 98%，每天减少了几千万次用户的打扰。此外，在鲲鹏上实现的Deep Structured Semantic Model（DSSM）模型，已经广泛被应用于神马搜索，淘宝搜索，1688广告，蚂蚁智能客服等业务中。

总体来说，鲲鹏系统上的10+个成熟算法已经被广泛应用于120+个产品中，这些无一不是阿里生态体系内最大规模的算法。