Petuum：大规模机器学习平台的变革
在大规模数据之上利用机器学习以及深度学习算法从中学习到知识，是过去十多年人工智能取得突破的最主要手段，也是系统架构师面临的重要挑战之一，许多模型和抽象先后用于这一任务，包括早期的MPI，后来的Hadoop，乃至于当前使用较多的Spark。目前，人工智能已经进入爆发的前夜，能否有效从数据中发现知识，是成功利用人工智能技术提高生产力的关键所在。
然而，随着数据规模的增加，以及机器学习模型的复杂化，从数据中获取知识的成本不断攀升。大规模的数据，总是解决过拟合的最有效手段，在PB级数据屡见不鲜的今天，再加上一些复杂模型如深度学习动辄数十亿甚至千亿级的模型参数，这些挑战都需要在更多的机器上有效地并行处理。因此，有效的大规模机器学习框架，是应对未来的刚性需求。Petuum就是这样一个平台，名字取自一首名为 “无穷动”（Moto Perpetumm ）的意大利帕格尼尼小提琴名曲，由卡内基梅隆大学邢波教授主导的机器学习研究小组于2013年底开源，到2015年7月先后发布了5个版本，并仍然在持续进化之中。这首以快著称的小提琴曲，共3005个音符，演奏者手指起落平均每秒达16次之多，曲子优美而紧凑，表达了Petuum的设计思想。那么相比之前，以及同期的其他大规模机器学习平台，Petuum有哪些特色呢？用一句话概括，Petuum设计的所有目标，都是为了更加有效地并行处理。
在分布式机器学习的技术演进中，每年都不断有新的论文和抽象涌现出来，这当中最为人所知的，就是以MapReduce为代表的Hadoop和Spark生态系统，然而，它们并不能很好地适应分布式机器学习。举例来说，Spark上最新的SparkNet训练深度学习时，增加相应的机器并不能使训练速度获得近乎线性的提升，如下图所示的单机版（Caffe）和多节点集群之间的对比：
另一个重要的工作来自于GraphLab，尽管把机器学习模型抽象为图可以解决很多问题，但同时又引入了一些新的问题，比如如何切分机器学习程序，计算调度等，另一方面，机器学习任务抽象成图并不是很直接，比如深度学习中的多层结构，把已有的算法移植到基于图的抽象上需要不少工作，而且基于图的抽象有时还会导致程序不正确，或者陷入次优化。
因此，机器学习问题，有其特殊的考虑，拿传统的用于数据分析的框架比如MapReduce/RDD来进行分布式机器学习地开发，会有削足适履之嫌。那么，什么样的抽象才是适合大规模机器学习的呢？我们需要从机器学习算法的本质来看待问题。
绝大多数机器学习算法都可以归结为类似下面的最优化问题：
落实到具体实现就是以迭代—收敛为中心的循环：
因此，如何高效地计算∆梯度，就是机器学习算法扩展的关键所在。这种特性跟传统用于分布式计算的MapReduce抽象有着很大不同：
以一个传统的MapReduce程序---排序为例，从Mapper到Reducer整体都是Single Pass，而不是迭代式执行的，更重要的是，每个排序步骤是确定性的，例如，如果某个Mapper输出错误键值对，那么最后的输出结果可能就是错误的，因为数据没有被送到正确的Reducer，所以输出也就在错误的位置，这种错误是会一直传播而不会得到任何修正的。
因此在实际工程实现中，Hadoop/Spark都做出了额外的复杂努力，来提供容错，比如基于磁盘的快照，并且跟任务调度结合起来，这里边的工程设计十分复杂。
而对于机器学习程序来说，中间结果的错误是可以容忍的，有多条路径都可以收敛到最优，因此少量的错误可类似于随机噪声，但不影响最终的收敛结果。
机器学习算法的这种特性能够很大的影响分布式框架的设计—系统并不需要完美地确保所有任务无误运行，也无须确保机器之间通信正确，乃至从错误中恢复。当资源有限时(比如机器之间带宽有限)，简易容错设计能够让系统更简单和高效。这是大规模机器学习问题跟传统分布式问题的第一点重要区别。
另一方面，机器学习算法却比传统的MapReduce程序拥有更加复杂的结构依赖，就是说机器学习模型中的参数通常不是独立的，因此，不正确地并行执行可能会导致最终结果的不正确。针对这种特性的一个直观考虑是，将模型参数分组，使得不同组之间的参数独立，这样不同分组的模型能够并行运行，而组内模型参数则仍然按照顺序化方式处理避免出现错误。协方差矩阵是发现模型参数依赖关系的手段之一，下图的理想Lasso回归并行执行方案中，模型参数通过协方差矩阵成为若干分组，就是红色方块内部，这些分组模型被送到不同的节点执行，从而做到了最大化并行且保证正确结果。
除此之外，机器学习算法还有一个特性是参数收敛速度的不均匀性。MapReduce排序把数据分发到不同节点执行，各节点的任务和负载基本上是均衡的，然而对于机器学习问题来说，数十亿，甚至更多的参数能够以不同的迭代数目收敛，有的2-3轮迭代即可，有的则需要上百次。例如一个超过千亿参数的稀疏回归模型，85%的参数能够在5轮迭代就收敛，而其余15%的参数则需要100次迭代才可以收敛。因此，机器学习平台需要优先分配计算资源给收敛慢的参数。
因此为了能够让机器学习程序高效执行，需要做三件事情：
1 决定如何更好的切分成多个任务。
2 决定如何调度子任务。
3 均衡各节点的负载。
而这就是Petuum机器学习平台从一开始设计就考虑的要素。具体来说，Petuum平台由Bösen和Strads两个子系统构成。Bösen是一个参数服务器的实现，参数服务器是近年来新出现的专门用于机器学习算法的数据并行抽象。它通过采用一个分布式的Key-Value存储模型存放参数，这样就提供了有效的机制用于在分布式系统不同的Worker节点之间同步模型参数，而每个Worker只需要保存它计算时所依赖的一小部分参数即可。为避免以Key-Value为单元进行频繁的参数数据交互会导致过高的通信开销，参数服务器通常采用数学封装来进行参数同步，比如向量，张量，矩阵的行列等。
Bösen为参数服务器添加了被称作SSP（Staleness Synchronous Parallel）的延迟同步并行模型，其目的是在理论保证正确的前提下，利用机器学习算法的自我修复能力尽可能提升迭代吞吐量，基本思想是允许各机器以不同步调对模型进行更新，但是加一个限制，使得最快的机器的进度和最慢机器的进度之差不要太大。这样做的好处是：既减轻慢的节点拖整个系统的后腿，又能保证模型的最终收敛。这样延迟异步的控制方式避免了传统基于BSP的分布式计算的等待时间。
Strads的目的是跟Bösen搭配，提供结构可知的并行调度。在Strads系统中，模型会进行依赖关系分析，从而确定可以并行执行的参数分组单元。在调度时，Strads会优先分配计算资源给收敛速度相对较慢的参数分组。如果说Bösen是控制数据并行的最优设计，那么Strads则通过调度整合模型并行和数据并行，从而达到机器学习算法的最佳并行。通过这些并行手段，Petuum可以避免传统分布式平台因为无效同步导致的低吞吐量（并行保证），或者因为过度并行导致每次迭代的质量降低从而引发更多迭代才能收敛（正确性保证）。
Petuum将Bösen和Strads搭配使用，还有一些其他实现上的关键特性，例如通过优先级通信机制和通信拓扑结构，优化网络带宽的使用；以及自动调整迭代步长提高收敛速度等。
在Petuum平台上运行的机器学习程序只需要实现3个接口：
1 schedule，用来确定更新的模型参数以及提供参数依赖检查。
2 push，用来让工作节点为不同参数块执行∆更新函数。
3 pull，用来执行聚合函数。
其中，push和pull就是参数服务器的原语。
目前，Petuum平台提供了包括协同过滤，稀疏逻辑回归，主题模型，矩阵分解，以及深度学习等重要的大规模机器学习算法。下图是Petuum在不同规模集群上跟同类分布式机器学习框架的比较：
左边是大规模主题模型LDA的对比。众所周知大规模LDA一直是机器学习的挑战之一，Petuum在128台老旧机器（2核＊8G内存）上能够完成上万主题的模型训练，而基于MPI模型的Yahoo_LDA则无法完成该任务，即便在小规模LDA上也比Petuum的收敛速度慢很多。如果用Spark来实现主题模型，性能差距则会高达100倍（图里尚没有列出）。事实上，Petuum是最早实现大规模主题模型的分布式机器学习平台之一（LightLDA）。
右边的图是Petuum跟Spark和GraphLab在矩阵分解上的对比，可以看到，越是大型模型，Petuum优势越明显。
下图是Petuum的深度学习子项目Poseidon在AlexNet上的分布式深度学习评测。Poseidon是Petuum利用单机版Caffe做的分布式深度学习项目，由于Petuum结构设计上的灵活性，在未来引入其余热门的深度学习框架如TensorFlow从而提供比原版更好的深度学习性能也不是什么难事。
关于正确性保证，以下是Petuum运行主题模型的结果，在不同大小的集群下，采用Petuum都能够做到保持相同数目的迭代收敛。
相比之下，采用YahooLDA系统，从25台节点的集群扩展到100台节点时，迭代的次数需要增加2倍才能收敛，如果集群数量进一步增加到1000台，迭代次数则需要增加10倍才能收敛。
不论是理论上还是实践上，Petuum都展现了在解决大规模机器学习问题上的近乎完美的资源利用，由此获得相对于其他分布式机器学习平台十倍乃至百倍的性能提升，在一些用于广告场景的对比测试中，甚至取得了相对Spark 1000倍的性能优势。这使得大规模机器学习在大多数情况下只需利用中小规模的集群既可完成，对于云计算提供商，企业大数据用户，都是非常适合的选择。
随着以Petuum为中心的机器学习生态系统建设的完善，分布式机器学习平台为大数据时代带来的深刻变革，我们将拭目以待。
本文内容来自于清华大学朱军教授在2016 DTCC中国数据库技术大会上的演讲材料，以及卡内基梅隆大学Sailing Lab的Petuum项目论文，对Petuum技术有兴趣的读者可联系[email protected] 。
转载自：数据极客公众号
关注大会官方公众号，获取更多详情！
↓↓↓