CN104636204A - 一种任务调度方法与装置 - Google Patents

Abstract

本发明提供了一种任务调度方法及装置；所述方法包括：当判断需要将第一节点的任务调度到第二节点时，获取系统中各节点当前的属性数据；所述第二节点为空闲节点；根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。本发明能够在调度预测执行任务时满足数据本地性需求，从而降低大数据处理作业的执行时间。

Description

一种任务调度方法与装置

技术领域

本发明涉及大数据处理领域，尤其涉及一种任务调度方法与装置。

背景技术

在大数据处理系统的作业调度问题中，随着数据集的增加，移动数据的代价远远大于“移动”数据处理模块的代价，因此，在大数据处理环境中，需要将计算推向数据而非将数据推向计算，即取得更好的数据本地性(DL：data locallity)是取得大数据处理系统高效率的核心。

同时，在大数据处理过程中，如果一个节点执行任务的速度明显慢于其他节点，则该节点被标志为慢节点(straggler)，其上执行的任务被标识为慢任务(straggler task)，慢任务会大大延长MapReduce等大数据处理批处理任务的执行时间，从而被谷歌的工程师定义为影响系统性能优化的难题之一。并且，以MapReduce为代表的批处理模式，其处理模式多分为几个阶段，以MapReduce为例，MapReduce作业的生命周期大致可分为2个阶段：Map阶段和Reduce阶段。在每个阶段，依据处理数据集的大小，计算被均匀地分解为小的任务集合，每个任务被调度到各自的计算节点执行，从而实现对大数据集的并行处理并加速作业完成。每个Reduce任务的输入依赖于所有Map任务的输出，只有所有Map任务均成功完成后Reduce任务才会开始。如果部分Map任务进展缓慢，会造成Map阶段不能迅速结束，使得Reduce阶段不能开始，造成其他Reduce任务处理资源等待，不仅延长了整个作业的完成时间，而且造成了资源闲置和计算能力浪费；对于Reduce慢任务，由于其迟迟不能完成，保存在Map任务节点上的中间数据不能删除，造成存储空间浪费。

为了解决慢任务的问题，一般采用重现调度的模式实现。以MapReduce编程模型的开源实现Hadoop为例，Hadoop的缺省调度器使用ProgressScore 来量化一个任务的进展程度，对于Map任务而言，任务的进度和已处理数据的大小成正比，所以ProgressScore即为已处理数据占输入数据的比例。TaskTracker会在每次发送心跳信息时汇报其上运行任务的ProgressScore，因此，集中的任务调度器JobTracker知道每个任务的ProgressScore。

Hadoop采用一种简单的方式识别慢任务，首先，JobTracker对所有任务的ProgressScore求算术平均值，用averageScore表示，如果有n个任务正在运行，则其值可由下式求得：

$\mathrm{averageScore}=\frac{\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\mathrm{ProgressScore}\left({\mathrm{task}}_i\right)}{n}$

当某个任务至少运行1分钟后，JobTracker检查它当前的ProgressScore是否低于averageScore－0.2，如果低于，该任务就被标示为慢任务，当有空闲任务槽可用时，JobTracker会调度该任务的一个副本任务，称为预测执行任务(speculative task)，到空闲计算槽上执行。

但是，Hadoop的缺省机制没有考虑数据本地性的需求。在集中管理的数据中心中，这种做法有其合理性，因为数据中心中节点间带宽资源相对充足，预测执行任务数所占总任务数比例不大的情况下，传输数据的时间开销不会对作业完成时间造成太大影响。

然而，在云计算等虚拟计算环境中，尤其是异构资源构建的MapReduce即服务等应用场景下，相对于数据中心，节点之间的带宽衰减严重且异构性强，如果在调度预测执行任务的时候采用Hadoop缺省的慢任务预测执行机制，即直接调度慢任务的预测执行任务到空闲资源上执行，而不考虑数据本地性，可能导致慢任务完成时间较长，从而延长作业执行时间，降低系统利用率，造成资源浪费。

相关文献明确指出，资源异构的执行环境中，调度预测执行任务时考虑数据本地性能够降低作业执行时间，提升系统吞吐率。

综上，如何在调度预测执行任务时满足数据本地性需求，成为虚拟计算环境中应用性能优化的重要研究课题之一。但是，目前业界还没有给出合适的解决方案。

发明内容

本发明要解决的技术问题是如何在调度预测执行任务时满足数据本地性需求，从而降低大数据处理作业的执行时间。

为了解决上述问题，本发明提供了一种任务调度方法，包括：

当判断需要将第一节点的任务调度到第二节点时，获取系统中各节点当前的属性数据；所述第二节点为空闲节点；

根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；

按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。

可选地，一个组合调度方案的预计完成时间为该组合调度方案中，被迁移的各任务的预计执行完成时间中的最大值。

可选地，一个被迁移的任务的预计执行完成时间为当前时刻加上该任务的数据传输时间加上传输完成后，该任务在迁移的目标节点上被处理所需要的时间；其中，被处理所需要的时间为目标节点处理该类任务的处理速率的倒数；

一个任务的数据传输时间为：当该任务迁移到的目的节点包含该任务的数据时，所述数据传输时间为0；不包含时，所述数据传输时间为该任务的数据量除以该任务迁移出的源节点和目的节点之间的带宽。

可选地，所述根据属性数据确定预计完成时间最小的组合调度方案包括：

根据所述属性数据更新预定的数据结构中所保存的各节点的属性数据；所述预定的数据结构为有向完全图；各节点的所述属性数据包括该节点对不同类型任务的处理能力及存储的数据块列表量；所述有向完全图中的有向边的属性数据包括两个相邻节点的带宽，以及将该有向边的起始节点上正在执 行的任务迁移到该有向边终止节点上执行时，该被迁移任务的预计执行完成时间；

计算所述有向完全图的最短的有向路径；将所述最短的有向路径对应的组合调度方案确定为预计完成时间最小的组合调度方案；其中，所述有向路径的长度为该路径所包含的各有向边的所述预计执行完成时间中的最大值。

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

在迁移任务时，在目标节点启动封装有任务追踪器TaskTracker的轻量级Linux容器实例，并将迁移的任务重新在目标节点开始执行。

本发明还提供了一种任务调度装置，包括：

更新模块，用于当判断需要将第一节点的任务调度到第二节点时，获取系统中各节点当前的属性数据；所述第二节点为空闲节点；

规划模块，用于根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；

迁移模块，用于按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。

可选地，一个组合调度方案的预计完成时间为该组合调度方案中，被迁移的各任务的预计执行完成时间中的最大值。

可选地，一个被迁移的任务的预计执行完成时间为当前时刻加上该任务的数据传输时间加上传输完成后，该任务在迁移的目标节点上被处理所需要的时间；其中，被处理所需要的时间为目标节点处理该类任务的处理速率的倒数；

一个任务的数据传输时间为：当该任务迁移到的目的节点包含该任务的数据时，所述数据传输时间为0；不包含时，所述数据传输时间为该任务的数据量除以该任务迁移出的源节点和目的节点之间的带宽。

可选地，所述规划模块根据属性数据确定预计完成时间最小的组合调度方案是指：

所述规划模块根据所述属性数据更新预定的数据结构中所保存的各节点的属性数据；所述预定的数据结构为有向完全图；各节点的所述属性数据包括该节点对不同类型任务的处理能力及存储的数据块列表量；所述有向完全图中的有向边的属性数据包括两个相邻节点的带宽，以及将该有向边的起始节点上正在执行的任务迁移到该有向边终止节点上执行时，该被迁移任务的预计执行完成时间；计算所述有向完全图的最短的有向路径；将所述最短的有向路径对应的组合调度方案确定为预计完成时间最小的组合调度方案；其中，所述有向路径的长度为该路径所包含的各有向边的所述预计执行完成时间中的最大值。

可选地，所述迁移模块还用于在迁移任务时，在目标节点启动封装有任务追踪器TaskTracker的轻量级Linux容器实例，并将迁移的任务重新在目标节点开始执行。

本发明引入轻量级Linux容器提供的大数据处理单元快速部署技术，在此基础上提出了基于组合优化的预测执行技术，借助数据资源分布、计算节点性能、节点间网络带宽等细粒度的资源信息，实现预测执行任务的组合优化调度，满足了数据本地性需求，从而能够降低大数据处理作业的执行时间，大大提升大数据处理系统的吞吐量。实验证明，本发明能够最多减少50％以上的任务执行时间。另外，和传统的Map任务迁移方式不同，由于Linux容器的封装性和快速启动特性，迁移时能够做到TaskTracker任务处理单元和任务一起迁移，即在目标节点启动封装有TaskTracker的轻量级Linux容器实例，并将迁移任务重新在目标节点开始执行。这是和传统的Hadoop作业迁移的不同，传统Hadoop作业迁移必须要求目标节点部署有TaskTracker任务处理单元。

附图说明

图1为实施例一的任务调度方法的流程示意图；

图2为实施例一的例子中的节点拓扑示意图；

图3为实施例一的例子中的组合调度方案示意图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本发明实施例以及实施例中的各个特征可以相互结合，均在本发明的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一、一种任务调度方法，如图1所示，包括：

S101、当判断需要将第一节点的任务调度到第二节点时时，获取各节点当前的属性数据；所述第二节点为空闲节点；

S102、根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；

S103、按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。

本实施例中，所述第一节点可以为慢任务节点。所述有向路径上只包括两个节点的情况即现有的解决方案：直接从慢任务节点迁移任务到空闲节点；包括两个以上节点时，慢任务节点上的任务会迁移到该有向路径上的下一个节点上，后续节点依次迁移任务到下一个节点上，直到有向路径上的倒数第二个节点迁移任务到空闲节点上。

随着docker等轻量级Linux容器的出现，应用程序可以被封装到镜像文件中，可以在核心版本高于2.6.8的Linux服务器快速启动一个处理单元(如Hadoop中的TaskTracker)，因此，数据的处理单元可以被封装到docker镜像中并被自由部署到任意节点，甚至快速迁移到目标节点。这为本实施例提出的组合优化调度提供了技术基础。

本实施例还可以包括：

在迁移任务时，在目标节点启动封装有任务追踪器TaskTracker的轻量级Linux容器实例，并将迁移的任务重新在目标节点开始执行。

针对预测执行任务调度中的组合优化问题，本实施例的方法采用的是基于组合优化的预测执行技术，相对于现有技术中直接将慢任务节点上的任务调度给空闲节点的做法，本实施例在多种组合调度方案中进行优选，这是一种借助细粒度资源信息，通过组合优化机制满足预测执行任务的数据本地性需求，通过选择执行时间开销最低的组合调度方案，进而大幅降低整个作业Map阶段执行时间的优化技术。

本实施例中，假设一个组合调度方案对应的有向路径为从节点A(位于起点的节点)开始，依次历经节点B、节点C、节点D，到节点E为止，那么该组合调度方案就是节点A上的任务a迁移到节点B，节点B上的任务b迁移到节点C，节点C上的任务c迁移到节点D，节点D上的任务d迁移到节点E(位于终点的节点)。

本实施例中，不同的组合调度方案相当于不同的任务组合迁移方式，这里的组合表示不仅仅是从一个节点迁移任务到另一个节点，而是会形成一个连锁的迁移过程，比如任务e迁移到的目的节点A同时也是迁移出任务a的源节点。每个被迁移的任务将在目的节点上重新开始执行，因此本实施例也可以称为组合重执行方案。

本实施例的一种实施方式中，一个组合调度方案的预计完成时间为该组合调度方案中，被迁移的各任务的预计执行完成时间中的最大值。

本实施方式中，一个被迁移的任务的预计执行完成时间可以但不限于为当前时刻加上该任务的数据传输时间加上传输完成后，该任务在迁移的目标节点上被处理所需要的时间；其中，被处理所需要的时间为目标节点处理该类任务的处理速率的倒数。

其中，处理速率的单位可以为任务/秒，其物理意义是多少秒完成一个任务；可以依据各个节点执行数据分析任务的历史完成情况确定。

其中，一个任务的数据传输时间可以但不限于为：当该任务迁移到的目 的节点包含该任务的数据时，所述数据传输时间为0；不包含时，所述数据传输时间为该任务的数据量除以该任务迁移出的源节点和目的节点之间的带宽。

需要指出的是，在Hadoop集群应用场景中，任意两个任务处理节点之间都具备直接的网络连接，即带宽不会为零。所以不会出现0为分母的计算错误。

本实施例的一种实施方式中，根据所述属性数据确定所述预计完成时间最小的组合调度方案具体可以包括：

根据所述属性数据更新预定的数据结构中所保存的各节点的属性数据；所述预定的数据结构为有向完全图；各节点的所述属性数据包括该节点对不同类型任务的处理能力及存储的数据块列表量；所述有向完全图中的有向边的属性数据包括两个相邻节点的带宽，以及将该有向边的起始节点上正在执行的任务迁移到该有向边终止节点上执行时，该被迁移任务的预计执行完成时间；其中，预计执行完成时间可根据前文计算得到，在触发任务迁移调度时实时刷新；

计算所述有向完全图的最短的有向路径；将所述最短的有向路径对应的组合调度方案确定为预计完成时间最小的组合调度方案；其中，所述有向路径的长度为该路径所包含的各有向边的所述预计执行完成时间中的最大值。

可以采用已有的算法来计算最短的有向路径。其它实施方式中，也可以采用其它数据结构或算法确定预计完成时间最小的组合调度方案。

本实施例的一个例子中，在系统初始化时，先依据每个节点上的数据分布情况，节点对任务的处理能力(可以由历史信息统计生成)生成有向完全图的数据结构；当有任务调度时根据当前时刻节点的属性数据更新所述有向完全图的数据结构；当判断需要调度时(比如有节点请求任务触发调度过程时，或其它现有技术中触发调度的情况)，按照本实施例的上述方法找出最优的组合调度方案，按照该最优方案中的有向路径依次级联调度(比如按照上述节点A到E的有向路径，则是将节点A上的任务a迁移到节点B，节点B上的任务b迁移到节点C，……，将节点D上的任务d迁移到节点E)。当某个节点完成任务时、或调度完成后也可以更新所述有向完全图。

本例子的设计原理如下：

MapReduce作业的运行时间由执行时间最长的Map任务和运行时间最长的Reduce任务的运行时间之和决定，因此，要使作业的运行时间最短，就要最小化Map任务的运行时间t_mtask和Reduce任务的运行时间t_rtask的最大值，见式(1)：

min(t_job)＝min(max(t_mtask)+max(t_rtask)) 

                                           (1) 

＝min(max(t_mtask))+min(max(t_rtask))

因此，最小化MapReduce作业运行时间转化为一个Min-Max优化问题。由于Reduce任务数目比较少，任务需要传输的数据集较小，其输入数据需要从所有Map任务获取，不存在数据本地性问题。因此，预测执行组合调度技术主要降低所有Map任务中慢任务的运行时间，其优化目标方程如式(2)：

min(max(t_mtask))   (2)

上述降低所有Map任务中慢任务运行时间的问题可以进一步转化为如何最小化Map慢任务的预测执行任务的执行时间t_spec，目标方程见式(3)：

min(t_spec)   (3)

首先，对上述最小化t_spec的问题建模。既然每个节点之间都存在直接网络连接，即任意两点的通讯不需要第三个节点转发，因此，可采用完全图表示节点的网络拓扑结构，如图2所示，和任务迁移图，如图3所示。

图2中包括：

用于处理任务的节点N1～N6：拥有其上存储的数据块列表和任务处理能力两种属性。其中，N1为慢任务节点，N4为空闲节点。

数据块：拥有数据块大小一种属性(对Hadoop分布式文件系统HDFS而言，尺寸是固定的，由系统管理员指定)。

任务(Map任务)，拥有处理数据大小，进展程度ProgressScore和已运行时间T三种属性。 

网络连接：拥有网络带宽一种属性。

由于大数据处理的程序代码(对Haoop而言，是处理单元TaskTracker) 可以被封装为轻量级Linux容器的镜像文件并灵活迁移，因此，所有数据节点上均可以按需执行大数据处理的程序并作为处理节点的实例。因此，图2是一个无向完全图，每条边代表一个网络连接，具有网络带宽等属性；图3是一个有向完全图，每条边代表一个可能的迁移路径，表示将该边始点上运行的任务结束，迁移到该边的终点上重新执行。

如图3所示，虚拟计算环境中预测执行任务的调度，存在两种机制：

(1)Hadoop默认算法：直接在空闲资源上运行预测执行任务；比如图3中的虚线所示，慢任务节点s上的任务T_s直接迁移到空闲节点f。

(2)本实施例的方法：一种采用组合重执行机制的组合调度方案，其组合调度方案在图上可视为从慢任务节点到空闲节点的一条无环的有向路径。对该路径上的每条边，其始点上的任务会被迁移到其终点上重新执行，依次顺延，但是保留慢任务节点上的慢任务继续执行。比如图3中的双点划线所示，慢任务节点s上的任务T_s迁移到节点u上重新执行；节点u上的任务T_u迁移到节点v上重新执行；节点v上的任务T_v迁移到节点f上重新执行；节点x和节点y未包括在该有向路径中；假设组合重执行机制中不存在节点之间互换作业的情况，即路径中不存在环路，这在现实中是合理的，因为已经开始运行的作业其数据已经传输到节点本地，并且Map任务的负载大致相当，初始分配作业时已经考虑到了数据本地性的要求，因此节点之间互换作业并不会带来性能收益。

相对于Hadoop默认算法，本实施的方法引入了节点间带宽和节点处理能力能细粒度资源信息，并且设计了组合优化机制满足预测执行任务的数据本地性需求。

对图3中的边(u,v)而言，设T_u表示节点u上运行的Map任务，d(T_u)表示T_u所处理的数据，|d(T_u)|表示d(T_u)的大小，PR_v表示节点v完成该类型Map任务的ProgressRate(处理速率)，bw(u,v)表示节点u，v之间网络连接的带宽。

定义1(组合重执行任务的预计执行完成时间)：给定节点u上执行的Map任务T_u重新调度到节点v上执行，则其预计执行完成时间(Expected Time to Finish,ETF)，用t'_etf(u,v)表示，定义为式(4)。

${t^{\′}}_{\mathrm{etf}}(u,v)=t_c+t_{\mathrm{data}\_\mathrm{movement}}+\frac{1}{{\mathrm{PR}}_v}---\left(4\right)$

其中数据传输时间t_{data_movement}可由公式(5)求得：

$t_{\mathrm{data}\_\mathrm{movement}}=\left\{\begin{array}{ccc}0& \mathrm{if}& \mathrm{v\; contains\; d}\left(T_u\right)\\ \frac{\left|d\left(T_u\right)\right|}{\mathrm{bw}(u,v)}& \mathrm{if}& \mathrm{v\; does}{n}^{\′}\mathrm{t\; contain\; d}\left(T_u\right)\end{array}\right.---\left(5\right)$

其中t_c表示当前时刻。需要指出的是，d(T_u)也可以从u以外的节点传输到v，在实现中使用副本优化选择策略来加速传输。

定义2(慢任务组合重执行方案)：给定s表示慢任务运行节点，f表示空闲节点，PATH(s,f)表示图3中从s到f的一条路径，沿着PATH(s,f)级联地将所有该路径的包含边中起始节点的任务迁移到终止节点上执行，定义为沿PATH(s,f)的慢任务的组合重执行方案。

定义3(慢任务组合重执行预计完成时间)：给定沿PATH(s,f)的慢任务组合重执行，则其预计完成时间定义为各迁移任务的预计执行完成时间中的最大值，见式(6)。

$t_{\mathrm{spec}}\left(\mathrm{PATH}(s,f)\right)=\max \left({t^{\′}}_{\mathrm{etf}}(u,v)\right),\mathrm{for\; all}(u,v)\⋐\mathrm{PATH}(s,f)---\left(6\right)$

定义4(慢任务最优组合重执行方案)：给定s表示慢任务运行节点，f表示空闲节点，PATH(s,f)表示图3中从s到f的一条路径，最优慢任务组合执行方案定义为预测完成时间最小的组合重新执行方案，用CRES表示，见式(7)：

t_spec(CRES)＝min(t_spec(PATH(s,f))),for all Path connecting s,f   (7) 

t_cres表示沿最优组合重执行方案CRES所取得的慢任务预测执行的预计完成时间，见式(8)：

t_cres＝min(t_spec(PATH(s,f))),for all Path connecting s,f   (8) 

则由式(6)和式(8)可得组合重执行优化的目标方程，见式(9)：

$t_{\mathrm{cres}}=\min \left(\max \right({t^{\′}}_{\mathrm{etf}}(u,v)),\mathrm{for\; all}(u,v)\⋐\mathrm{PATH}(s,f)---\left(9\right)$

将图3中有向边(u,v)的权重设置为t'_etf(u,v)，该权值大于零，则慢任务最优组合重执行方案在图3上体现为满足式(9)的一条最优路径，该路径的权值 不是所含边的权值算术和，而是所含边中权值的最大值。基于动态规划思想，本实施例提出了优化预测执行任务执行时间的组合优化调度方案，表一给出了本实施例一个具体例子的伪代码。

表一、调度方案伪代码

实施例二、一种任务调度装置，包括：

更新模块，用于当判断需要将第一节点的任务调度到第二节点时，获取系统中各节点当前的属性数据；所述第二节点为空闲节点；

规划模块，用于根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；

迁移模块，用于按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。

本实施例的一种实施方式中，一个组合调度方案的预计完成时间为该组合调度方案中，被迁移的各任务的预计执行完成时间中的最大值。

本实施方式中，一个被迁移的任务的预计执行完成时间为当前时刻加上该任务的数据传输时间加上传输完成后，该任务在迁移的目标节点上被处理所需要的时间；其中，被处理所需要的时间为目标节点处理该类任务的处理速率的倒数。

本实施方式中，一个任务的数据传输时间为：当该任务迁移到的目的节点包含该任务的数据时，所述数据传输时间为0；不包含时，所述数据传输时间为该任务的数据量除以该任务迁移出的源节点和目的节点之间的带宽。

需要指出的是，在Hadoop集群应用场景中，任意两个任务处理节点之间都具备直接的网络连接，即带宽不会为零。所以不会出现0为分母的计算错误。

本实施例的一种实施方式中，所述规划模块根据属性数据确定预计完成时间最小的组合调度方案是指：

所述规划模块根据所述属性数据更新预定的数据结构中所保存的各节点的属性数据；所述预定的数据结构为有向完全图；各节点的所述属性数据包括该节点对不同类型任务的处理能力及存储的数据块列表量；所述有向完全图中的有向边的属性数据包括两个相邻节点的带宽，以及将该有向边的起始节点上正在执行的任务迁移到该有向边终止节点上执行时，该被迁移任务的预计执行完成时间；计算所述有向完全图的最短的有向路径；将所述最短的有向路径对应的组合调度方案确定为预计完成时间最小的组合调度方案；其中，所述有向路径的长度为该路径所包含的各有向边的所述预计执行完成时间中的最大值。

本实施例的一种实施方式中，所述迁移模块还可以用于在迁移任务时，在目标节点启动封装有TaskTracker的轻量级Linux容器实例，并将迁移的任务重新在目标节点开始执行。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程 序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明的权利要求的保护范围。

Claims (10)

1.一种任务调度方法，包括：

当判断需要将第一节点的任务调度到第二节点时，获取系统中各节点当前的属性数据；所述第二节点为空闲节点；

根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；

按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。

2.如权利要求1所述的方法，其特征在于：

一个组合调度方案的预计完成时间为该组合调度方案中，被迁移的各任务的预计执行完成时间中的最大值。

3.如权利要求2所述的方法，其特征在于：

一个被迁移的任务的预计执行完成时间为当前时刻加上该任务的数据传输时间加上传输完成后，该任务在迁移的目标节点上被处理所需要的时间；其中，被处理所需要的时间为目标节点处理该类任务的处理速率的倒数；

一个任务的数据传输时间为：当该任务迁移到的目的节点包含该任务的数据时，所述数据传输时间为0；不包含时，所述数据传输时间为该任务的数据量除以该任务迁移出的源节点和目的节点之间的带宽。

4.如权利要求3所述的方法，其特征在于，所述根据属性数据确定预计完成时间最小的组合调度方案包括：

根据所述属性数据更新预定的数据结构中所保存的各节点的属性数据；所述预定的数据结构为有向完全图；各节点的所述属性数据包括该节点对不同类型任务的处理能力及存储的数据块列表量；所述有向完全图中的有向边的属性数据包括两个相邻节点的带宽，以及将该有向边的起始节点上正在执行的任务迁移到该有向边终止节点上执行时，该被迁移任务的预计执行完成时间；

计算所述有向完全图的最短的有向路径；将所述最短的有向路径对应的组合调度方案确定为预计完成时间最小的组合调度方案；其中，所述有向路径的长度为该路径所包含的各有向边的所述预计执行完成时间中的最大值。

5.如权利要求1所述的方法，其特征在于，还包括：

在迁移任务时，在目标节点启动封装有任务追踪器TaskTracker的轻量级Linux容器实例，并将迁移的任务重新在目标节点开始执行。

6.一种任务调度装置，其特征在于，包括：

更新模块，用于当判断需要将第一节点的任务调度到第二节点时，获取系统中各节点当前的属性数据；所述第二节点为空闲节点；

规划模块，用于根据所述属性数据确定预计完成时间最小的组合调度方案；所述组合调度方案是指按照对应的有向路径，将该有向路径上各节点执行的任务迁移到下一个节点上重新执行；各所述组合调度方案对应的所述有向路径不同；各所述有向路径上包括两个或两个以上节点，起点为所述第一节点，终点为所述第二节点；

迁移模块，用于按照所确定的组合调度方案对相应有向路径上各节点的任务进行迁移。

7.如权利要求6所述的装置，其特征在于：

一个组合调度方案的预计完成时间为该组合调度方案中，被迁移的各任务的预计执行完成时间中的最大值。

8.如权利要求7所述的装置，其特征在于：

一个被迁移的任务的预计执行完成时间为当前时刻加上该任务的数据传输时间加上传输完成后，该任务在迁移的目标节点上被处理所需要的时间；其中，被处理所需要的时间为目标节点处理该类任务的处理速率的倒数；

一个任务的数据传输时间为：当该任务迁移到的目的节点包含该任务的数据时，所述数据传输时间为0；不包含时，所述数据传输时间为该任务的数据量除以该任务迁移出的源节点和目的节点之间的带宽。

9.如权利要求8所述的装置，其特征在于，所述规划模块根据属性数据确定预计完成时间最小的组合调度方案是指：

所述规划模块根据所述属性数据更新预定的数据结构中所保存的各节点的属性数据；所述预定的数据结构为有向完全图；各节点的所述属性数据包括该节点对不同类型任务的处理能力及存储的数据块列表量；所述有向完全图中的有向边的属性数据包括两个相邻节点的带宽，以及将该有向边的起始节点上正在执行的任务迁移到该有向边终止节点上执行时，该被迁移任务的预计执行完成时间；计算所述有向完全图的最短的有向路径；将所述最短的有向路径对应的组合调度方案确定为预计完成时间最小的组合调度方案；其中，所述有向路径的长度为该路径所包含的各有向边的所述预计执行完成时间中的最大值。

10.如权利要求6所述的装置，其特征在于：

所述迁移模块还用于在迁移任务时，在目标节点启动封装有任务追踪器TaskTracker的轻量级Linux容器实例，并将迁移的任务重新在目标节点开始执行。