导读：机器学习和深度学习是近年技术的热点，面对众多的机器学习平台如何进行选择，这是一个很困扰的问题。本文对分布式机器学习（ML）平台中使用的设计方法进行了调查，并提出了未来的研究方向。
本文比较了机器学习平台设计方法和使用指南，是我和 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 翻译，转载译文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
推荐阅读
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号
有疑问加站长微信联系（非本文作者）
