CN117632357A - 数据调度方法、系统、设备及计算机可读存储介质 - Google Patents

Abstract

本发明公开了一种数据调度方法、系统、设备及计算机可读存储介质，该数据调度方法包括：根据Volcano模块、Fluid模块和Kubernetes Operator子系统，通过CRD自定义资源的方式对Job资源进行改造；通过调度程序插件的方式，将Volcano模块的vc‑scheduler组件集成进入Kube‑scheduler子系统，通过Volcano模块、Fluid模块和Kubernetes Operator子系统对数据进行调度。本发明实现了对应用数据的数据智能感知和调度优化。

Description

数据调度方法、系统、设备及计算机可读存储介质

技术领域

本发明涉及容器调度技术领域，尤其涉及一种数据调度方法、系统、设备及计算机可读存储介质。

背景技术

基于Hadoop生态的传统大数据系统缺乏弹性能力的特性，需要按照高峰期的业务需求部署大数据系统才能满足业务需求，但是这样就会造成低峰期资源利用率低的问题。而云原生技术天然适合解决传统大数据系统面临的弹性不足、资源利用率低的问题，但是云原生本身的存算分离的特性，使得大数据上云面临着性能大大降低，如何提升大数据在云上的性能问题成为了不能不解决的问题。

目前主要从两个方面着手来提升云上性能，一个是优化网络信号，另一个是拉近数据和计算的距离。前者一般是通过提高带宽等基础设施实现，对于后者，在拉近数据和计算的距离后，如何基于应用数据进行智能调度和调度优化成为了关键，它是执行作业又快又好的关键保证，而Kubernetes本身的调度无法感知数据，更无法基于应用数据进行智能调度和调度优化。

发明内容

本发明的主要目的在于提供一种数据调度方法、系统、设备及计算机可读存储介质，旨在实现对应用数据的数据智能感知和调度优化。

为实现上述目的，本发明提供一种数据调度系统，所述数据调度系统包括Kubernetes Operator子系统和Kube-apiserver子系统，所述Operator子系统包括Kube-controller-manager子系统、Kube-scheduler子系统、Volcano模块和Fluid模块，其中，

所述Volcano模块包括Job组件、Queue组件、vc-controllers组件和vc-scheduler组件，其中，所述Job组件和所述Queue组件集成于所述Kube-apiserver子系统，所述vc-controllers组件集成于Kube-controller-manager子系统，所述vc-scheduler组件集成于所述Kube-scheduler子系统；

所述Fluid模块包括Dataset控制组件、Runtime控制组件、Volume控制组件、Fluid调度器组件、Dataset组件和Runtime模块，其中，所述Dataset组件和所述Runtime模块集成于所述Kube-apiserver子系统，所述Dataset控制组件、Runtime控制组件、Volume控制组件集成于Kube-controller-manager子系统，所述Fluid调度器组件集成于所述Kube-scheduler子系统。

可选地，所述Runtime模块包括Alluxio Runtime组件、GooseFS Runtime组件、JuiceFS Runtime组件和JindoFS Runtime组件。

可选地，所述数据调度系统还包括OSS(object Storage Service)组件、Ceph组件和HDFS(Hadoop Distributed File System)组件。

此外，为实现上述目的，本发明提供一种数据调度方法，其特征在于，所述数据调度方法应用于如上述的数据调度系统，所述数据调度系统包括Volcano模块、Fluid模块和Kubernetes Operator子系统，所述方法包括：

根据所述Volcano模块、所述Fluid模块和所述Kubernetes Operator子系统，通过CRD自定义资源的方式对Job资源进行改造；

通过调度程序插件的方式，将所述Volcano模块的vc-scheduler组件集成进入所述Kube-scheduler子系统；

通过所述Volcano模块、所述Fluid模块和所述Kubernetes Operator子系统对数据进行调度。

可选地，所述方法还包括：

在所述Fluid模块创建的所述数据集对应的运行状态为预备状态时，通过所述Fluid模块将alluxio worke节点配置对应的目标标签，其中，所述目标标签包括namespace信息和datasetname信息。

可选地，所述Volcano模块包括vc-scheduler组件，所述方法还包括：

通过所述vc-scheduler组件读取当前配置文件，得到当前配置文件的actions进程，以及每个action进程对应的plugins插件；

在创建新的会话过程中，通过所述vc-scheduler组件获取当前cluster集群里面的pod容器信息、tasks任务信息和node节点信息，并保存在缓存中，作为本轮调度的资源视图；

通过所述vc-scheduler组件依次执行当前配置文件中的actions进程，以及各所述action进程对应的plugins插件，通过各所述plugins插件选择出的最优node节点作为本次调度的结果。

可选地，所述通过各所述plugins插件选择出的最优node节点作为本次调度的结果的步骤包括：

通过各所述plugins插件分别选出一组node作为本次调度的目标节点，以及分别为各自选出的目标节点进行分数评价；

在所述分数评价完成后，对分数评价后的各所述目标节点的分数进行相交运算，以选出目标节点组；

根据各所述plugins插件对应的权重，从所述目标节点组中选择出最优node节点作为本次调度的结果。

可选地，所述Volcano模块包括vc-controllers组件，所述方法还包括：

通过所述vc-controllers组件检查所述Job组件中数据集的任务状态；

若所述任务状态为第一状态，则启动新任务进程，其中，所述新任务进程使用新的dataset数据集，所述第一状态为完成状态或者失败状态；

若所述任务状态为第二状态，则进行等待，直至任务超时或者任务完成，启动所述新任务进程，其中，所述第二状态为正在运行状态

此外，为实现上述目的，本发明还提供一种数据调度设备，数据调度设备包括存储器、处理器及存储在存储器上并可在处理器上运行的数据调度程序，数据调度程序被处理器执行时实现如上述的数据调度方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，计算机可读存储介质上存储有数据调度程序，数据调度程序被处理器执行时实现如上述的数据调度方法的步骤。

本申请通过将vc-controllers组件集成于Kube-controller-manager子系统，所述vc-scheduler组件集成于所述Kube-scheduler子系统，所述Dataset组件和所述Runtime模块集成于所述Kube-apiserver子系统，所述Dataset控制组件、Runtime控制组件、Volume控制组件集成于Kube-controller-manager子系统，所述Fluid调度器组件集成于所述Kube-scheduler子系统，从而实现基于Kubernetes Operator技术、Kubernetes scheduderFramework、Fluid和Volcano技术，设计和实现一种基于应用数据的数据感知和调度优化的调度方法，该调度方法基于Kubernetes scheduler Framework，可以作为一个调度插件与其它调度引擎如Volcano无缝集成，与Volcano相互补充，相比于仅部署Fluid，由于目前Fluid实现调度亲和性需要对namespace，kubernetes集群进行配置等，手动操作的比较多，便利性差，而本申请通过在部署Fluid(即Fluid模块)的基础上，还无缝集成了Volcano模块，通过Volcano模块和Fluid模块各自组件功能的优势互补，从而既能满足数据亲和性，又能和Volcano其他的一些调度plugin一起参与每个node的打分，通过Volcano模块来进行数据调度，不需要对namespace及kubernetes集群做额外的配置，克服了在KubernetesOperator中仅部署Fluid模块的固有缺陷，使得本申请能够提供一种基于批处理系统调度及数据感知调度联合为基础构建的调度方法，从而使得既可以通过Volcano模块为大数据的机器学习和深度学习提供gang-scheduler、fair-aware的解决方案，又能通过Fluid模块迅速拉近数据与计算的距离，有效解决大数据上云等场景中遇到的性能瓶颈问题，有效实现对应用数据的数据智能感知和调度优化。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的终端\装置结构示意图；

图2为本发明实施例数据调度系统的系统架构示意图；

图3为本发明实施例涉及改造volcano模块的框架示意图；

图4为本发明实施例中Volcano进行调度的流程示意图；

图5为本发明数据调度方法第一实施例的流程示意图。

本发明目的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明，若本发明实施例中有涉及方向性指示(诸如上、下、左、右、前、后……)，则该方向性指示仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。

另外，若本发明实施例中有涉及“第一”、“第二”等的描述，则该“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。

为了助于理解本申请实施例的技术方案，本申请先对一些技术术语进行解释：

Kubernetes：由Master和Node组成，Master负责管理容器的编排、部署、调度等。

Dataset：数据集是逻辑上相关的一组数据的集合，会被运算引擎使用。例如，大数据的Spark和AI(Artificial Intelligence，人工智能)场景的TensorFlow。而这些数据智能的应用会创造工业界的核心价值。Dataset的管理实际上也有多个维度，例如安全性、版本管理和数据加速。

Runtime：实现数据集安全性、版本管理和数据加速等能力的执行引擎，定义了一系列生命周期的接口，可以通过实现这些接口，支持数据集的管理和加速。

Alluxio：作为大数据和机器学习生态系统中的一个新的数据访问层，配置在任何持久性存储系统(如Amazon S3、Microsoft Azure对象存储、Apache HDFS或OpenStackSwift)和计算框架(如Apache Spark、Presto或Hadoop MapReduce)之间。请注意，Alluxio不是一个持久化存储系统。使用Alluxio作为数据访问层有如下好处：

1、对于用户应用程序和计算框架，Alluxio提供了快速存储，促进了作业之间的数据共享和局部性，而不管使用的是哪种计算引擎。因此，当数据位于本地时，Alluxio可以以内存速度提供数据；当数据位于Alluxio时，Alluxio可以以计算集群网络的速度提供数据。第一次访问数据时，只从存储系统上读取一次数据。为了得到更好的性能，Alluxio推荐部署在计算集群上。

2、对于存储系统，Alluxio弥补了大数据应用与传统存储系统之间的差距，扩大了可用的数据工作负载集。当同时挂载多个数据源时，Alluxio可以作为任意数量的不同数据源的统一层。

Alluxio Runtime：来源于Alluxio社区，是支撑Dataset数据管理和缓存的执行引擎实现，支持PVC，Ceph，CPFS加速，有效支持混合云场景。

JuiceFS Runtime：基于JuiceFS的分布式缓存加速引擎，支持场景化的数据缓存和加速能力。JuiceFS Runtime是基于C++实现的支撑Dataset数据管理和缓存的执行引擎，可支持OSS对象存储、OSS-HDFS以及HDFS的数据访问加速。

Fluid：Fluid不是全存储加速和管理，而是应用使用的数据集加速和管理。Fluid提供了一种更加云原生的方式对数据集进行管理，通过缓存加速引擎实现将底层存储系统的数据cache在计算节点的内存或者硬盘上，解决了计算与存储分离架构中由于数据传输带宽限制以及底层存储带宽与IOPS能力限制导致的IO效率不高等问题。Fluid提供缓存数据调度能力，缓存被纳入kubernetes扩展资源，kubernetes在进行任务的调度的时候，能够参考缓存进行调度策略的分配。Fluid有2个重要的概念：Dataset与Runtime。

其中，Dataset数据集是逻辑上相关的一组数据的集合，一致的文件特性，会被同一运算引擎使用。Runtime实现数据集安全性，版本管理和数据加速等能力的执行引擎的接口，定义了一系列生命周期的方法。Fluid的Runtime定义了标准化的接口，Cache RuntimeEngine可以对接多种缓存引擎，提供了用户更灵活的选择，用户能够针对不同的场景与需求，充分利用缓存引擎加速相应的场景应用。

JuiceFS Runtime：是Fluid自定义的一种Runtime，其中可以指定JuiceFS的worker、fuse镜像以及相应的缓存参数。其构建方式与Fluid其他Runtime一致，即通过CRD(Custom Resource Definition，自定义资源)的方式构建，JuiceFS Runtime Controller监听JuiceFS Runtime资源，实现缓存Pod的管理。JuiceFS Runtime支持数据亲和性调度(node Affinity)，选择合适的缓存节点，支持Fuse pod懒启动，支持用户以POSIX接口访问数据，目前只支持一个挂载点。

GooseFS Runtime：目前在Kuberntes中使用GooseFS加速Spark的数据访问主要有两种方式：

1、基于Fluid分布式数据编排与加速引擎(Fluid Operator架构)部署运行GooseFS Runtime Pods和Spark Runtime加速Spark计算应用。

2、在Kubernetes中运行Spark on GooseFS(Kubernetes Native部署架构)。

Dataset Controller：负责Dataset的生命周期管理，包括创建与Runtime的绑定、解绑和删除。

Runtime Controller：负责Runtime的生命周期管理，包括创建、扩缩容、缓存预热和清理的触发，以及删除等操作，这些操作实际是操作后端缓存引擎(Alluxio、juiceFS)。

Node：容器运行的载体，Node即虚拟机，每个Node上面可以运行成百上千个Pod容器。

Pod容器：Pod是Kubernetes创建或者部署的最小单位，一个Pod封装一个或者多个容器，存储资源及管理控制容器的运行方式的策略选项。

Master：缓存系统的核心组件，通常是一个pod。

Worker：组成缓存集群的组件，可以是多个pod，可以设置个数；用于缓存远端数据。

Scheduler：是Kubernetes Master的调度组件，通过预选和优选节点，将容器绑定到最优节点上。

Gang：资源成组，确保作业内的成组Pod资源不被强制驱逐。

fair-aware：目的是为了确保在多种类型资源共存的环境下，尽可能满足分配的公平原则。

Volcano-scheduler(即vc-scheduler)：vc-scheduler中的调度策略都以插件的形式存在，其不仅可以调度批量计算的作业，也可以调度微服务作业；并且可以通过multi-scheduler功能与kube-scheduler(即Kubernetes scheduler)共存。

Volcano-Controller(即vc-controllers)：Volcano通过CRD的方式提供了通用灵活的Job抽象Volcano Job(batch.volcano.sh/jobs)，Controller则负责跟Scheduler配合，管理Job的整个生命周期。主要功能包括：

(1)自定义的Job资源：跟K8s内置的Job(作业)资源相比，Volcano Job有了更多增强配置，比如：任务配置，提交重试，最小调度资源数，作业优先级，资源队列等。

(2)Job生命周期管理：Volcano Controller会监控Job的创建，创建和管理对应的子资源(Pod，ConfigMap，Service)，刷新作业的进度概要，提供CLI方便用户查看和管理作业资源等。

(3)任务执行策略：单个Job下面往往会关联多个任务(Task)，而且任务之间可能存在相互依赖关系，Volcano Controller支持配置任务策略，方便异常情况下的任务间关联性重试或终止。

(4)扩展插件：在提交作业、创建Pod等多个阶段，Controller支持配置插件用来执行自定义的环境准备和清理的工作，比如常见的MPI作业，在提交前就需要配置SSH插件，用来完成Pod资源的SSH信息配置。

接下来介绍本申请实施例进行数据调度的系统架构，请参照图2，图2为本发明实施例数据调度系统的系统架构示意图，本申请实施例提供一种数据调度系统，所述数据调度系统包括Kubernetes Operator子系统(未图示)和Kube-apiserver子系统，所述Operator子系统包括Kube-controller-manager子系统、Kube-scheduler子系统、Volcano模块和Fluid模块，其中，

所述Volcano模块包括Job组件、Queue组件、vc-controllers组件和vc-scheduler组件，其中，所述Job组件和所述Queue组件集成于所述Kube-apiserver子系统，所述vc-controllers组件集成于Kube-controller-manager子系统，所述vc-scheduler组件集成于所述Kube-scheduler子系统；

所述Fluid模块包括Dataset控制组件(即图2中的Dataset controller)、Runtime控制组件(即图2中的Runtime controller)、Volume控制组件(即图2中的Volumecontroller)、Fluid调度器组件(即图2中的fluid-scheduler)、Dataset组件和Runtime模块(未图示)，其中，所述Dataset组件和所述Runtime模块集成于所述Kube-apiserver子系统，所述Dataset控制组件、Runtime控制组件、Volume控制组件集成于Kube-controller-manager子系统，所述Fluid调度器组件集成于所述Kube-scheduler子系统。

示例性地，所述Runtime模块包括Alluxio Runtime组件、GooseFS Runtime组件、JuiceFS Runtime组件和JindoFS Runtime组件。

在一种可实施的方式中，所述数据调度系统还包括OSS(object StorageService)组件、Ceph组件和HDFS(Hadoop Distributed File System)组件。

在本实施例中，由于现有的Volcano及Fluid都只是解决了一部分问题，前者解决了Gang-Schedule的问题，解决了大数据，DL(Deep Learning，深度学习)、ML(MachineLearning，机器学习)的job之间相互依赖等问题，后者解决了数据分布式缓存的问题，并将分布式缓存部署到kubernetes集群中，拉近了计算和缓存的距离，但是调度方面也没有完全实现按照数据感知实行智能调度的问题，因为其调度实现方式是通过webhook注入调度到Pod，注入node select到pod的yaml文件中。这种方式下无法综合利用volcano的打分的机制给各个node打分和排序。另外目前Fluid社区实现调度亲和性需要对namespace、kubernetes集群进行配置等，手动操作的比较多，用起来较为麻烦。

基于此，本申请实施例的技术方案通过将vc-controllers组件集成于Kube-controller-manager子系统，所述vc-scheduler组件集成于所述Kube-scheduler子系统，所述Dataset组件和所述Runtime模块集成于所述Kube-apiserver子系统，所述Dataset控制组件、Runtime控制组件、Volume控制组件集成于Kube-controller-manager子系统，所述Fluid调度器组件集成于所述Kube-scheduler子系统，从而实现基于Kubernetes Operator技术、Kubernetes scheduder Framework、Fluid和Volcano技术，设计和实现一种基于应用数据的数据感知和调度优化的调度方法，该调度方法基于Kubernetes schedulerFramework，可以作为一个调度插件与其它调度引擎如Volcano无缝集成，与Volcano相互补充，相比于仅部署Fluid，由于目前Fluid实现调度亲和性需要对namespace，kubernetes集群进行配置等，手动操作的比较多，便利性差，而本实施例通过在部署Fluid(即Fluid模块)的基础上，还无缝集成了Volcano模块，通过Volcano模块和Fluid模块各自组件功能的优势互补，从而既能满足数据亲和性，又能和Volcano其他的一些调度plugin一起参与每个node的打分，通过Volcano模块来进行数据调度，不需要对namespace及kubernetes集群做额外的配置，克服了在Kubernetes Operator中仅部署Fluid模块的固有缺陷，使得本实施例能够提供一种基于批处理系统调度及数据感知调度联合为基础构建的调度方法，从而使得既可以通过Volcano模块为大数据的机器学习和深度学习提供gang-scheduler、fair-aware的解决方案，又能通过Fluid模块迅速拉近数据与计算的距离，有效解决大数据上云等场景中遇到的性能瓶颈问题，有效实现对应用数据的数据智能感知和调度优化。

另外，请结合参照图3，图3为本发明实施例涉及改造volcano模块的框架示意图。该Volcano Job(即上述的Job组件)模块提供了一个自定义资源，jobs.batch.volcano.sh对于该自定义资源，没有定义任何跟应用数据相关的元素。在本实施例中，需要将应用数据相关信息写入自定义资源，根据自定义资源，结合Fluid dataset实现应用数据感知调度和优化。该应用数据相关信息会在调度程序插件plugin中被volcano-scheduler所使用。根据应用数据相关信息，通过对node信息的检索，所有含有该应用数据相关信息的node，都可以作为调度pod的目标节点。

图3中涉及到的主要组件包括：Volcano Job(即Job组件)、Volcano Controllers(即vc-controllers组件)和vc-scheduler(即vc-scheduler组件)三个版块。该方案具体实现流程如下：

1、配置volcano-scheduler的configmap，启动本案提出的sheduler plugin，该configmap定义了第3步调度中使用的调度策略，包含了使用哪些plugin，各个调度插件的权重等等。

2、用户通过kubectl创建Volcano Job资源。Volcano job模块参与了该部分，其定义包含了dataset的信息。

3、Volcano Controller监测到Job资源创建，校验资源有效性，依据JobSpec创建依赖的Pod、Service和ConfigMap等资源，执行配置的插件，并负责第5步中job资源的生命周期管理，在本实施例中，它会检测dataset的变化，并执行相应的操作，包括对task的等待删除，基于最新dataset启动新的task等。

4、Volcano Scheduler监听Pod资源的创建，依据第1步中的调度策略，完成Pod资源的调度和绑定。该步骤根据本实施例的scheduler plugin的实现，结合其它调度plugin，经过综合评分，选出一个最优节点。

5、Kubelet负责Pod资源的创建，业务开始执行。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的终端结构示意图。

本发明实施例终端为数据调度设备。

如图1所示，该终端可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

可选地，终端还可以包括摄像头、RF(Radio Frequency，射频)电路，传感器、音频电路、WiFi模块等等。其中，传感器比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示屏的亮度，接近传感器可在终端设备移动到耳边时，关闭显示屏和/或背光。当然，终端设备还可配置陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

本领域技术人员可以理解，图1中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及数据调度程序。

在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的数据调度程序，并执行以下操作：

参照图5，本发明提供一种数据调度方法，所述数据调度方法应用于如上述的数据调度系统，在数据调度方法的第一实施例中，所述数据调度系统包括Volcano模块、Fluid模块和Kubernetes Operator子系统，数据调度方法包括以下步骤：

步骤S10，根据所述Volcano模块、所述Fluid模块和所述Kubernetes Operator子系统，通过CRD自定义资源的方式对Job资源进行改造；

步骤S20，通过调度程序插件的方式，将所述Volcano模块的vc-scheduler组件集成进入所述Kube-scheduler子系统；

步骤S30，通过所述Volcano模块、所述Fluid模块和所述Kubernetes Operator子系统对数据进行调度。

由于本实施例将Volcano模块集成进入Kube-scheduler子系统，本领域技术人员可知的是，Volcano模块包括Job组件，因此可通过Volcano模块的Job组件引入dataset这个定义，并将dataset的相关信息都写入到了scheduler cache(调度器缓存)中的nodeinfo(节点信息)中，从而使得调度plugin(插件)时Volcano模块只需要通过对cache(缓存)中保存的nodeinfo的筛选就可以选出正确的目标节点，无需对job拉起的pod进行任何更改即可实现pod的感知数据的调度。也即，通过Volcano模块来进行数据调度，克服了在KubernetesOperator中仅部署Fluid模块的固有缺陷。

本实施例通过将数据调度系统设置包括Volcano模块、Fluid模块和KubernetesOperator子系统，并根据Volcano模块、Fluid模块和Kubernetes Operator子系统，通过CRD(Custom Resource Definition，自定义资源)自定义资源的方式对Job资源进行改造，从而实现基于现有Volcano及Fluid等技术，根据Kubernetes Operator、Kubernetes scheduderFramework对现有的jobs.batch.volcano.sh CRD进行改造，以Scheduler plugin的方式集成进入Volcano，将两个分散的Scheduler统一，并且不需要额外的操作，也即本实施例不需要对namespace做任何配置，也不需要对kubernetes集群做任何改动，就能够根据应用数据感知、智能调度到应用数据所缓存的地方，并通过调度程序插件的方式，将Volcano模块的vc-scheduler组件集成进入Kube-scheduler子系统，使得本实施例能够提供一种基于批处理系统调度及数据感知调度联合为基础构建的调度方法，可以既为大数据的机器学习和深度学习提供gang-scheduler、fair-aware的解决方案，又能迅速拉近数据与计算的距离，有效解决大数据上云等场景中遇到的性能瓶颈问题，进而能够实现对应用数据的数据智能感知和调度优化。

进一步地，基于上述本发明的第一实施例，提出本发明数据调度方法的第二实施例，在本实施例中，所述方法还包括：

步骤A10，在所述Fluid模块创建的所述数据集对应的运行状态为预备状态时，通过所述Fluid模块将alluxio worke节点配置对应的目标标签，其中，所述目标标签包括namespace信息和datasetname信息。

在本实施例中，具体地，Fluid(即Fluid模块)在创建dataset时，当dataset(数据集)对应的Runtime的状态变成Ready时，它会给Runtime拉起的每一个alluxio worker节点加入一个label，该label的定义如下：fluid.io/s-$NM-$datasetname。其中$NM是该dataset对应的namespace，$datasetname为dataset的名字(即datasetname信息)。本实施例基于这一点，便可实现对作业进行应用数据感知和调度优化，从而不需要对namespace做任何配置，也不需要对kubernetes集群做任何改动，就能够根据应用数据感知，智能调度到应用数据所缓存的地方，进而确保对应用数据的数据智能感知和调度优化。

在一种可能的实施方式中，所述Volcano模块包括vc-scheduler组件，所述方法还包括：

步骤B10，通过所述vc-scheduler组件读取当前配置文件，得到当前配置文件的actions进程，以及每个action进程对应的plugins插件；

步骤B20，在创建新的会话过程中，通过所述vc-scheduler组件获取当前cluster集群里面的pod容器信息、tasks任务信息和node节点信息，并保存在缓存中，作为本轮调度的资源视图；

步骤B30，通过所述vc-scheduler组件依次执行当前配置文件中的actions进程，以及各所述action进程对应的plugins插件，通过各所述plugins插件选择出的最优node节点作为本次调度的结果。

进一步地，所述通过各所述plugins插件选择出的最优node节点作为本次调度的结果的步骤包括：

步骤C10，通过各所述plugins插件分别选出一组node作为本次调度的目标节点，以及分别为各自选出的目标节点进行分数评价；

步骤C20，在所述分数评价完成后，对分数评价后的各所述目标节点的分数进行相交运算，以选出目标节点组；

步骤C30，根据各所述plugins插件对应的权重，从所述目标节点组中选择出最优node节点作为本次调度的结果。

为了进一步助于理解本申请的该实施方式，列举一具体实施例，请参照图4，图4为本发明实施例中Volcano进行调度的流程示意图：

如图4所示，在一次调度过程中大体分为3步，每一步都需要做应用数据感知的调度相关工作。

第一步，首先Volcano scheduler(即vc-scheduler组件)需要读取当前的配置文件，获得当前配置文件中actions，以及每个action对应的plugins等。

第二步，获得这些配置文件后，开启一轮新的会话，创建新的会话过程中，会首先获取当前cluster里面的pod、tasks、node information等，并保存在cache中，作为本轮调度的资源视图。

第三步，依次执行配置中的action及其对应的plugins，经过不同plugin的选择，选出一个最适合的node作为本次调度的结果。每个plugin都会选出一组node作为本次调度的目标节点，并且每个node都有会对应的打分，经过相交运算，选出目标节点组，最后根据每个scheudler plugin的权重，从最终的目标节点组中选出一个得分最高的node，作为本次调度的目标节点。

具体地，在本实施例中，在第一步时，需要将co-locality plugin设置到配置文件中，参与本轮调度对node的选择及打分。Node的打分机制主要是通过volcano-scheduler的configmap里面nodeorder来实现的。本实施例通过给支持的scheduler plugin配置不同的权重，这样就可以控制每种调度算法插件的影响因子。例如，列举如下一示例性的调度算法：

调度策略中，只enable了两个调度插件，scheduler plugin A的权重是1，scheduler plugin B的权重是100，调度plugin A选出了node1和node2两个节点。node1得分100，node2得分50；调度plugin B，选出了node1、node2和node3，分值依次是3、5和10。经过相交，选出的目标主机组为node1和node2，node1的得分最终为100*1+3*100＝400，node2的得分为50*1+5*100＝550，这时会选择node2为本次调度的目标主机，由此可见，可以通过权重来控制调度算法插件的影响。

在该方案实现中，第二步需要获取应用数据相关信息，相关信息主要有FluidDataset及Runtime。然后再定义新的调度plugin加入到allocate action中。对于获取应用数据相关信息的获取，是通过api-Server添加Fluid Dataset及Runtime的信息到系统cache中。作为本轮应用数据感知调度输入。Cache中dataset的信息至少包括以下几个部分：Cache状态、Hcfs信息，mounts point、Phase、与之关联的runtime信息、Ufs Total等。

然后增加co-locality调度plugin，该调度的流程如下：

1、根据task中的pod template的dataset信息，如果dataset为空字符串或者dataset没有设置，意味着不需要应用数据，尽量选择集群中非分布式缓存部署的node；

2、如果dataset有定义，并且已经ready，相关的Alluxio work pod所在的node就会有一个fluid.io/s-$NM-$datasetname的label。该label在下一个调度周期会被cache捕获，放入node的nodeinfo保存起来。而co-locality调度plugin根据cache中nodeinfo保存的dataset的状态、名称等进行node节点的过滤。

3、选出缓存分布式系统中带有dataset名称并且状态为Ready的node list，最后和系统中其它的scheduler plugin一起根据配置的权重进行打分，选出得分最高的的host，作为本次调度Pod最合适的目标节点。

值得一提的是，在本实施例中，通过job引入了dataset这个定义，并将dataset这个定义相关信息都写入到了scheduler cache中的nodeinfo中，调度plugin只需要通过对cache中保存的nodeinfo的筛选就可以选出正确的目标节点，无需对job拉起的pod进行任何更改，便可以实现pod的感知数据的调度。

需要说明的是，该具体实施例阐述的诸多细节仅助于理解本申请的技术构思，并不构成对本申请的限定，基于本申请的该技术构思进行更多形式的简单变换，均应在本申请的保护范围内。

本实施例通过vc-scheduler组件读取当前配置文件，得到当前配置文件的actions进程，以及每个action进程对应的plugins插件，并在创建新的会话过程中，通过vc-scheduler组件获取当前cluster集群里面的pod容器信息、tasks任务信息和node节点信息，并保存在缓存中，作为本轮调度的资源视图，然后通过vc-scheduler组件依次执行当前配置文件中的actions进程，以及各action进程对应的plugins插件，通过各plugins插件选择出的最优node节点作为本次调度的结果，从而通过配置项，将数据感知调度与其它支持的调度结合打分机制对选择出来的每个节点进行打分，将pod调度到得分最高的目标节点上运行。

在一种可能的实施方式中，所述Volcano模块包括vc-controllers组件，所述方法还包括：

步骤D10，通过所述vc-controllers组件检查所述Job组件中数据集的任务状态；

步骤D20，若所述任务状态为第一状态，则启动新任务进程，其中，所述新任务进程使用新的dataset数据集，所述第一状态为完成状态或者失败状态；

步骤D30，若所述任务状态为第二状态，则进行等待，直至任务超时或者任务完成，启动所述新任务进程，其中，所述第二状态为正在运行状态。

为了进一步助于理解本申请的该实施方式，列举一具体实施例，在具体本实施例中进一步详细介绍Volcano Controllers模块(即vc-controllers组件)中的实现：

Volcano Controllers模块主要是对自定义资源生命周期的管理。本实施例引入了dataset到Job这个自定义资源中，因此该Volcano Controllers模块增加了对dataset生命周期管理的功能。

在一实例中，当对job(即Job组件)中的dataset进行update的时候，volcanoController会检查当前job中使用老dataset的task的状态(即数据集的任务状态)；如果task的状态是completed或者Failed(即第一状态)，那么启动新的task(即新任务进程)，并且新的task使用新的dataset；如果task的状态是Running(即第二状态)，会根据默认的gracefulperiod时间等待，直到任务超时或者任务完成，启动使用新的dataset的新task。

在另一实例中，当对job中的dataset进行delete的时候，volcano Controller会检查当前job中使用老dataset的task的状态；如果task的状态是completed或者Failed，那么启动新的task，并且新task的调度将不受scheduler plugin的影响；如果task的状态是Running，会根据默认的gracefulperiod时间等待，直到任务超时或者任务完成，启动新task，新task的调度将不受scheduler plugin的影响。

需要说明的是，该具体实施例阐述的诸多细节仅助于理解本申请的技术构思，并不构成对本申请的限定，基于本申请的该技术构思进行更多形式的简单变换，均应在本申请的保护范围内。

本实施例通过vc-controllers组件检查Job组件中数据集的任务状态，如果该任务状态为第一状态，则启动新任务进程，其中，第一状态为完成状态或者失败状态。如果该任务状态为第二状态，则进行等待，直至任务超时或者任务完成，启动所述新任务进程，其中，第二状态为正在运行状态，从而使得本实施例能够结合volcano的实现机制，通过scheduler plugin的形式，集成到调度框架中，使得本实施例能够将上述涉及到的plugins调度插件可以与其它插件一起参与调度流程中的打分，为现有的调度机制又增加了一个数据感知的插件。

此外，本发明还提供一种数据调度设备，所述数据调度设备包括：存储器、处理器及存储在所述存储器上的数据调度程序；所述处理器用于执行所述数据调度程序，以实现上述数据调度方法各实施例的步骤。

本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者一个以上程序，所述一个或者一个以上程序还可被一个或者一个以上的处理器执行以用于实现上述数据调度方法各实施例的步骤。

本发明计算机可读存储介质具体实施方式与上述数据调度方法各实施例基本相同，在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种数据调度系统，其特征在于，所述数据调度系统包括Kubernetes Operator子系统和Kube-apiserver子系统，所述Operator子系统包括Kube-controller-manager子系统、Kube-scheduler子系统、Volcano模块和Fluid模块，其中，

所述Volcano模块包括Job组件、Queue组件、vc-controllers组件和vc-scheduler组件，其中，所述Job组件和所述Queue组件集成于所述Kube-apiserver子系统，所述vc-controllers组件集成于Kube-controller-manager子系统，所述vc-scheduler组件集成于所述Kube-scheduler子系统；

所述Fluid模块包括Dataset控制组件、Runtime控制组件、Volume控制组件、Fluid调度器组件、Dataset组件和Runtime模块，其中，所述Dataset组件和所述Runtime模块集成于所述Kube-apiserver子系统，所述Dataset控制组件、Runtime控制组件、Volume控制组件集成于Kube-controller-manager子系统，所述Fluid调度器组件集成于所述Kube-scheduler子系统。

2.如权利要求1所述的数据调度系统，其特征在于，所述Runtime模块包括AlluxioRuntime组件、GooseFS Runtime组件、JuiceFS Runtime组件和JindoFS Runtime组件。

3.如权利要求1所述的数据调度系统，其特征在于，所述数据调度系统还包括OSS(object Storage Service)组件、Ceph组件和HDFS(Hadoop Distributed File System)组件。

4.一种数据调度方法，其特征在于，所述数据调度方法应用于如权利要求1至3中任一项所述的数据调度系统，所述数据调度系统包括Volcano模块、Fluid模块和KubernetesOperator子系统，所述方法包括：

根据所述Volcano模块、所述Fluid模块和所述Kubernetes Operator子系统，通过CRD自定义资源的方式对Job资源进行改造；

通过调度程序插件的方式，将所述Volcano模块的vc-scheduler组件集成进入所述Kube-scheduler子系统；

通过所述Volcano模块、所述Fluid模块和所述Kubernetes Operator子系统对数据进行调度。

5.如权利要求4所述的数据调度方法，其特征在于，所述方法还包括：

在所述Fluid模块创建的所述数据集对应的运行状态为预备状态时，通过所述Fluid模块将alluxio worke节点配置对应的目标标签，其中，所述目标标签包括namespace信息和datasetname信息。

6.如权利要求4所述的数据调度方法，其特征在于，所述Volcano模块包括vc-scheduler组件，所述方法还包括：

通过所述vc-scheduler组件读取当前配置文件，得到当前配置文件的actions进程，以及每个action进程对应的plugins插件；

在创建新的会话过程中，通过所述vc-scheduler组件获取当前cluster集群里面的pod容器信息、tasks任务信息和node节点信息，并保存在缓存中，作为本轮调度的资源视图；

通过所述vc-scheduler组件依次执行当前配置文件中的actions进程，以及各所述action进程对应的plugins插件，通过各所述plugins插件选择出的最优node节点作为本次调度的结果。

7.如权利要求6所述的数据调度方法，其特征在于，所述通过各所述plugins插件选择出的最优node节点作为本次调度的结果的步骤包括：

通过各所述plugins插件分别选出一组node作为本次调度的目标节点，以及分别为各自选出的目标节点进行分数评价；

在所述分数评价完成后，对分数评价后的各所述目标节点的分数进行相交运算，以选出目标节点组；

根据各所述plugins插件对应的权重，从所述目标节点组中选择出最优node节点作为本次调度的结果。

8.如权利要求4至7中任一项所述的数据调度方法，其特征在于，所述Volcano模块包括vc-controllers组件，所述方法还包括：

通过所述vc-controllers组件检查所述Job组件中数据集的任务状态；

若所述任务状态为第一状态，则启动新任务进程，其中，所述新任务进程使用新的dataset数据集，所述第一状态为完成状态或者失败状态；

若所述任务状态为第二状态，则进行等待，直至任务超时或者任务完成，启动所述新任务进程，其中，所述第二状态为正在运行状态。

9.一种数据调度设备，其特征在于，所述数据调度设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据调度程序，所述数据调度程序被所述处理器执行时实现如权利要求4至8中任一项所述的数据调度方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有数据调度程序，所述数据调度程序被处理器执行时实现如权利要求4至8中任一项所述的数据调度方法的步骤。