【对标TensorFlow】阿里公开内部超大规模分布式机器学习平台
论文《鲲鹏：基于参数服务器的分布式学习系统及其在阿里巴巴和蚂蚁金服的应用》（KunPeng: Parameter Server based Distributed Learning Systems and Its Applications in Alibaba and Ant Financial），由蚂蚁金服人工智能部和阿里云团队的周俊，李小龙，赵沛霖，陈超超，李龙飞，杨新星，崔卿，余晋，陈绪，丁轶，漆远合作完成。
文中描述的实验在十亿级别的样本和特征数据上进行。结果表示，鲲鹏的设计使得一系列算法的性能都得到了极大的提升，包括 FTRL，Sparse-LR，以及 MART。此外，鲲鹏在阿里巴巴“双11”狂欢购物节及蚂蚁金服的交易风险检测中，体现出了巨大的应用价值。
研究背景：工业界需要能够训练 TB-PB 级数据量的机器学习平台
现在是个大数据的时代，各个平台的数据量都与时俱进。举例而言，国外的 Twitter 每天新增 5 亿条Tweets，阿里巴巴每天有 5000 万个包裹，蚂蚁金服的支付宝交易峰会达到 12 万笔/秒，仅仅在 2016 年“双11”当天就产生了 10.5 亿笔交易。
如此大的数据量，使得机器学习不得不面临着样本及特征规模巨大的挑战。例如，阿里巴巴内部的模型会达到千亿样本，百亿特征，TB-PB 级的训练数据量。因此，如果搭建能够训练如此大规模数据的机器学习平台是工业界面临的一个巨大问题。
图 1：阿里某生产集群中 MPI 任务状态
目前，业界已经有一些比较成熟的分布式处理框架，如 Hadoop，Spark，GraphLab 和 GraphX。虽然它们可以支持机器学习算法并行化，但它们很难让开发人员设计出更有效率且支持更大规模的机器学习算法。
具体而言，Hadoop 和 Spark 虽然提供了一些同步和粗粒度运算符（例如，Map，Reduce 和 Join 等），但主要还停留在解决中小规模机器学习的问题。GraphLab/GraphX 主要是为了图存储和计算，并不适用于普通的大规模机器学习算法。MPI 虽然能够支持普通的分布式计算，但其缺乏容错机制。特别是在 worker 很大的情况下，MPI 的运行成功率会大大降低，如图1所示。
因此，如何设计更有效率且支持更大规模的机器学习算法，就成为一个业界难题。
鲲鹏：
超大规模分布式计算系统 + 超大规模分布式优化算法
为了解决这一问题，蚂蚁金服人工智能部&阿里云团队开发了鲲鹏。
鲲鹏取名自《庄子·逍遥游》，文中记载“北冥有鱼，其名曰鲲。鲲之大，不知其几千里也；化而为鸟，其名为鹏。鹏之背，不知其几千里也。怒而飞，其翼若垂天之云。”
研究人员表示，在他们的鲲鹏系统中，“鲲”即是超大规模分布式计算系统，拥有超强的计算能力；而“鹏”即是超大规模分布式优化算法，建立在“鲲”之上。“鲲鹏”即同时拥有超大规模分布式计算系统及超大规模分布式优化算法，合二为一使得它有“一飞冲天”的能力，如图2 所示。
图 2：鲲鹏的研究动机及创新性
在系统方面，鲲鹏的创新在于它拥有了以下功能：
强大的容错功能，甚至在复杂且忙碌的线上集群环境中
Backup Instance for Straggler Management
支持有向无循环图形式的调度和同步，包括BSP/SSP/ASP
用户友好的界面和编程
从算法创新角度看，鲲鹏架构使得常用的机器学习算法的大规模化成为了可能，截止目前，已经有众多机器学习算法在鲲鹏上得以实现和应用，包括但不限于LR，FTRL，MART，FM，HashMF，DSSM，DNN，LDA。
鲲鹏的总体架构
鲲鹏的架构建立在阿里巴巴集团内部的大规模分布式 Apasra 平台上面，拥有Robust Failover、Backup Instance，以及 DGA for Scheduling & Synchronization 等特性。
图3：鲲鹏的架构
图3 中的核心模块包括以下几部分：
Server nodes：对模型做分片存储
Worker nodes：对训练数据做分片并计算
Coordinator：控制算法整体流程，如初始化，迭代，终止等
ML Bridge：使用脚本形式的工作流对数据进行预处理
PS-Core：核心的参数服务器组件 (servers/workers/coordinator)
Fuxi：监控所有机器运行状态，必要时进行容错
用户视角
鲲鹏系统的调用，对普通用户而言也非常简单。用户只需要使用简单的几行脚本形式的命令，即可完成整个算法的调度。整个过程主要包括：
数据预处理，准备成算法接受格式
构建算法的输入/出表
调用鲲鹏算法，ps_train -i demo_batch_input -o demo_batch_result -a xxAlgo -t
xxTermination;
评估算法效果
进行A/B测试
图 4：鲲鹏架构用户视角
从图4 中可以看出，整个流程对用户而言都是透明的，使用过程也“如丝般顺滑”，不用感知算法背后复杂的优化及调度过程。
开发者视角
鲲鹏架构对普通的机器学习算法开发者而言也非常简单，它将复杂的通信及调度过程包装成了 API。例如，Worker.PullFrom(Server)，开发者只需要这一行简单的代码即可把模型从 server 端 pull 到 worker 端。再如，SyncBarrier()，这开发者只需要这一行简单的代码即可完成 server 端模型的同步。
图 5：鲲鹏架构开发者视角
实验结果
1. 与 Spark 和 MPI 比较
图 6：鲲鹏与 Spark 和 MPI 训练时间及内存消耗对比
图6 显示了在 7 个不同数据集上（D1-D7），鲲鹏与 Spark 和 MPI 的逻辑回归算法（LR）训练时间及内存消耗对比。如 D1(460K,20M) 指该数据集包含了 46 万特征，2000 万样本。从中可以看出，Spark 和 MPI 的 LR 在特征超大的情况下（D7）会出错，而鲲鹏的LR则可顺利训练成功。
2. Kunpeng-MART 与 XGBoost 比较
图 7：Kunpeng-MART 与 XGBoost 内存消耗对比结果
图7 显示了基于鲲鹏实现的 Multiple Additive Regression Trees（MART）与开源的 XGBoost 在 4 个不同数据集上的对比结果。从中可以看出，基于鲲鹏的 MART 内存使用情况要稳定的低于 XGBoost。此外，我们在 Ads CVR2 数据上重复跑了 10 次 XGBoost，但无一成功得到结果。
图8 显示了基于鲲鹏的 MART 和 XGBoost 在相同数据集上运行时间的对比，其中也可以看出基于鲲鹏的 MART 训练时间要优于 XGBoost。
图 8：Kunpeng-MART 与 XGBoost 训练时长对比结果
3. 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），已经广泛被应用于搜索、广告和智能客服等业务中。总体来说，鲲鹏系统上的 10 多个成熟算法已经被广泛应用于 120 多个产品中，这些无一不是阿里生态体系内最大规模的算法。