本论文从分布式体系的视点展开针对当时一些机器学习渠道的研讨，总述了这些渠道所运用的架构规划，对这些渠道在通讯和操控上的瓶颈、容错性和开发难度进行剖析和比照，并对分布式机器学习渠道的未来研讨作业提出了一些主张。文中的作业由 Murat Demirbas 教授与他的研讨生 Kuo Zhang 和 Salem Alqahtani 共同完结。

机器学习，特别是深度学习，已在语音辨认、图画辨认和自然打量处理以及近期在引荐及搜索引擎等范畴上取得了革命性的成功。这些技能在无人驾驶、数字医疗体系、CRM、广告、物联网等范畴具有很好的运用远景。当然，是资金***和驱动了技能的加快推动，使得咱们在近期看到了一些机器学习渠道的推出。

考虑到练习中所触及的数据集和模型的规划非常巨大，机器学习渠道通常是分布式渠道，不方便了数十个甚至数百个并行运转的核算节点对模型做练习。据估计在不远的将来，数据中心的大多数使命都会是机器学习使命。

我来自于分布式体系研讨范畴，因而咱们考虑从分布式体系的视点展开针对这些机器学习渠道的研讨，剖析这些渠道在通讯和操控上的瓶颈。咱们还考虑了这些渠道的容错性和易编程性。

咱们从规划办法大将机器学习渠道划分为三个根本类别，分别是：根本数据流、参数 - 服务器模型和高档数据流。

下面咱们将对每类办法做扼要介绍，以 Apache Spark 为例介绍根本数据流，以 PMLS(Petuum)为例介绍参数服务器模型，而高档数据流则运用 TensorFlow 和 MXNet 为例。咱们比照了上述各渠道的功能并给出了一系列的评价成果。要了解具体的评价成果，可参阅咱们的论文。惋惜的是，作为一个小型研讨团队，咱们无法展开大规划的评价。

在本篇博文的***，我给出了一些结论性关键，并对分布式机器学习渠道的未来研讨作业提出了一些主张。对这些分布式机器学习渠道已有必定了解的读者，能够直接跳到本文结束。

Spark

在 Spark 中，核算被建模为一种有向无环图(DAG)，图中的每个极点表明一个 RDD，每条边表明了 RDD 上的一个操作。RDD 由一系列被切分的方针(Partition)组成，这些被切分的方针在内存中存储并完结核算，也会在 Shuffle 进程中溢出(Overflow)到磁盘上

在 DAG 中，一条从极点 A 到 B 的有向边 E，表明了 RDD B 是在 RDD A 上履行操作 E 的成果。操作分为“转化”(Transformation)和“动作(Action)”两类。转化操作(例如 map、filter 和 join)运用于某个 RDD 上，转化操作的输出是一个新的 RDD。

Spark 用户将核算建模为 DAG，该 DAG 表明了在 RDD 上履行的转化和动作。DAG 从而被编译为多个 Stage。每个 Stage 履行为一系列并行运转的使命(Task)，每个分区(Partition)对应于一个使命。管中窥豹，有限(Narrow)的依靠联系将有利于核算的高效履行，而广泛(Wide)的依靠联系则会引进瓶颈，由于这样的依靠联系引进了通讯密布的 Shuffle 操作，这打断了操作流 。

Spark 的分布式履行是经过将 DAG Stage 划分到不同的核算节点完结的。上图明晰地展现了这种“主机(master)- 作业者(worker)”架构。驱动器(Driver)包括有两个调度器(Scheduler)组件，即 DAG 调度器和使命调度器。调度器对作业者分配使命，并和谐作业者。

Spark 是为通用数据处理而规划的，并非专用于机器学习使命。要在 Spark 上运转机器学习使命，能够运用 MLlib for Spark。假如选用根本设置的 Spark，那么模型参数存储在驱动器节点上，在每次迭代后经过作业者和驱动器间的通讯更新参数。假如是大规划不方便机器学习使命，那么驱动器或许无法存储避实就虚的模型参数，这时就需求运用 RDD 去包容避实就虚的参数。这将引进很多的额定开支，由于为了包容更新的模型参数，需求在每次迭代中创立新的 RDD。更新模型会触及在机器和磁盘间的数据 Shuffle，从而约束了 Spark 的扩展性。这正是根本数据流模型(即 DAG)的短板地点。Spark 并不能很好地支撑机器学习中的迭代运算。

PMLS

PMLS 是专门为机器学习使命而规划的。它引进了称为“参数 - 服务器”(Parameter-Server，PS)的笼统，这种笼统是为了支撑迭代密布的练习进程。

PS(在图中以绿色方框所示)以分布式 key-value 数据表方式存在于内存中，它是可仿制和分片的。每个节点(node)都是模型中某个分片的主节点(参数空间)，并作为其它分片的二级节点或仿制节点。这样 PS 在节点数量上的扩展性很好。

PS 节点存储并更新模型参数，并呼应来自于作业者的恳求。作业者从自己的本地 PS 复制上恳求***的模型参数，并在分配给它们的数据集分区上履行核算。

PMLS 也选用了 SSP(Stale Synchronous Parallelism)模型。比较于 BSP(Bulk Synchronous Parellelism)模型 ，SSP 放宽了每一次迭代结束时各个机器需做同步的要求。为完结同步，SSP 答应作业者间存在必定程度上的不同步，并保证了最快的作业者不会抢先最慢的作业者 s 轮迭代以上。由于处理进程处于差错所答应的范围内，这种非严厉的一致性模型仍然适用于机器学习。我从前宣布过一篇博文专门介绍这一机制。

TensorFlow

Google 给出了一个根据分布式机器学习渠道的参数服务器模型，称为“DistBelief”(此处是我对 DistBelief 论文的总述)。就我所知，咱们对 DistBelief 的不满意之处首要在于，它在编写机器学习运用时需求混合一些底层代码。Google 想使其任一雇员都能够在无需通晓分布式履行的情况下编写机器学习代码。正是出于同一原因，Google 对大数据处理编写了 MapReduce 结构。

TensorFlow 是一种规划用于完结这一方针的渠道。它选用了一种更高档的数据流处理范式，其间表明核算的图不再需求是 DAG，图中能够包括环，并支撑可变状况。我以为 TensorFlow 的规划在必定程度上受到了 Naiad 规划理念的影响。

TensorFlow 将核算表明为一个由节点和边组成的有向图。节点表明核算操作或可变状况(例如 Variable)，边表明节点间通讯的多维数组，这种多维数据称为“Tensor”。TensorFlow 需求用户静态地声明逻辑核算图，并经过将图重写和划分到机器上完结分布式核算。需阐明的是，MXNet，特别是 DyNet，运用了一种动态界说的图。这简化了编程，并提高了编程的灵活性。

如上图所示，在 TensorFlow 中，分布式机器学习练习运用了参数 - 服务器办法。当在 TensorFlow 中运用 PS 笼统时，就运用了参数 - 服务器和数据并行。TensorFlow 宣称能够完结更杂乱的使命，可是这需求用户编写代码以通向那些未探究的范畴。

MXNet

MXNet 是一个协同开源项目，源自于在 2015 年呈现的 CXXNet、Minverva 和 Purines 等深度学习项目。类似于 TensorFlow，MXNet 也是一种数据流体系，支撑具有可变状况的有环核算图，并支撑运用参数 - 服务器模型的练习核算。相同，MXNet 也对多个 CPU/GPU 上的数据并行供给了很好的支撑，并可完结模型并行。MXNet 支撑同步的和异步的练习核算。下图显现了 MXNet 的首要组件。其间，运转时依靠引擎剖析核算进程中的依靠联系，对不存在相互依靠联系的核当作并行处理。MXNet 在运转时依靠引擎之上供给了一个中间层，用于核算图和内存的优化。

MXNet 运用检查点机制支撑根本的容错，供给了对模型的 save 和 load 操作。save 操作将模型参数写入到检查点文件，load 操作从检查点文件中读取模型参数。

MXNet 运用描绘式编程打量表述核算为一个有向图，也支撑运用一些指令式编程去界说 tensor 的核算和操控流。MXNet 供给了多种打量(例如 C++、Python、R 和 Scala 等)编写的客户端 API。与 TensorFlow 相同，MXNet 的后台中心引擎库相同是运用 C++ 编写的。

部分评价成果

在咱们的试验中，运用了 Amazon EC2 m4.xlarge 实例。每个实例具有 4 个由 Intel Xeon E5-2676 v3 完结的 vCPU，及 16GB 的内存，EBS 带宽是 750Mbps。咱们对两种常见的机器学习使命进行了试验，它们分别是二分类逻辑斯蒂回归和运用多层神经网络的图画分类。本文中只给出了部分成果图，更多的试验成果可拜见咱们的论文。需指出的是，咱们的试验具有一些限制性。首要，咱们运用机器数量不大，不能测验扩展性。其次，咱们也只运用了 CPU 核算，并未测验 GPU 的运用情况。

该图展现了各个渠道对逻辑斯蒂回归的核算速度。PMLS 和 MXNet 是最快的两个体系，TensorFlow 速度最慢，而 Spark 介于两者之间。 对此，咱们剖析以为是由多个原因导致的。首要，比较于 Spark 和 TensorFlow，PMLS 是一个轻量级体系，它是选用高功能 C++ 编程打量完结的，而 Spark 是运用运转在 JVM 上的 Scala 打量编写的。其次，PMLS 中包括的笼统较少，而 TensorFlow 中则具有过多的笼统。笼统增加了体系的杂乱度，并导致运转时开支。

该图展现了 DNN 在各个渠道上的速度。比较于单层神经网络，当发展到两层神经网络时，由于需求更多的迭代核算，Spark 的功能下降。咱们将模型参数存储在 Spark 的驱动器中，由于驱动器能够包容这些参数。可是假如咱们运用 RDD 坚持参数，并在每次迭代后做更新，成果或许会更差。

该图展现了渠道的 CPU 占用率。Spark 运用看上去具有偏高的 CPU 占用率，这首要来自于序列化的开支。有些前期作业也指出了同一问题。

结论及未来的研讨方向

机器学习和深度学习运用是高度可并行的，可是从并发算法视点看，要做到并不那么简单。能够说，参数 - 服务器办法最合适于分布式机器学习渠道的练习使命。

考虑到瓶颈，网络仍然是分布式机器学习运用的瓶颈。比较于更高档的通用数据流渠道，更重要的是要提出对数据和模型的更好安排和参加机制。应将数据和模型视作一等公民。

此外，还有其它一些要素对渠道具有奇妙的影响。关于 Spark，CPU 开支成为比网络限制更严峻的瓶颈问题。Spark 运用的编程打量是 Scala 等 JVM 打量，这对 Spark 的功能具有明显的影响。因而存在着对更好的监控东西以及对分布式机器学习渠道功能猜测的需求。近期现已呈现了一些东西，例如 Ernest 和 CherryPick，它们处理了一些 Spark 数据处理运用上的问题。

关于支撑机器学习的运转时分布式体系，仍然存在着一些敞开问题，例如资源调度和运转时功能改善。考虑到运用的运转时监控和功能剖析，下一代的分布式机器学习渠道应供给对运转于渠道上使命的核算、内存、网络资源的运转时弹性装备和调度等才能。

在编程和软件工程的支撑上，也相同有一些敞开问题。什么是合适机器学习运用的分布式编程笼统?这些问题还需求做进一步的研讨，并对分布式机器学习运用进行查验和验证，例如运用特定问题输入测验 DNN。