基于分布式云的机器学习

这篇文章由微软云与信息服务实验室(CISL)和微软研究院(Microsoft Research)的研究员Dhruv Mahajan，Sundararajan Sellamanickam和Keerthi Selvaraj撰写。

三百六十行，行行出数据。从有关用户行为的记录，到系统的访问，还有使用模式等等。使用像微软Azure这样的云服务平台，不能只是存储数据或是做做简单的传统的表面工作，而是应该用上基于云的预报分析的威力和规模，这样，任何公司都将会获益匪浅。使用现代工具，比如Azure机器学习(Azure Machine Learning)，公司可以获得有关未来如何发展的有可执行性的见解，进而获得竞争优势。

搜集和保存『大数据』正在变成许多应用普遍的需求。当数据大小爆炸式增长时，分布式的存储变得更加必要。在许多应用中，搜集数据本身就是一种无中心的过程，自然地导致分布式的存储。这种情况下，采用分布式计算来建构用于分布式数据的机器学习(ML)解决方案就变得尤为不可或缺。比如使用逻辑回归进行在线广告中的点击率统计、应用于大型图像或语音训练的数据库的深度学习解决方案和用于检测异常模式的日志分析。

那么，有效的在集群上的机器学习(ML)解决方案的训练就成为了笔者工作的微软云和信息服务实验室(CISL，读作‘sizzle’ :-))的一个重要的重点领域。在这篇文章中，我们在这个话题上深入一点，讨论一些相关的话题和我们最近试图解决一些相同问题的研究。在这里展示的有些细节非常有技术含量，但是我们试图用尽可能简单的方式解释主要观点。任何对大数据上的分布式机器学习(ML)有兴趣的人都会通过理解这些观点有所收获，而且我们也很期待你们的评论和反馈。

选择正确的设备

在一篇最近的文章中，John Langford描述了用于快速学习的Vowpal Wabbit(VW)系统，他简略地尝试了超过万亿级的数据库。大多数机器学习(ML)算法都是迭代的，选择正确的分布式架构来运行他们非常关键。

Map Reduce和它的开放的源代码和Hadoop都是分布式数据处理的很流行的平台。然而，它们并不适用于迭代的机器学习(ML)算法，因为每一次迭代都开销巨大——比如作业调度、数据传输和数据解析。

更好的选择是添加通讯装置，比如All Reduce，它和Hadoop兼容(VW也一样)，或者使用更新的分布式架构，比如REEF，它支持高效迭代运算。

SQM

现在最先进的分布式机器学习(ML)算法，例如VW中的那个，都是基于统计查询模型(SQM)。在SQM中，学习是基于在每个数据点上都进行一些运算并把所有数据点的结果信息累积起来。比如，设想一种线性机器学习(ML)问题，输出结果是特征向量和权重参数向量的点积。这就包括重要的预报模型，比如逻辑回归、SVMs和最小二乘法拟合。在这个案例中，每次迭代，训练目标函数的总梯度都是与每个单独的数据点相关的梯度相加计算得到的。每个节点都形成与在那个节点的训练数据相对应的部分梯度，然后使用一个All Reduce操作来得到总梯度。

通讯瓶颈

分布式计算常常会面对一个关键的瓶颈，通常表现为很大的计算通讯带宽比。比如，计算速度是通讯速度的10-50倍都是很常见的现象。

用Tcomm和Tcomp分别表示每次迭代通讯和计算所用的时间。那么，一个迭代的机器学习(ML)算法的总时间就可以被写成

Toverall=(Tcomm+Tcomp)*迭代次数

Tcomp通常随着节点数的增加而现行减少而Tcomm增加或是保持不变(在All Reduce算法的最好情况下)。有关大数据的机器学习(ML)解决方案通常都含有大量的权重参数(d)，这些参数在每次迭代中都必须在一个集群的计算节点之间更新和通讯。更严重的是，在SQM中有一些其他的需要消耗O(d)(与d渐进相等，

突破通讯瓶颈

我们最新的研究解决了这一重要的问题。它是基于以下的观察：考虑一种情况，Tcomm，也就是节点之间的权重参数的通讯时间，非常大。在一个像 SQM一样的标准的方法中，每次迭代每个节点的计算所用的时间并不比Tcomm少。于是我们可以问下面的问题：修改算法使得它的Tcomp被增加到和 Tcomm相近，但是同时使得算法在更少的迭代内收敛到需要的解决方案，是不是可行呢?

当然，回答这个问题并不是轻而易举的，因为他需要从根本上对算法的改变。

更多细枝末节

考虑一个学习线性模型的机器学习(ML)问题。在我们的算法中，权重是不断更新的而且节点中的梯度是用一种和基于SQM的算法相似的方法共享的。然而，在每个节点，梯度(使用All Reduce计算)和节点的本地数据都通过一种并不轻而易举的方式形成了对整个问题的本地估测。每个节点都去解决它估测的问题，得到权重变量的本地更新。然后所有节点的本地更新会被结合到一起来形成一个权重变量的整体更新。注意到解决估测问题会导致每个节点的计算量上升，但是并不需要额外的通讯。结果就是 Tcomp会增加，而由于Tcomm已经很高，每次迭代的花销并不受很大影响。然而，因为每个节点都在解决估测的整个问题，需要的迭代次数将会显著下降。考虑一种情况，数据量非常大以至于每个节点获得的数据本身就已经足够做很好的工作了。在这种情况下，每个节点的估测问题就会和整个问题很接近;结果就是，我们的算法只需要一两次迭代，而基于SQM的算法则需要几百次甚至上千次的迭代。此外，我们店方法更加灵活，允许某种程度的估测而不是要求精确。总体上，我们的算法几乎总是比SQM更快，而且平均来看，要快2到3倍。

有人可能会设想把权重向量分配到许多个集群中的节点，设置分散数据的存储和计算，使得任何一个权重变量的更新只发生在一个集群节点。这在某些情况下会显得非常有吸引力，比如当一个人对把线性机器学习(ML)问题中无关的权重变量归零或分布式深度网络学习感兴趣时。又一次地，我们开发了专门的迭代算法，可以在每个节点都增加运算而减少迭代次数。

评估

我们在上文重点讨论了适合重度通讯的情况的算法。但是不是所有在实践中解决的问题都是这样。对于一般的情况，在最近的学术文献中有许多分布式机器学习(ML)算法。但是一个谨慎的对于这些算法的评估并没有人做过。最好的算法正在进入云端机器学习(ML)图书馆。

自动化的适合满足使用者需求的分布式机器学习(ML)

这个故事也有一些其他的重要的侧面。云端的分布式机器学习(ML)的使用者可能有各种各样的需求。他们可能关心把总的解决时间最小化，或者解决方案的金钱花销。使用者可能愿意牺牲一点精确性但是优化上面提到的变量。或者，他们可能热心于获得最精确的结果，而不太关心时间和开销。给定一种对问题的描述、一族不同的像这样的使用者的要求以及可用的系统配置的细节，拥有一种自动的选择正确算法和相关参数设置的过程非常重要。我们现在的研究就重点关注这一方面。

随着将来我们不断升级和扩展我们的产品，自动化分布式机器学习(ML)解决方案将是Azure机器学习(ML)的一个重要的方面和关注点。