分布式是机器学习的未来！

2018 年 11 月 3 日 AI前线

作者｜George Anadiotis

译者｜盖磊

编辑｜Debra

AI 前线导读：本文是 ZDNet 在今年的 Spark 和人工智能欧洲峰会期间对 Matei Zaharia 的专访，他是 Spark 的商业支持公司 Databricks 的 CTO 。采访中，Zaharia 介绍了公司的整合分析目标，以及 Spark 和 MLFlow 框架的用例、编程语言、采纳模式，提出分布式是机器学习的未来发展方向。

更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）

今年十月真可以称得上是机器学习的一场盛宴。上周，多个机器学习相关的大事同时推出，包括 Facebook 发布 PyTorch 1.0 beta 版、 fast.ai 推出 fastai 1.0 版、Neuton 框架推出、微软开源 Infer.NET 框架以及 MLFlow 推出 0.7.0 版。

此次 MLFLow 发布绝非偶然。上周，Apache Spark 峰会的欧洲版“Spark 和人工智能欧洲峰会”召开。从名称上看，这次峰会首次扩展添加了“人工智能”。大会吸引了大量来自机器学习社区的关注。显然，会上也预计要发布机器学习方面的声明。

Databricks 是为 Apache Spark 提供商业支持的公司，MLFlow 是该企业推出的自有产品。正如与会者所期待的，Databricks 的 CTO Matei Zaharia 在主题演讲中宣布了 MLFlow 的新版本。ZDNet 择机采访了 Zaharia，采访内容涉及多个方面，从采纳模式、用例到竞争，以及从编程语言到机器学习的未来发展。

整合分析

图一Databricks 公司的 CTO Matei Zaharia

Databricks 公司的座右铭是“整合分析”。正如 Databricks 的 CEO Ali Ghodsi 在主题演讲中所指出的，公司的目标在于整合数据、工程和人力，打破技术和组织上的孤立。这提出了一个很宽泛的愿景，而 Databricks 并非首家投身于这一愿景的公司。

从技术方面看，挑战主要在于如何将数据工程和数据科学整合在一起。正如 Zaharia 指出的，所有人其实都是由数据工程着手的：

在大约 80% 的用例中，数据科学或机器学习是最终目标。但要实现此，需要具有能持续可靠采集数据的流水线。

数据工程和数据科学同等重要，但是在科学之外的工作都需要由数据工程完成。我们针对的是使用大量数据的用户，这更具挑战性。如果用户考虑使用 Spark 实现分布式处理，那么这意味着用户已具有大量的数据。

很多情况下，Spark 也适用于用户数据是多来源的情况。Spark 以及 Databricks 的私有云平台 Delta 已支持对多个数据源的读写功能。使用 Spark 实现可处理多数据源的节点，这是用户业务取得成功的关键。

图二推出 MLFlow 的动机（图片由 Databricks 的 Mani Parkhe 和 Tomas Nykodym 提供）

现在，Databricks 更进一步推出了 MLFlow（https://mlflow.org/）。MLFlow 意在将不同的机器学习框架由实验室整合应用到生产环境中，并通过 Hydrogen 项目（https://databricks.com/session/databricks-keynote-2）构建一种数据和处理的通用框架。

MLFlow 的目标在于帮助跟踪实验结果、实现项目的分享和重用，并推动模型应用于生产环境。MLFlow 可以视为一种数据科学记事本的组合，其中添加了从 Git 等代码版本管理系统中发现历史等特性，并使用了 Maven 和 Gradle 等提供的依赖管理和部署特性。MLFlow 最早是在去年六月发布的，目前已有约 50 位来自不同机构的贡献者，他们已在生产环境中使用了 MLFLow。据 Zaharia 介绍，这些贡献者正在很好地推进 MLFlow，当前的目标是大量获取反馈并改进 MLFlow，直至一个令人满意的程度。

MLFlow 不仅可用于在 Spark 和 Delta 上部署机器学习模型，它还支持将模型导出为 REST 服务，进而运行在任何平台上，或是通过 Docker 容器化后运行在 Kubernetes 上。MLFlow 还支持云环境，当前已得到 AWS SageMaker 和 Azure ML 的支持，并可使用上述平台提供的 A/B 测试等高级功能。

Zaharia 指出，MLFlow 的目标之一是确保模型可打包到应用中（例如，移动应用）。他补充说其中具有多种不同的实现方式，例如导出模型为 Java 类文件，但这些方式都不能称为标准方式，这正是 MLFlow 意图去解决的一个问题。

分布式是机器学习的未来

熟悉机器学习模型部署的用户，一定知道 PMML 和 PFA，它们是当前部署机器学习模型的打包标准。在此我们探讨这两者，目的是为了引出 Databricks 正致力于实现的一个项目：Hydrogen 项目。

Hydrogen 项目的目标在于整合 Apache Spark 中使用的最先进人工智能和大数据技术。在实践中，这意味着该项目要实现数据和执行的整合，提供一种在不同机器学习框架间交换数据的方式，并实现训练和推理过程的标准化。

从数据方面看，Hydrogen 项目基于 Apache Arrow 构建。Apache Arrow 致力于实现大数据的内存中表示，最大化性能和互操作性。据 Zaharia 介绍，Hydrogen 项目已经支持部分数据类型，并可以通过扩展支持更多的数据类型。“我们可以做得更好”。

从执行方面看，为什么不考虑重用 PMML/PFA？Zaharia 将该问题简单归结为分布式训练的需求。他指出，PMML/PFA 是针对模型打包和部署的，与模型存在一定程度上的集成，二者均具有一些局限性。他补充说，事实上还没有真正解决问题的模型序列化标准格式：

“ONNX 是一种新提出的生态系统，也有人考虑了 TensorFlow 图。但是二者均不能覆盖所有的模型。TensorFlow 图并未覆盖随机森林等模型，而 PMML 并未很好地覆盖深度学习。”

“我们将 MLFlow 视为一种更基本的接口，类似于‘我的模型提供一种需要安装软件库的功能’。由此，我们无需关注模型是如何选取存储字节位的，而是关注我们需要安装什么。我们可以通过 MPI 等方式支持分布式训练。MPI 是在构建高性能计算（HPC）中广为使用的一种非常标准的方式，业已存在二十多年，并且工作得非常好！”

作为本文的作者，我们可以证实 Zaharia 的上述说法，因为我们在二十年前就使用 MPI 做 HPC 研究。Zaharia 继续补充说，在一切可能的情况下，他们首选考虑重用来自社区的已有贡献。例如使用 Horovod，一个由 Uber 构建的分布式机器学习开源框架。

在 Zaharia 看来，Horovod 是一种使用 MPI 实现分布式深度学习更高效通信的方式，适用于 TensorFlow 和 PyTorch。“要使用它，你需要运行 MPI 任务并提供数据，而且需要考虑好如何分区数据”。

PyTorch 项目的牵头人 Soumith Chintala 似乎也非常认同 Zaharia 的理念，即分布式训练是深度学习的下一个重要关注点。他已在最新版本的 PyTorch 中引入了这一理念。想要了解最新进展的 ZDNet 读者，可以观看 Spark 和人工智能峰会上来自 Logical Clocks AB 的 Jim Dowling 演讲介绍如何使用 Apache Spark 和 TensorFlwo 实现分布式深度学习（https://databricks.com/session/distributed-deep-learning-with-apache-spark-and-tensorflow）。

编程语言、事务和采纳

Zaharia 曾提及将机器学习模型导出为 Java 类文件。借此机会，ZDNet 与 Zaharia 探讨了对编程语言的支持和 Spark 采纳的模式。总而言之，Zaharia 的观察符合社区的普遍看法：

“我认为大家可能过多地看到 Python、R 和 Java 在数据科学和机器学习项目中的使用，对此尽可随意选择。”

“在 MLFlow 中，我们在一开始只采用了 Python，随后加入了 Java、Scala 和 R，使用的编程语言是根据用例的不同而有所变化。这就是为什么我们尽量支持尽可能多编程语言的原因。我们通常趋向于使用 Python，尤其是对于一些新的机器学习项目。但是 R 在很多领域中提供了非常好的软件库，因此得到了人们的广泛使用。在其它一些领域中，尤其是在大规模部署中，人们通常使用 Java 和 Scala。”

这次采访也是与 Zaharia 探讨 Apache Beam 的一个很好机会。Beam 是一个意在通过平台可感知 API 抽象化流处理的项目，因此 Beam 是可移植的。Beam 近期添加了支持除原生 Java 以外其它编程语言的机制，Spark 的主要竞争对手Apache Flink 正是使用该机制添加了对 Python 的支持。

在 ZDNet 上次对 Databricks 公司的采访中，他们对贡献 Beam 的支持资源并不感兴趣。所以，我们在想，近期 Beam 添加了对更多语言的支持是否有可能改进现状。很可惜，情况似乎并无任何变化。

尽管存在第三方提供的 Beam 集成，但 Zaharia 依然坚称，直接使用由 Spark 结构化的数据流仍然是在 Spark 上实现流处理的最好方式。他并不认可通过 Beam 实现多语言支持的方式。

但是他补充道，不同于 Spark 对其它语言的支持是后期补充的，MLFlow 提供了 REST 支持，这使得人们如果愿意，就可以使用 Julia 等构建软件包。

图三机器学习的下一步发展是分布式，因为分布式可以很好地加速机器学习。但分布式是难以实现的，其在机器学习中的应用依然处于早期阶段。

Zaharia 还提及了在 Apache Flink 中引入 ACID 特性，以及这对 Spark 意味着什么，尤其是考虑到 Artisans 数据上还存在未决的专利问题。Zaharia 对哪些是可以申请专利的感到十分困惑。他举例说，在本世纪早期就已提出如何使用 PostgreSQL 支持流处理，这也是 Spark Steaming 自首次发布以来一直支持的语义：

“Spark 曾经提出过事务，Delta 也使用 Hive 和 HDFS 等多种系统支持事务。一些特定的发行版本模式或存储格式可能已被专利覆盖。但是事务在任何情况下都是至关重要的，尤其是在生产环境下。”

Zaharia 指出，Databricks 的纯云（cloud-only）策略运作良好。在一些情况下，Spark 用户会选择迁移到 Databricks 的云平台。在另一些情况下，由业务线的要求决定采用云优先（Cloud-first）的方法。无论哪种情况，看上去 Spark 似乎已在相对较短的时间内建立了足够强大的立足点。随着 Spark 的不断创新，Databricks 在实现愿景上没有任何放缓的迹象。

查看英文原文：

https://www.zdnet.com/article/apache-spark-sets-out-to-standardize-distributed-machine-learning-training-execution-and-deployment/