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

横向对比三大分布式机器学习平台：Spark、PMLS、TensorFlow 2017-08-04 11:47 程序设计/谷歌/对比 选自muratbuffalo

做者：Murat Demirbas

参与：Panda

分布式机器学习是机器学习领域的一大主要研究方向。近日纽约州立大学布法罗分校计算机科学与工程教授、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

本文为机器之心编译