从预处理到模型发布：京东登月机器学习平台框架揭秘

京东技术开放日第20期在9月16日于国家会议中心成功举行，分享会上鲁楠、武健和范振等主讲人分享了京东登月机器学习平台的基本架构和组成部分。机器之心简要整理了登月机器学习平台的基本框架。

 

本文简要介绍了京东登月机器学习平台，登月平台的基础架构主要以Docker+Kubernetes为中心，底层基础设施包括CPU和GPU计算资源，IB、OPA高速互联网络以及多样化的文件系统，之上是机器学习框架和算法库，最上层是业务应用。管理中心包括权限管理、任务管理、流程管理、监控中心、日志中心。登月机器学习平台是十分便捷和高效的系统，用户可以通过简单的组件拖拽搭建强大的机器学习模型。

 

以下整理自京东高级工程师鲁楠在京东技术开放日对登月机器学习平台所做的解读。

 

鲁楠表示在设计登月的时候，他们从机器学习常见的五个处理步骤出发，即数据源、数据处理、数据建模、模型评估、模型发布。

数据源也就是业务方具体想使用的建模数据，通过他们的实际调研发现，当时的业务方大部分使用的是存入京东大数据集市的结构化数据，也就是存储在AI与大数据部的数据仓库中，因此数据源成为了他们对内的一个天然优势。同时，对外部而言，登月也与京东云数据打通，也支持本地数据的上传等.

在数据处理上，业务方最关心的是两个部分：即数据标注和数据预处理。在标注方面登月有自己的标注平台，可以轻松便捷地解决一些数据标注问题。其次在数据预处理上，登月不仅将常用的预处理方法进行封装，也提供了一些常用框架和引擎来供用户使用，将数据预处理方法的选择权交给业务方。

随后是数据建模，从建模方法上来说可以将建模分为两种。第一种是传统的机器学习，包括常用的支持向量机、决策树分类、XGboost等。第二种是深度学习，包括卷积神经网络、循环神经网络和深度神级网络等。在登月机器学习平台上，我们可以使用封装好的机器学习算法进行建模，并且登月允许对模型训练的超参数进行调节以最优化性能。比如在登月平台进行图像分类时，从最简单的LeNet到近来广泛使用的152层残差网络，我们可以选择不同的CNN模型，此外还能调节迭代次数、核数与内存数等

在完成数据建模之后，我们还需要对模型进行评估，登月平台参考了业界常用的模型评估方法，并将这些评估方法集成到了里面。最后完成模型发布。

上图是登月机器学习平台的核心界面。在这个界面中，左边是各种通用的算法组件库，从数据源到最后的模型评估等等都有。如机器学习和深度学习中各种分类、回归和聚类算法，数据操作中各式各样的数据处理方法。中间是一个简单的实验，该实验主要分为以下五个部分，这五个部分涵盖了日常业务生产中常用的几点。

 

• 第一个是数据源，登月的数据源和整个集团的大数据进行了有效的打通，对公司内部所有的用户来说，大部分数据无需进行数据同步，直接调用就行。对于外部用户，可以在京东云上上传自己的数据就可完成数据源的创建。
  
• 第二个是数据预处理，登月给用户提供一个灵活的方式对数据进行预处理，包括数据类型转换、缺失值删除、缺失值填充、水平拼接、数据扰乱和SQL操作等。
  
• 第三个是特征工程，包括数据拆分、清洗，PCA，随机森林，逻辑回归等。
  
• 第四个是模型的训练和预测。我们能够拖拽左侧常用的算法组件，将选定的模型与前面的特征进行有效的拓扑连接，就能进行模型的训练。右侧是模型的属性栏，我们可以在上面调整模型的各种超参数。
  
• 第五个是模型评估，也是非常方便的拖拽就可完成，这大大降低了用户的编码劳力。
  

此外，登月机器学习平台在查看日志、数据、模型以及算法运行情况等可视化方面也都提供了支持。

上图呈现了登月机器学习平台简要的技术框架，其主要分为：页面展示层、算法组件层、任务调度层、集群管理层以及硬件层。

页面展示层就是我们在上文讨论的portal页面，页面层之下是登月的算法组件层，目前登月包含70多种涵盖数据源到模型发布的各个组件。接下来的是比较重要的任务调度层，任务调度层是承接页面端指令和底层集群资源的调度层，它首先接收页面端传来的算法参数，然后对接收到的算法参数进行解析并调度到相应的执行引擎和对应的集群上。在调度层下是集群管理层，登月的集群管理层支持多个不同的集群，也支持不同的存储系统，其底层都是通过Docker来进行管理。最底层的硬件层是异构的形式，包括CPU、GPU，万兆网络和高速互联设备INFINIBAND，后者的传输速度将近100G每秒。

上图是任务调度层的任务划分。根据登月平台对“任务”的定义，我们可以将任务分为两部分，一部分是组件任务，另外一部分是实验任务。

对于组件任务来说，当用户在前端页面将组件拖拽到实验窗口并点击执行后，登月后台需要根据组件信息进行如下几方面的考量：第一，多执行引起的选择。也就是组件会通过哪一个执行引擎来进行运算。第二，多集群的选择。每个业务方在大数据里分为不同的集市，而各个集市很有可能不在一个集群里，所以这个时候登月需要辨别用户的任务到底适合在哪个集群上运行。第三是多存储系统的选择。组件执行的时候，它的输入输出数据到底适配于哪一个存储系统。第四是多网卡的选择，这一点对于业务方来说并没有一个很明显的感受，他仅能通过日志来查看算法任务是否变得更快，但对于底层来说，登月拥有多个网卡，为此，登月会对不同的业务进行网卡适配。例如Tensorflow任务，单机训练并没有必要考虑网卡的问题，但对于分布式训练，我们希望首先给它分配的是资源充足的网络，能让数据和模型进行快速的传输。最后是多资源的分配，登月在底层支持的是GPU、CPU和Memory，假如用户在界面上配置一个模型需要3个GPU或者CPU，登月的底层便需要对这些资源进行合理的调度分配。

 此外，组件任务还有端口管理、日志回传和Container通信，它们是针对具体算法业务而言的。Tensorflow虽然是比较火的深度学习框架，但其也存在问题。比如说它的端口和IP需要人为指定，它的资源管理多租户隔离没有做得很好。因此登月将Tensorflow放在集群里，需要考虑它的日志怎么回传到页面端。此外登月还要考虑在Tensorflow角色划分后，它在运行时具体是怎么通信的。这些都是登月在组件任务这块所需要考虑的。

由于实验任务是一个完整的拓扑结构任务，所以我们重点考虑的是任务的执行周期和任务出现异常之后的监控报警。

为此，我们通过以下方案来解决上述的问题。

在登月组件任务调度中分为三个具体的模块：Launcher层，引擎层和集群层。Launcher层首先接到页面端用户传来的数据、资源和环境配置，然后登月会将这些信息进行拼接，在选择适当的引擎之后，将其传入引擎层，同时启动日志服务。在引擎层，分为两个小模块，一块是原生和集群比较适配的引擎；还有一些是适配性能没有这么好的引擎，我们加入了一个转化层来对它进行更合理的优化，使它更好的适配我们的集群。通过执行引擎层之后就是集群层了，集群层可能是多个集群，这些集群任务都完全不一样，登月接收到引擎层指令之后，将执行引擎合理分配到每一个集群上，使这些执行引擎能够在各个集群上优雅的运行。

下面需要介绍登月中的集群管理，集群管理里分为三个模块：数据管理、资源管理和镜像管理。在数据管理里面，登月引用了集市和生产账号的概念，登月首先将运行具有相同任务的群体定义为集市，在集市下面我们又划分出另外一个概念，即生产账号，它可能是实验小组或者项目的一组人。登月对公司内部的权限管理的最小管理单元是生产账号。目前登月现在能够处理的数据规模达到PB级，同时这些数据都是共享的方式。在底层这些数据都是在一个大池子里面，但是对于各个生产账号来说，登月为他做了权限隔离，他们能够看到的数据只是自己的数据，无法察看其他人拥有的数据，包括他的HDFS路径或者HIVE表等。

上图是在Kubernetes集群上的数据管理，在Kubernetes数据管理中登月将权限精确到用户这一层，针对用户，每个人都会获得一个独立卷，从物理上实现了数据隔离的效果。

上图是登月在集群管理中的资源管理，当用户申请各个集市或各个资源队列的资源时，每个生产账号只能访问指定队列，每个队列只能调度它拥有标签的资源。背后是登月使用了异构队列和标签调度，先开始登月的标签调度最先在是容量调度上使用，后面将这种调度移植到公平调度里面，进而让整个公司内部的集群都能使用。

下面是登月在Kubernetes上的资源调度方式，除了采用标签调度的方式，其采用精确到用户的方式，登月为每个用户分配一个Namespace，而不同Namespace之间不仅能够做到cpu,gpu,内存的隔离，还能够做到网络隔离，实现了真正意义上的资源隔离。

登月除了提供通用的算法组件外，也支持自定义的算法组件，同时也提供自定义镜像的方式来定义算法环境。为此，在镜像管理中，业务方只需制作好自己的Dockerfile，然后就可以提交到仓库里面，登月会自动生成这些镜像，并由运维人员会对这些镜像进行二次压缩，然后分发到每个集群的物理机上。

最后是任务提交，在登月平台上，任务的提交方式有两种，一种是页面端，即直接进行拖拽就可以完成，另外一种是通过简单的命令 moonshot.py-file 启动就可以。

最后，鲁楠表示登月机器学习平台在未来将依然基于数据源到模型发布的机器学习通用五步法，并在此基础上为用户减轻或者打消掉其中的一个或多个环节来进一步提升用户的体验，减少用户的编码成本，为此登月将要做以下四部分工作：

• 第一部分，登月希望能够对更多算法进行封装，这种封装形式主要采用两种：第一种是业界常用算法的封装。第二种是通过与业务方合作的方式，在了解业务方需求的情况下对算法组件进行封装。登月的目标是希望能够解决业务方80%的需求。
  
• 第二部分，登月希望能够建造一个属于自己的特征工程。对于特征工程这个概念怎么理解呢？目前在整个京东数据仓库中已经有了各种各样的用户画像数据，但是这些数据都源于不同部门，这些用户画像数据并不是完整的或者统一的结构。因此登月希望将这些用户画像进行有效的统一，同时还希望能够将深度学习引入特征工程，从而为用户提供更丰富的特征工程数据。
  
• 第三部分是登月的优化目标。我们认为目前登月为用户提供的自定义组件编写流程的程序依然存在一些复杂，我们希望用户能直接在实验界面中进行自定义。同时，我们认为spark组件在启动时的初始化耗时对业务方来说是不必要的，未来登月也将去掉这部分的耗时。其次，登月还将关注参数服务器的优化，虽然大部分业务方仍然在使用Spark，但是我们注意到spark只能解决数据并行的问题，我们需要优化参数服务器以达到两种并行的最优结合。此外，底层算法库的优化同样需要关注，如稀疏矩阵的优化，gpu cpu最优协同效率等。最后登月还将关注深度学习里常见的模型压缩问题。
  
• 第四部分是服务智能化的概念，我们一直认为登月不仅仅只是提供资源的平台，登月平台的未来要真正走向服务智能化。登月不仅仅为用户提供简单拖拽的形式来完成实验任务，同时也应该为用户推荐一些类似的算法组件或特征库，未来用户在登月上能直接使用推荐的一些算法组件和特征数据完成自己的业务。