微软分布式云端机器学习应用探讨

云计算 分布式
如今,各类企业都在积聚越来越庞大的数据资产,比如用户行为、系统访问、使用模式等数据记录。而运用像微软Azure机器学习平台这样的云端服务平台,企业不仅仅可以用它来储存数据,做一些经典的“后视”商务智能分析,更能使用云端的强大力量做出具有“前瞻性”的预测分析。

[[136236]]

如今,各类企业都在积聚越来越庞大的数据资产,比如用户行为、系统访问、使用模式等数据记录。而运用像微软Azure机器学习平台这样的云端服务平台,企业不仅仅可以用它来储存数据,做一些经典的“后视”商务智能分析,更能使用云端的强大力量做出具有“前瞻性”的预测分析。使用Azure机器学习这样的现代化工具,企业可以获得关于其业务未来发展的切实见解——这将成为它们的竞争优势。

对“大数据”的收集和维护已经成为许多应用程序的普遍需求。随着数据量的剧增,分布式储存已成为必然趋势。在许多应用中,收集数据本身就是一个分散的过程,自然导致了分布式的数据储存。这种情况下,建立起以分布式计算处理分布式数据的机器学习(以下简称“ML”)方案就十分必要。这些方案包括:通过在线广告领域的逻辑回归分析来估计点击率,应用于大量图像和语音训练的数据集的深度学习方案,或为检测异常模式而进行的记录分析。

因此,在一个集群中对ML方案进行高效的分布式训练,是微软云信息服务实验室(CISL——Microsoft Cloud & Information Services Lab,发音像“sizzle”:-))的重要研究领域。本文,我们将对这一主题进行一些较为深入的探讨。下面所阐述的一些细节可能技术性略强,但我们会尽可能以简单易懂的方式来阐明它的中心思想。理解了这些想法,任何对大数据分布式ML感兴趣的人都会有所收获,我们也很期待你们的评论和反馈。

选择合适的基础设施

John Langford在近期发表的一篇文章中,介绍了用于快速学习的Vowpal Wabbit (VW) 系统,并简要谈及了对兆级数据集的分布式学习。因为大多ML的算法本质上是迭代,因此选择合适的分布式框架来运行它们就变得十分关键。

Map Reduce和它的开源实现Hadoop,是目前较为流行的分布式数据处理平台。但由于ML每次迭代都有巨大的开销——如作业调度,数据传送和数据解析,因此以上的分布式数据处理平台并不能很好的用于迭代性的ML算法。

一个更好的选择是增加通信基础设施,如与Hadoop兼容的All Reduce(像在VW中那样),或者采用更新的分布框架,如支持有效迭代运算的REEF。

统计查询模型 (SQM)

目前分布式ML***进的算法,如用于VW中的是基于统计查询模型(SQM--Statistical Query Model)的算法。在SQM中,学习是基于对每个数据点进行计算,然后将对所有数据点的运算结果进行累加。举例来说,假设线性ML问题的结果是一个特征向量与其权重参数向量的点积。这包含了逻辑回归、支持向量机(SVMs)和最小二乘方拟合(least squares fitting)等重要的预测模型。在这种情况下,每次迭代时的训练目标函数的整体梯度是由各个数据点的梯度相加而成的。每个节点形成与该节点的训练数据相一致的局部梯度,然后用All Reduce运算来获得整体梯度。

通信瓶颈

分布式运算常常要面临一个关键瓶颈,即运算与通信宽带之间的巨大比例差。举例来说,通信速度比运算速度慢10倍到50倍都很常见。

以Tcomm和Tcomp分别表示通信和运算的单次迭代时间,那么一个迭代性ML算法的总时间花费可用下列算式表示:

总时间 =(Tcomm + Tcomp)* #迭代次数

当节点增多时,Tcomp通常为线性下降,而Tcomm则上升或保持不变(All Reduce良好实施的情况下)。涉及大数据的ML方案经常有众多的权重参数(d),这些参数在每次迭代时都会在集群中的节点间通信、更新。此外,其他步骤如SQM中的梯度运算也需要复杂度为O(d)的 通信。这种情况在Map Reduce中更加不理想——每次迭代都需要一次独立的Map Reduce工作。因此,当参数d很大时,Tcomm也会变得很大。SQM并未在这方面的低效率问题上给予足够的重视。

攻克通信瓶颈问题

我们近期的研究正是针对这一关键问题,并建立在下述现象之上:假设Tcomm节点间权重参数的通信时间非常大。在每次迭代中,采用SQM这种标准方法会使得Tcomp每个节点内与运算相关的时间,远小于Tcomm。因此我们提出以下问题,有没有可能修改算法和其迭代,使Tcomp与Tcomm接近,并且在这个过程中,将该算法转变成为迭代次数较少的理想方案呢?

当然,回答这个问题并不简单,因为它意味着一次根本性的算法改变。

#p#

更多的具体细节

 

[[136237]]

接下来让我们考虑ML学习线性模型的问题。在我们的算法中,节点中权重更新和渐变的方式与SQM方式类似。然而,在每个节点中的渐变梯度(用All Reduce算出)和本地数据经过复杂的方式形成对全局问题的本地近似值。每个节点解决自己的近似问题,形成权重变量的本地更新,随后所有节点的本地更新结合形成权重变量的全局更新。每个节点解决近似问题时会导致其计算量增多,但不需要任何额外的通信。这样一来,虽然Tcomp增高,但因为Tcomm 本身就很高,因此每次迭代花费的时间并未受到显著影响。但是,由于每个节点现在解决的是近似全局视图的问题,解决问题需要的迭代数量将大大减少。设想在无比庞大的数据中,每个节点自身的数据就足以实现良好的学习。这种情况下,每个节点形成的近似问题就近似于全局问题,这样SQM的算法需要几百次甚至几千次的迭代时,我们的算法只需要一或两次迭代就能完成。此外,我们的方法也较为灵活,允许出现一系列的近似值而不只是一个特定值。总体来说,我们的算法比 SQM平均快了两到三倍。

 

也可以考虑将权重向量分散到多个集群节点中,建立分布式数据储存和运算方式,使任何一个权重变量的更新只发生在一个集群节点上。这在一些情况下非常有效,比如对线性ML问题中相关权重变量的归零问题,或者做分布式深度训练时。这样我们又一次建立了特殊的迭代算法,增加了每节点内的运算但减少了迭代的次数。

评估

上述我们重点关注的算法比较适合通信负担较重的情况,但这并不能解决在实际中的所有问题。对于一般的情况,最近的学术文献中有很多好的分布式ML算法,但目前对这些方法还没有一个细致的评测。***的方法还在寻找它们通往云端ML库的道路上。

根据用户需求的自动分布式ML

另外,还有一个重要的部分,即在云端上使用分布式ML的用户拥有不同的需求。他们也许对最短时间内产生方案感兴趣,也许认为最少花费产生方案很重要。在考虑上述变量进行***选择时,用户愿意牺牲一些精确度。另一种可能是,他们也许迫切地想知道最确切的结果,而不计时间和花费。考虑到问题描述、用户的不同要求和系统配置的可应用性细节,拥有一个能够选择合适算法和参数设定的自动程序十分重要。我们目前的研究也集中在这一方面。

原文链接:http://www.msra.cn/zh-cn/research/machine-learning-group/distributed-cloud-based-machine-learning.aspx

责任编辑:Ophira 来源: msra
相关推荐

2021-09-09 15:45:17

机器学习人工智能Ray

2015-11-11 14:01:26

微软开源分布式

2016-08-31 07:02:51

2018-11-07 09:23:21

服务器分布式机器学习

2017-12-05 14:55:56

2022-08-03 20:18:58

机器学习算法分析数据

2017-06-29 13:29:34

大数据PAI机器学习

2018-10-29 12:42:23

Ceph分布式存储

2017-09-11 15:19:05

CoCoA机器学习分布式

2018-12-05 10:30:16

微软分布式开源

2018-12-14 10:06:22

缓存分布式系统

2021-08-30 18:36:33

鸿蒙HarmonyOS应用

2019-10-10 09:16:34

Zookeeper架构分布式

2017-09-01 05:35:58

分布式计算存储

2019-06-19 15:40:06

分布式锁RedisJava

2023-05-29 14:07:00

Zuul网关系统

2021-04-06 16:25:56

分布式存储Fail-in-pla三副本架构

2011-04-01 14:28:58

zabbix应用proxy

2021-12-13 11:07:10

鸿蒙HarmonyOS应用

2024-01-08 08:05:08

分开部署数据体系系统拆分
点赞
收藏

51CTO技术栈公众号