如何选择合适的分布式机器学习平台

本文比较了机器学习平台设计方法和使用指南，是我和 Kuo Zhang 和 Salem Alqahtani 同学合作而成。我们在 2016 年秋天写了这篇文章，并在 ICCCN'17（温哥华）提交了这篇文章。

机器学习，特别是深度学习（DL）在语音识别，图像识别和自然语言处理以及推荐/搜索引擎方面取得了成功。这些技术在自主驾驶汽车，数字卫生系统，CRM，广告，物联网等方面都有广泛的应用。随着这些资本进入进一步推动技术变革，我们已经看到许多机器学习平台。

由于训练中涉及到的巨大的数据集和模型大小，机器学习平台通常是分布式 ML 平台，通常并行运行了 10 - 100 个 worker 来训练模型。据估计，数据中心的绝大多数任务将在不久的将来成为机器学习任务。

于是我们决定从分布式系统的角度研究这些 ML 平台，分析这些平台的通信和控制瓶颈。我们还研究了这些平台的容错性和是否易于编程。

我们根据 3 种基本设计方法对分布式 ML 平台进行分类：

基本数据流
参数服务器模型
高级数据流

我们简单介绍每种方法，使用 Apache Spark 作为基本数据流方法的示例，PMLS（Petrar）作为参数服务器模型的示例，TensorFlow 和 MXNet 作为高级数据流模型的示例。我们提供性能评估的评估结果。有关更多评估结果，请参阅论文。不幸的是，作为一个来自学术界的小团队我们无法进行规模评估。

在这篇文章末尾，我将介绍分布式 ML 平台未来工作的总结和建议。如果您已经有了这些分布式 ML 平台的经验，请直接跳到最后。

Spark

在 Spark 中，计算被建模为有向无环图（DAG），其中每个顶点表示弹性分布式数据集（RDD），每个边表示RDD上的操作。 RDD 是划分为逻辑（内存中或者交换到磁盘上）分区的对象集合。

在 DAG 上，从顶点A到顶点B的边缘E意味着RDD B是在RDD A上执行操作E的结果。有两种操作：转换和动作。转换（例如，映射，过滤器，连接）对RDD执行操作并产生新的RDD。

Spark 用户将计算作为 DAG 进行建模，该 DAG 会转换并运行 RDD 上的操作。 DAG 被分阶段编译。每个阶段作为一系列并行运行的任务（每个分区的一个任务）而执行。窄依赖关系对于高效执行是有好处的，而宽依赖关系则引入瓶颈，因为它们会中断执行流水线并需要执行通信密集的操作。

通过在区分 DAG 阶段来达成 Spark 中的分布式执行。该图显示了 master 的架构。 driver 包含两个调度程序组件，DAG 调度程序和任务调度程序，还有负责任务和协调 worker。

Spark 设计用于一般数据处理，而不是专门用于机器学习。然而，在 Spark 上使用 MLlib，就可以在 Spark 上做 ML。在基本设置中，Spark 将模型参数存储在 driver 节点中，而 worker 与 driver 进行通信，以便在每次迭代后更新参数。对于大规模部署，模型参数可能和 driver 不匹配，并将作为 RDD 维护。这引入了很多开销，因为需要在每次迭代中创建新的 RDD 以保存新模型参数。更新模型需要在机器间混洗数据，这限制了Spark 的可扩展性。这是 Spark 中的基本数据流模型（DAG）不足的地方。 Spark 不支持 ML 中需要的迭代过程。

PMLS

PMLS 专为 ML 设计的。它引入了参数服务器（PS）以服务于迭代密集的 ML 训练过程。

PS（在图中的绿色框中显示）使用分布式内存键值存储来维护参数信息。它可以复制和分片：每个节点作为模型（参数空间）的分片的主节点，以及其他分片的副本。因此，PS相对于节点数量很容易扩展。

PS节点存储和更新模型参数，并响应worker的请求。 worker从其本地PS副本中请求最新的模型参数，并对分配给它们的数据集分区执行计算。

PMLS还采用了同步并行（SSP）模型，该模型放宽了在每次迭代结束时工人进行同步的批量同步平行（BSP）的限制。 SSP减少了worker的同步困难，确保最快的worker不能在最慢的worker之前进行。由于处理过程的噪声容限，该一致性模型仍然适用于ML训练。我在2016年4月的博客文章[1]中介绍过。

TensorFlow

Google 有一个基于分布式机器学习平台的参数服务器模型，名为 DistBelief。（这是我对 DistBelief 论文的评论[2]）可以看出，DistBelief 的主要问题是，它需要混写在 ML 应用程序的低级代码中。 Google 希望其任何员工能够编写 ML 代码，而不需要他们精通分布式执行 - 这与 Google 为大数据处理编写 MapReduce 框架的原因相同。

所以 TensorFlow 旨在实现这一目标。 TensorFlow 采用数据流范例，但计算图不需要 DAG 高级版本，但可以包括循环和支持可变状态。我认为 Naiad[3] 设计可能对 TensorFlow 设计有一些影响。

TensorFlow 表示使用节点和边的有向图进行计算。节点表示具有可变状态的计算。边缘表示在节点之间传递的多维数据阵列（张量tensor）。 TensorFlow 要求用户静态地声明这个符号计算图，并且利用图的分区和重写达成分布式计算。（MXNet，特别是 DyNet，可以动态声明符号计算图，这提高了编程的简单性和灵活性。）

在 tensorflow 分布式 ML 训练使用参数服务器的方法如图所示。在 TensorFlow 中使用 PS 抽象时，可以使用参数服务器和数据并行。 TensorFlow 可以做更复杂的事情，但这需要编写自定义代码并进入未知领域。

一些评估结果

对于我们的评估，我们使用了 Amazon EC2 m4.xlarge 实例。每个包含 4 个 vCPU（英特尔至强处理器E5-2676 v3）和 16GB RAM。 EBS 带宽为 750Mbps。我们使用两种常用的机器学习任务进行评估：使用多层神经网络的 2 级逻辑回归和图像分类。我只是在这里提供几张对比图，你可以查看我们的论文进行更多的实验。我们的实验有几个限制：我们使用的机器少，不能测试规模。我们也仅限于 CPU 计算，并没有用 GPU 测试。

该图显示了逻辑回归执行的速度。 Spark 仅在 PMLS 和 MXNet 之后。

该图显示了 DNN 平台的速度。与单层逻辑回归相比，Spark 的性能损失比两层神经网络更大。这是因为需要更多的迭代计算。我们将 driver 的参数保存在 Spark 中，而如果我们将参数保存在 RDD 中并且在每次迭代之后更新，情况会更糟。

该图显示了平台的 CPU 利用率。 Spark 应用程序似乎具有更高 CPU 利用率（序列化开销）。

结语和未来方向

ML / DL应用程序的并行计算并非很出色，从并发算法的角度来看略微无趣。在分布式ML平台上的参数服务器是决定性因素。

就瓶颈而言，网络仍然是分布式ML应用程序的瓶颈。与其在更先进的通用数据流平台上工作，不如提供更好的数据/模型，将数据/模型作为一等公民来处理。

但是，也可能会有一些惊喜和微妙之处。在Spark中，CPU开销正在成为瓶颈[4]。Spark中使用的编程语言（即Scala / JVM）会显着影响其性能。因此，需要更好的工具来进行分布式ML平台的监视和/或性能预测。近来已经提出了一些解决Spark数据处理应用程序问题的工具，如Ernest[5]和CherryPick[6]。

分布式系统支持ML运行时还有许多开放性问题，例如资源调度和运行时性能改进。通过对应用程序的运行时监控/分析，下一代分布式ML平台应为运行的任务提供计算，内存，网络资源的通用运行时弹性配置和调度。

最后还有编程和软件工程支持的问题。适用于ML应用程序的[分布式]编程抽象是什么？这还需要更多的分析ML应用程序的验证和验证（测试具有特别有问题输入的DNN）。

https://muratbuffalo.blogspot.com/2016/04/petuum-new-platform-for-distributed.html
https://muratbuffalo.blogspot.com/2017/01/google-distbelief-paper-large-scale.html
http://muratbuffalo.blogspot.com/2014/03/naiad-timely-dataflow-system.html
http://muratbuffalo.blogspot.com/2017/05/paper-summary-making-sense-of.html
https://spark-summit.org/east-2017/events/ernest-efficient-performance-prediction-for-advanced-analytics-on-apache-spark/
https://blog.acolyer.org/2017/05/04/cherrypick-adaptively-unearthing-the-best-cloud-configurations-for-big-data-analytics/

英文原文：http://muratbuffalo.blogspot.com/2017/07/a-comparison-of-distributed-machine.html

本文作者 Murat，由 Jesse 翻译，转载译文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。