当我们讨论机器学习平台，我们实际上在讨论什么(上)

发布时间：2019-06-01 22:31:07 来源：自考网

概论

近年来飞速发展的机器学习，尤其以深度学习为代表，已发展成算力、数据、算法交相辉映的好看风景。如果要给由机器学习带来的算力技术找一个近似的比较物，那应该是高性能计算(HPC)，两者都需要处理海量的计算和数据，机器学习也继承了HPC多年来积累的多项技术。

然而，传统的HPC只是少部分科研人员和研究机构才参与的，而机器学习搭上了AI普惠时代班车，迅速席卷了几乎所有公司和工程领域。所以，机器学习的工具箱越来越丰富，很快就超过了HPC的发展，例如：

Nvidia的CUDA将GPU引入通用计算领域

传统的Python数据分析开始出现Numpy/Pandas/Scikit-Learn

Caffe/Theno/Torch等深度学习框架的出现

Tensorflow/Pytorch等设计更现代更成熟的框架

分布式训练的多项技术，Keras/Digits等更上层的框架

CuML/Rapids等原生支持GPU的各层级的机器学习加速库...

关于机器学习的抽象脚步不止于此，这两年基于云服务的机器学习平台和框架如雨后春笋一样出现，提供使用者更加简便易用的体验。云和机器学习相结合有着很大的想象空间，因为机器学习往往需要巨大和昂贵的算力、海量的数据存储、极高的分布式通信性能要求等，而云服务的规模效应能够较大降低满足这些需求的成本，用户解脱出来专注于算法和业务的开发。此外，机器学习平台可以提供更全周期的服务，例如海量数据存储、ELK、数据增广、模型训练、模型发布、模型评估、算力扩容等等功能。

机器学习平台也有其自身的特殊性，例如分布式训练对节点间通信性能要求极高，CPU\GPU密集性的计算，海量的数据存储，极高的IO会对数据缓存策略有要求等。当然，按照我们的经验，还有传统用户对上云后的使用习惯的缺乏，所以也要提供非常好用的用户交互方式。

本文会重点介绍机器学习平台最常见的架构：IBM的FfDL。此外，带着机器学习平台设计常见的难点问题，审视国内外几个较为优秀的机器学习平台的功能和设计，包括华为云的ModelArts，Floydhub，Kubeflow（限于文章篇幅，Kubeflow将在下篇详细讲述）和我们帆一尚行的自研机器学习平台iGear。对这些机器学习平台的介绍重点会放在平台的架构方案、功能、通信和存储等问题。当然，对于 ModelArts和Floydhub等商业产品，我们没有太多渠道一窥其详细的架构设计，更多侧重在功能性上。

机器学习平台架构应该长什么样

目前主要有两大类的机器学习平台架构可以分为两大方向：基于Kubernetes与Docker，容器粒度的任务分配和组合，典型的如Kubeflow；基于成熟的大数据处理设施和资源调度(如Yarn)设施的机器学习平台，典型的如Hadoop的Submarine项目。两种方案也有着各自突出的地方，比如Kubernetes可以提供成熟稳健的GPU容器分配和调度，而基于大数据分析的架构则更方便进行数据的存储和处理。但不同架构之间的界限也不是泾渭分明的，例如有TensorflowOnSpark、Yarn调度GPU容器等项目。

在IBM[1,2]这两篇介绍DLAAS(DeepLearning-As-a-Service)的文章中，将深度学习平台的设计难点总结为以下几个方面：

容错恢复能力：平台需要具备一定的容错恢复能力。在实际使用中，硬件软件层和任务调度层等，都可能出现错误，那么在出错情况下有条件的恢复训练就非常重要

算力的弹性扩展：平台要能够提供横向的算力扩展，甚至能够默认使用无限的虚拟资源的能力。比如可以让任务使用任意多GPU的能力

可观察性：机器学习平台应该有相应的API能够让用户获取任务的状态和监控

安全性：应该有足够安全的多用户多租户资源隔离手段

分布式训练能力：平台需要有稳健的、足够加速比的分布式训练技术，这就对节点间通信等提出巨大挑战

在文章 [1] 中，IBM给出了他们为解决以上技术难点而采用的技术架构，这个架构和产品IBM将其命名为(FfDL)，具体的架构如下图所示：

在IBM给出的设计中，基本围绕Kubernetes和Docker的技术路线。我个人觉得这是一个比较务实和周全的设计，尤其是在用户交互上提供非常丰富的选择：包括Web化的方式，CLI命令行工具和编程SDK。此外，值得重点指出的是，Lifecycle Manager(LCM) -- 它是管理训练任务生命周期的服务，负责从创建到销毁的每个过程。在每次启动训练任务时(包括分布式训练任务)，LCM会在任务之外额外增加一个监听Pod(Job Monitor Pod)，这个Pod只负责监听该任务的状态，并解析包括训练日志在内的重要的训练状态，并将状态写入Etcd，而LCM通过查看Etcd的状态从而决定对这个任务的生命周期管理操作。另外值得注意的是，这个架构包含两个分布式存储，对象存储和基于SSD的Nfs服务，对象存储存放大部分冷数据，而Nfs作为一个热数据的缓存介质，以PVC的方式集成到K8s的Pod中。我们开发的机器学习平台也采用了这样的存储架构。关于FfDL详细的设计说明可以参考这两篇文章[1,2]。

带着对机器学习平台的一般性设计和难点的初步认知，来审视一下目前主流的和较出色的机器学习平台。

华为云的ModelArts

ModelArts是华为云EI的拳头产品之一，它定位为一个全场景全流程的AI开发平台。华为云的资深布道师陈亮最近有一篇关于ModelArts的很详细的介绍文章。ModelArts最大的特点就是全面和均衡，它包含了非常全面的功能，从下图可以看出：

可以看到包含了从数据处理到模型部署的各个主要环节。另外，提供的“市场”包括模型市场、应用市场和数据市场，这是较有前瞻性的做法，当然也是非常公有云的玩法。当业务积累到一定程度，用户间的资源共享是一个顺理成章的需求，用户可以将自己投入资源训练出来的模型或者数据卖给其他的用户，这样整体上能够节约大量的成本。

ModelArts也是基于Kubernetes的调度去实现任务的调度，据我所知华为云也对Kubernetes本身做了一些定制，此外，华为自研的AI芯片在业界已经不是什么秘密，那么ModelArts想必也会率先支持云端自研AI芯片，这是比较令人期待的。基于ModelArts的核心服务，上层可以构建通用的AI应用和行业解决方案。

回到机器学习训练平台本身，ModelArts用户交互形式也是比较全面的：支持Web UI的方式去使用平台功能，交互界面是使用Jupyter；此外也支持Python SDK的方式去做业务的集成；同时也有完备的Rest Api暴露给用户调用。存储上ModelArts也是使用的华为云的对象存储OBS。我们在外部不太能够看到平台细节上的具体设计，但是提供的自动学习等产品对平台的容错性和可观察性的要求很高。此外，ModelArts还拥有EYWA图计算引擎，提供全流程可视化管理，这在用户体验上会是比较大的加分。

另外值得介绍的是ModelArts在分布式训练的性能表现上显得比较有竞争力，根据斯坦福大学发布的DAWNBenchmark的最新成绩，在图像识别的总训练时间上，ModelArts排名第一，加速比能够达到0.8以上。

（图片来源：dawn.cs.stanford.edu）

当然， 2018年11才开始正式公测的 ModelArts还有很长的路要走，平台的特性又如此之多，要做好这样一个降低用户使用门开的机器学习平台的难度是极大的。在这个全世界人民都为华为捏一把汗的时间节点，我无比坚信华为人可以挺过去这段艰难的日子，也坚信华为人将打造一个完美的ModelArts。

Floydhub

（图片来源：floydhub.com）

Floydhub是一个在国外广受欢迎的机器学习平台，并且提供云端的GPU容器(主要是K80卡)。它受欢迎的最大原因就是简单而又有完备的核心功能。它的核心概念非常简约：

Projects：一个Project就是一组Workspace和Job的集合，是指你需要完成某个特定目标的总集合，用来跟踪这个目标和目标下的所以Workspace和Job

Workspace：通俗来说就是一个核心为Jupyter-Lab的交互式环境，这个环节可以理解为一个data-oriented IDE，说它是data-oriented，是因为在Jupyter-Lab之外，很好的集成了各种数据集的挂载和卸载

Jobs：Job可以理解成将数据集和代码以及执行环境绑定到一起的一个完整的训练任务，Job通常通过在本地运行Floyd CLI工具进行和云端的交互并执行

Datasets：用户上传的数据集，提供版本管理，并且可以挂载进任何任务

Environment：指代码执行的环境，包括软件包，OS，Cuda/Cudnn等等所有能让任务执行的环境

Output：是指所有从Job中输出的、需要保留的所有数据和文件，包括日志、模型参数等等

FloydHub在使用上会通过CLI工具和Web端相配合的方式，非常灵活，而且编辑代码既可以在本地进行也可以在云端进行，用户的体验会比较好。并且功能完备的CLI工具可以发布训练任务，追踪执行状态，控制任务的启停。这种体验能够让用户觉得云端资源只是本地的一个硬件资源拓展。下面以一个简单的官方Demo来展示下在FloydHub上进行训练的一般流程：

访问：https://www.floydhub.com/projects/create，并创建一个Project，比如命名为 mnist-cnn

在自己本地创建一个代码工程，为了方便起见，可以使用FloydHub的官方示例工程

$git clone https://github.com/floydhub/quick-start.git $ cd quick-start $ ls eval.pyLICENSEmnist_cnn.ipynbREADME.mdtrain_and_eval.pytrain.py

在该代码目录下，使用floyd CLI工具关联之前创建的"mnist-cnn"的Project和当前代码目录。经过这样的关联，CLI工具后续可以执行该代码目录下的代码

$floydinitmnist-cnn

执行该目录下的代码，并可以制定相应的环境，如GPU卡的使用，数据集的关联，运行代码的启动命令等等：

$ floyd run --gpu --env tensorflow-1.3 "python train_and_eval.py" Creating project run. Total upload size: 25.4KiB Syncing code ... [ = ===============================] 27316/27316 - 00:00:00 JOB NAME ---------------------- mckay/projects/mnist-cnn/1 To view logs enter: floydlogsmckay/projects/mnist-cnn/1

这里的过程实际上是将本地的代码目录通过CLI上传到FloydHub，按照传入的参数配置启动相应的容器，并将上传的代码环境挂载到容器中，并执行相应的启动脚本。

可以实时查看训练任务的状态：

$ floyd logs -f 2017-09-27 14:14:40,364 INFO - Starting attempt 1 at 2017-09-27 14:14:40.358414 2017-09-27 14:14:40,399 INFO - Downloading and setting up data sources 2017-09-27 14:14:40,534 INFO - Pulling Docker image: floydhub/tensorflow:1.3.0-py3_aws.12 2017-09-27 14:14:41,977 INFO - Starting container... 2017-09-27 14:14:42,489 INFO - # ############################################################################### 2017-09-27 14:14:42,489 INFO - Run Output: ...

FloydHub还有一个很好的特性，是将一些比较成熟的训练任务制作成了固定的模板，这样用户可以非常方便快速的基于这些模板去挂载相应的数据集或改变超惨进行叠加的训练：

（图片来源：floydhub.com）

对于FloydHub的具体架构，我们很难获悉，但是从容器里面可以看出一些蛛丝马迹，比如我们通过查看DNS的配置能看出它依然是基于Kubernetes，而它的数据集存储则是基于Ceph。当然，Floydhub也有一些问题，通过CLI工具或Web端上传很难支持较大的数据集，这会影响真正工业级别的训练任务。FloydHub完全可以去支持公有云的存储，比如AWS的S3。当然前提是FloydHub本身如果是部署在AWS上会显得更有意义，否则使用公有云的存储也解决不了训练时的大带宽的要求。

总结

机器学习平台还有很多产品和形式，比如基于Kubernetes CRD的Kubeflow，基于大数据组件的Submarine等等，当然还有我司自研的机器学习平台产品，将在下一篇文章中会继续讨论。

未完待续，下周见啦。

参考文献

[1]IBM Deep Learning Service (https://arxiv.org/abs/1709.05871)

[2]Scalable Multi-Framework Multi-Tenant Lifecycle Management of Deep Learning Training Jobs

当我们讨论机器学习平台，我们实际上在讨论什么(上)

学习型海警：2017年美国海警“司令阅读清单”

自考生课外阅读什么类型的书好

自考生课外阅读什么类型的书好

今日自考，祝愿所有考生考试顺利！

自考机构招生乱象横生

自考大数据揭秘！每年的自考报考人数超过你想象