横向对比三大分布式机器学习平台：Spark、PMLS、TensorFlow

分布式机器学习是机器学习领域的一大主要研究方向。近日纽约州立大学布法罗分校计算机科学与工程教授、Petuum Inc. 顾问 Murat Demirbas 和他的两位学生一起发表了一篇对比现有分布式机器学习平台的论文，对 Spark、PMLS 和 TensorFlow 等平台的架构和性能进行了比较和介绍。Murat Demirbas 教授在论文公布后还发表了一篇解读博客文章，机器之心对这篇文章进行了编译介绍，论文原文可访问：https://www.cse.buffalo.edu/~demirbas/publications/DistMLplat.pdf

这篇论文调查了分布式机器学习平台所用的设计方法，并提出了未来的研究方向。我与我的学生 Kuo Zhang 和 Salem Alqahtani 合作完成了这一工作。我们在 2016 年秋季完成了这篇论文，并且这篇论文还将出现在 ICCCN'17（温哥华）会议上。

机器学习（尤其是深度学习）最近已经在语音识别、图像识别、自然语言处理和推荐/搜索引擎等方面取得了变革性的成功。这些技术在自动驾驶汽车、数字医疗系统、CRM、广告、物联网等方面的应用非常有前途。当然，资本带领/推动着机器学习加速发展，我们看到近段时间以来已经诞生了很多机器学习平台。

因为训练过程涉及到巨大的数据集的模型，机器学习平台往往是分布式的，它们往往会使用并行的几十个或几百个工作器（worker）来训练模型。据估计，在不久的将来，数据中心中运行的绝大多数任务都将会是机器学习任务。

我有分布式系统的研究背景，所以我们决定从分布式系统的角度研究这些机器学习平台并分析其通信和控制局限。我们也调查了这些平台的容错能力和编程难度。

我们将这些分布式机器学习平台归类为了三大基本设计方法：

1. 基本数据流（basic dataflow）

2. 参数服务器模型（parameter-server model）

3. 先进数据流（advanced dataflow）

我们对这三种方法进行了简要介绍并举例进行了说明，其中基本数据流方法使用了 Apache Spark、参数服务器模型使用了 PMLS（Petuum）、先进数据流模型使用了 TensorFlow 和 MXNet。我们提供了几个比较性能的评估结果。论文里还有更多评估结果。不幸的是，作为学术界的一个小团队，我们无法进行大规模的评估。

在本文末尾，我给出了对分布式机器学习平台未来研究工作的总结和建议。如果你已经了解这些分布式机器学习平台，可以直接跳至末尾查看结论。

Spark

在 Spark 中，计算被建模成有向无环图（DAG：directed acyclic graph），其中每一个顶点都代表一个弹性分布式数据集（RDD：Resilient Distributed Dataset），每一条边都代表对 RDD 的一个运算。RDD 是被分到了不同逻辑分区的对象的集合，这些逻辑分区是作为 in-memory 存储和处理的，带有到磁盘的 shuffle/overflow。

在一个 DAG 中，从顶点 A 到顶点 B 的边 E 表示：RDD B 是在 RDD A 上执行运算 E 后得到的结果。运算有两种：变换（transformation）和动作（action）。变换（比如：映射、过滤、连接）是指在一个 RDD 上执行一种运算生成一个新的 RDD。

Spark 用户需要将计算建模为 DAG，从而在 RDD 上进行变换或运行动作。DAG 需要被编译为 stage。每个 stage 作为一系列并行运行的任务执行（每个分区执行一个任务）。简单狭窄的依赖关系有利于高效执行，而宽广的依赖关系会引入瓶颈，因为它们会扰乱流程，而且需要通信密集的 shuffle 运算。

Spark 中的分布式执行是通过将这种 DAG stage 分割到不同的机器上执行的。这张图清晰地显示了这种 master-worker 架构。驱动器（driver）包含了任务和两个调度器（scheduler）组件——DAG 调度器和任务调度器；并且还要将任务对应到工作器。

Spark 是为一般的数据处理设计的，并不特定于机器学习。但是使用 MLlib for Spark，也可以在 Spark 上进行机器学习。在基本的设置中，Spark 将模型参数存储在驱动器节点，工作器与驱动器通信从而在每次迭代后更新这些参数。对于大规模部署而言，这些模型参数可能并不适合驱动器，并且会作为一个 RDD 而进行维护更新。这会带来大量额外开销，因为每次迭代都需要创造一个新的 RDD 来保存更新后的模型参数。更新模型涉及到在整个机器/磁盘上重排数据，这就限制了 Spark 的扩展性。这是 Spark 的基本数据流模型（DAG）的不足之处。Spark 并不能很好地支持机器学习所需的迭代。

PMLS

PMLS 是专为机器学习设计的，没有其它杂乱的历史。它引入了参数服务器（PS： parameter-server）的抽象概念，支持密集迭代的机器学习训练过程。

其中 PS（图中绿色方框）被用作分布式的内存键值存储（distributed in-memory key-value store）。它会被复制和共享：每个节点都被用作这个模型（参数空间）一个分片的主节点以及其它分片的次要节点/副本。因此在节点数量方面，PS 可以很好地扩展。

PS 节点会存储和更新模型参数以及响应来自工作器的请求。工作器会请求来自它们的局部 PS 副本的最新模型参数，并在分配给它们的数据集部分上执行计算。

PMLS 还采用了 SSP（Stale Synchronous Parallelism）模型，这比 BSP（Bulk Synchronous Parellelism）模型更宽松——其中工作器在每次迭代结束时同步。SSP 为工作器的同步减少了麻烦，确保最快的工作器不能超过最慢的工作器 s 次迭代。宽松的一致性模型仍然可以用于机器学习训练，因为这个过程有一定的噪声容错能力，我在 2016 年 4 月的这篇文章中谈过这个问题：https://muratbuffalo.blogspot.com/2016/04/petuum-new-platform-for-distributed.html

TensorFlow

谷歌有一个基于参数服务器模型的分布式机器学习平台 DistBelief。参阅我对 DistBelief 论文的评论：https://muratbuffalo.blogspot.com/2017/01/google-distbelief-paper-large-scale.html。在我看来，DistBelief 的主要缺陷是：为了编写机器学习应用，需要操作低级代码。谷歌想要自己的所有员工无需精通分布式执行就能编写机器学习代码——基于同样的理由，谷歌为大数据处理编写了 MapReduce 框架。

所以为了实现这一目标，谷歌设计了 TensorFlow。TensorFlow 采用了数据流范式，但是是一种更高级的版本——其中计算图无需是 DAG，而且包含循环且支持可变状态。我认为 Naiad 设计可能对 TensorFlow 设计有所影响。

TensorFlow 使用节点和边的有向图来表示计算。节点表示计算，状态可变。而边则表示多维数据数组（张量），在节点之间传输。TensorFlow 需要用户静态声明这种符号计算图，并对该图使用复写和分区（rewrite & partitioning）将其分配到机器上进行分布式执行。（MXNet，尤其是 DyNet 使用了图的动态声明，这改善了编程的难度和灵活性。）

TensorFlow 中的分布式机器学习训练使用了如图所示的参数服务器方法。当你在 TensorFlow 中使用 PS 抽象时，你就用到了参数服务器和数据并行。TensorFlow 让你还能做更复杂的事情，但那需要编写自定义代码并进入全新的疆域。

一些评估结果

我们的评估使用了 Amazon EC2 m4.xlarge 实例。每个实例包含 4 个由 Intel Xeon E5-2676 v3 驱动的 vCPU 和 16 GiB RAM。EBS 带宽为 750Mbps。我们使用了两个常见的机器学习任务进行评估：二分类 logistic 回归和使用多层神经网络的图像分类。我在这里仅给出了几张图，查看我们的论文可以了解更多实验。但我们的实验还有一些局限性：我们使用了少量机器，不能大规模测试。我们也限制了 CPU 计算，没有测试 GPU。

这幅图展示了各平台的 logistic 回归执行速度。Spark 表现不错，但落后于 PMLS 和 MXNet。

这幅图展示了各平台的深度神经网络（DNN）执行速度。相比于单层的 logistic 回归，Spark 在两层神经网络上有更大的性能损失。这是因为两层网络需要更多迭代计算。在 Spark 中我们将参数保存在驱动器中，这样它们可以拟合；如果我们将参数保存在一个 RDD 中并且在每次迭代后更新，情况还会变得更加糟糕。

这幅图给出了各平台的 CPU 利用率。Spark 应用似乎有明显很高的 CPU 利用率，这主要是因为序列化（serialization）的额外开销。我们更早期的工作已经指出了这一问题：https://muratbuffalo.blogspot.com/2017/05/paper-summary-making-sense-of.html

总结与未来方向

机器学习/深度学习应用的并行处理让人为难，而且从并发算法（concurrent algorithms）的角度看并不非常有趣。可以相当肯定地说参数服务器方法在分布式机器学习平台的训练上更好。

至于局限性方面，网络仍然是分布式机器学习应用的一个瓶颈。提供更好的数据/模型分级比更先进的通用数据数据流平台更有用；应该将数据/模型看作头等公民。

但是，可能会有一些让人惊奇和微妙的地方。在 Spark 中，CPU 开销会先于网络限制变成瓶颈。Spark 使用的编程语言 Scala/JVM 显著影响了其性能表现。因此分布式机器学习平台尤其需要更好的监控和/或性能预测工具。最近已经有人提出了一些解决 Spark 数据处理应用的问题的工具，比如 Ernest 和 CherryPick。

在机器学习运行时的分布式系统支持上还有很多悬而未决的问题，比如资源调度和运行时的性能提升。对应用使用运行时监控/性能分析，下一代分布式机器学习平台应该会提供任务运行的计算、内存、网络资源的详细的运行时弹性配置/调度。

最后，在编程和软件工程支持方面也有一些待解决的问题。什么样的（分布式）编程抽象思想适用于机器学习应用？另外在分布式机器学习应用的检验和验证（尤其是使用有问题的输入来测试 DNN）上也还需要更多研究。

原文链接：http://muratbuffalo.blogspot.jp/2017/07/a-comparison-of-distributed-machine.html

本文为机器之心编译，转载请联系本公众号获得授权。

✄------------------------------------------------

加入机器之心（全职记者/实习生）：hr@jiqizhixin.com

投稿或寻求报道：editor@jiqizhixin.com

广告&商务合作：bd@jiqizhixin.com