任务调度方法、装置及控制节点与流程

本申请涉及计算机数据处理技术领域，特别涉及任务调度方法、装置及控制节点。

背景技术：

分布式计算集群可以分为分布式实时计算集群和分布式离线计算集群，在现有的分布式离线计算集群中，都有两种基本角色，分别为控制节点和计算节点。控制节点可以为各个计算节点分配任务，由计算节点执行各个任务。在实际应用中，计算节点可能由于异常原因而出现意外情况，而为了保障计算节点在单点失效后，集群仍可对外提供服务，控制节点可以将在失效的计算节点上的任务分配到其他计算节点上重新运行。

但是发明人在研究过程中发现，计算任务已经在失效的计算节点上运行了一段时间，如果分配至新的计算节点重新运行，势必会造成任务的某些阶段被重复在多个计算节点上执行的情况，这样就降低了任务的执行效率，并且浪费了节点的计算资源。

技术实现要素：

本申请所要解决的技术问题是提供一种任务调度方法，用以尽量避免现有技术中任务已经被执行一段时间之后仍然需要在重新分配的计算节点中重新运行的情况，以解决计算任务在重复执行时导致的计算资源浪费的问题。

本申请还提供了任务调度装置及控制节点，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本申请公开了一种任务调度方法，应用于分布式离线计算集群的控制节点中；包括：

响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第一计算参数，所述第一计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的任务进度；

在所述第一计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点；

针对所述各个计算任务的任务进度分别组成的各个进度变化集合，判断所述各个进度变化集合是否表示对应的计算任务执行缓慢；

如果是，则为执行缓慢的计算任务重新分配计算节点；

如果否，则在计算的所述下一个时间采集点到来时，执行所述获取与所述控制节点相连的各个计算节点的第一计算参数的步骤，直至所述各个计算任务执行完毕。

本申请还公开了一种任务调度方法，应用于分布式离线计算集群的控制节点中；该方法包括：

响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第二计算参数，所述第二计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的健康状态；

在所述第二计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点；

判断所述各个计算任务的健康状态是否表示对应的计算任务执行失败，如果是，则为所述执行失败的计算任务重新分配计算节点；

如果否，则在计算的下一个时间采集点到来时，执行所述获取与所述控制节点相连的各个计算节点的第二计算参数的步骤，直至所述各个计算任务执行完毕。

本申请公开了一种任务调度装置，包括：

第一获取模块，用于响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第一计算参数，所述第一计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的任务进 度；

第一计算模块，用于在所述第一计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点；

第一判断模块，用于针对所述各个计算任务的任务进度组成的各个进度变化集合，判断所述各个进度变化集合是否表示对应的计算任务执行缓慢；

第一分配模块，用于在所述判断模块的结果为是的情况下，为执行缓慢的计算任务重新分配计算节点；

第一触发模块，用于在所述判断模块的结果为否的情况下，在所述计算的下一个时间采集点到来时，触发所述获取模块，直至所述各个计算任务执行完毕。

本申请还公开了一种任务调度装置，包括：

第三获取模块，用于响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第二计算参数，所述第二计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的健康状态；

第二计算模块，用于在所述第二计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点；

第二判断模块，用于判断所述各个计算任务的健康状态是否表示对应的计算任务执行失败；

第二分配模块，用于在所述第二判断模块的结果为是的情况下，为所述执行失败的计算任务重新分配计算节点；

第二触发模块，用于在所述第二判断模块的结果为否的情况下，在所述计算的下一个时间采集点到来时，触发所述第二获取模块，直至所述各个计算任务执行完毕。

本申请公开了一种控制节点，包括：前述的任一项任务调度装置。

与现有技术相比，本申请包括以下优点：

在本申请实施例中，针对最近的第一预设采集次数个周期内的计算参数，可以预测得出下一个采集时间点，使得针对计算任务的采集时间点可以动态变化，并且通过对计算任务的任务进度的监控，可以在发现任务执行缓慢的情况下，从距离该任务执行缓慢的最近的时间点来重新运行，而不是重新运行整个任务，从而可以提高任务执行的效率，并且节约了分布式离线计算集群的计算资源。

进一步的，各个计算任务的中间结果的元数据可以同步到程序协调集群中，例如，一个私有的zookeeper上，这样可以很好地保障中间结果的元数据的可靠性和可用性。由于可以在程序协调集群中保留当前在运行的任务的最近N(即第一预设采集次数)个周期的元数据，因此zookeeper上的数据也不会很多，完全符合zookeeper的使用特性。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的任务调度方法实施例1的流程图；

图2是本申请的方法实施例在实际应用中的场景结构图；

图3是本申请的任务调度方法实施例2的流程图；

图4为本申请的任务调度装置实施例1的结构框图；

图5为本申请的任务调度装置实施例2的结构框图。

具体实施方式

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

本申请可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

参考图1，示出了本申请一种任务调度方法实施例1的流程图，本实施例应用于分布式离线计算集群的控制节点中；本实施例可以包括以下步骤：

步骤101：响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第一计算参数，所述第一计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的任务进度。

在本实施例中，如果任务被触发，控制节点在将任务分配至各个计算节点之后，需要每隔固定的时间采集段，从执行任务的各个计算节点采集各个计算节点的第一计算参数，在本实施例中，该第一计算参数可以包括：各个计算节点的初始CPU使用率，各个计算节点的初始内存使用率，以及，各个计算节点所执行的各个计算任务的任务进度。其中，任务进度可以表示当前计算任务执行完成的百分比，例如任务进度为50％，则表示该任务已经执行了一半。

在本步骤中，固定的时间采集段T_m可以采用如下所示的公式(一)计算得到：

T_m＝e^-(aα+bβ) (一)

在公式(一)中，α为计算节点的初始CPU使用率，β为计算节点的初始内存使用率。可见，固定的时间采集段T_m，可以由两方面因素决定：一是计算任务所在的计算节点的性能，二是可以人为设定的变量，a和b。其中，a和b是两个可以人为设定的变量。如公式(一)所示，固定的时间采集段T_m与“初始CPU使用率α和初始内存使用率β”成反比，这是因为当计算节点的CPU使用率和内存使用率提高后，各个任务出错的可能性就会增大，因此固定的采集时间段就应当相应缩短，以免错过最接近的任务恢复点；反之，固定的采集时间段则可以适当延长，以避免对于任务的第一计算参数的不必要的采集。

接着返回图1，进入步骤102：在所述第一计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点。

在本实施例中，步骤101可以执行第一预设采集次数示意的次数，例如，第一预设采集次数为10，则步骤101就可以执行10次，一共得到10个第一计算参数。基于此，步骤102在实际应用中可以包括如下所示的步骤A1～步骤A3：

步骤A1：根据所述初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点的目标CPU使用率和目标内存使用率。

以第一预设采集次数为10为例，当步骤101执行10次之后，就可以得到各个计算节点的10个初始CPU使用率和10个内存使用率，从而组成了各个计算节点的初始CPU使用率序列和初始内存使用率序列，在本实施例中分别表示为：α_x和β_x，其中：α_x＝{α₁ α₂ ... α_n}(0≤n≤N)，β_x＝{β₁ β₂ ... β_n}(0≤n≤N)。

然后，根据α_x和β_x，分别按照如下所示的公式(二)、(三)分别计算出下一个采集点的目标CPU使用率和目标内存使用率α_N+1和β_N+1。

${\mathrm{\α}}_{N+1}=\underset{n=0}{\overset{N}{\mathrm{\Σ}}}{\mathrm{\α}}_n\×2^{n-N}$ 公式(二)

${\mathrm{\β}}_{N+1}=\underset{n=0}{\overset{N}{\mathrm{\Σ}}}{\mathrm{\β}}_n\×2^{n-N}$ 公式(三)

其中，在公式(二)和公式(三)中分别采用了折半衰减原理来对前10次采集的第一计算参数加上权值，主要是为了区别各个时间采集点采集的第一计算参数对预测数据的影响，即：每过一个固定的时间采集段，采集的第一计算参数对预测数据的影响系数衰减为之前的一半。

步骤A2：依据所述目标CPU使用率和目标内存使用率计算下一次采集间隔。

根据步骤A1中计算的下一个采集点的CPU和内存使用率α_N+1和β_N+1，再次依据公式(一)计算出下一个采集间隔T_N+1。

步骤A3：依据所述下一次采集间隔和当前时间计算得到下一个时间采集点。

根据计算出的采集间隔T_N+1和当前采集时间t_o，按照如下所示的公式(四)计算出下一个采集时间点t_o′：

t_o′＝t_o+T_N+1 公式(四)

其中，以第一预设采集次数为10为例，当前采集时间t_o为第10次采集第一计算参数的系统时间。

步骤103：针对所述各个计算任务的任务进度分别组成的各个进度变化集合，判断所述各个进度变化集合是否表示对应的计算任务执行缓慢，果是，则进入步骤105，如果否，则进入步骤104。

根据步骤101中采集到的各个计算任务的任务进度P_i，可以得到各个计算任务的进度变化集合可表示为如下所示的公式(五)：

$P_{{\mathrm{\Δ}}_i}=\{P_{\mathrm{ij}}-P_{\mathrm{ij}-1}|1\≤j\≤M_P\}$ 公式(五)

在公式(五)中，计算任务的进度变化“P_Δi”就等于当前任务进度“P_ij”与上一个任务进度“P_ij-1”之差，“M_P”为计算任务的进度变化的最大范围，可以设置为固定的时间采集段的两倍。当然，本领域技术人员也可以根据需要设置为其他数值。

那么，判断各个进度变化集合是否表示对应的计算任务执行缓慢，可以通过判断各个进度变化集合中计算任务的变化趋势值是否小于预设 的任务缓慢阈值来实现。例如，当判断得到任务进度变化集合PΔ_i中的变化程度都趋近于0的结果的情况下，说明该计算节点负载过高或者任务变慢，即，该进度变化集合表示计算任务执行缓慢。

步骤104：获取与所述控制节点相连的各个计算节点的第一计算参数，并计算下一个时间采集点，直至所述各个计算任务执行完毕。

而如果计算任务并没有执行缓慢的情况出现，则可以在计算的下一个时间采集点到来的时候，获取与控制节点相连的各个计算节点的第一计算参数，重新计算下下一个时间采集点，直至各个计算任务执行完毕。需要说明的是，在本实施例中，以第一预设采集次数为10次为例，那么每次就采用最近前10次所获取到的第二计算参数计算下一个时间采集点。

步骤105：为执行缓慢的计算任务重新分配计算节点。

在某个计算任务执行缓慢的时候，可能说明执行该计算任务的计算节点已经达到饱和状态，或者计算节点出现了异常情况等，在这种情况下，控制节点可以在该计算任务所属的计算节点中将该计算任务杀死(kill)，然后为其分配新的计算节点。

其中，为执行缓慢的计算任务重新分配计算节点，具体可以包括如下所示的步骤B1～步骤B3：

步骤B1：在执行缓慢的计算任务归属的计算节点上杀死所述执行缓慢的计算任务。

首先，在执行缓慢的计算任务所属的计算节点上，将已经执行缓慢的计算任务kill掉。

步骤B2：将执行缓慢的计算任务依次加入预先设置的重试队列。

再将执行缓慢的计算任务加入至预先设置的一个重试队列中，以便控制节点后续从该充实队列中按照时间顺序读取计算任务。

步骤B3：从所述重试队列中按照时间顺序获取执行缓慢的计算任务，并为获取到的计算任务依次分配其他计算节点。

然后，控制节点再从重试队列中按照时间顺序获取执行缓慢的计算任务，并依次为其重新分配其他计算节点。

在实际应用中，步骤101中获取到的第一计算参数还可以包括：各个计算任务的中间结果的元数据。其中，中间结果的元数据为执行计算任务过程中产生的中间数据，用来表示计算任务的执行过程。例如，假设计算任务为读取一张EXCEL表格，那么中间结果的元数据可能是该EXCEL表格的存储位置，当前已经读取至该EXCEL表格的哪一行那一列，以及，读取到的结果的存储位置，等等。

那么，在本实施例中，在获取到各个计算任务的中间结果的元数据之后，还可以包括：

步骤100：将所述各个计算任务的中间结果的元数据存储至程序协调集群中。

可以将中间步骤获取到的中间结果的元数据D_i存储至程序协调集群中，例如，可以存储至zookeeper上。因为程序协调集群可以与控制节点和计算节点相互独立，因此，一旦某个计算任务执行缓慢或者执行失败，就可以参考中间结果的元数据来从距离任务失败的最接近的时间点开始继续执行，而不是从头再执行计算任务，相对更为节省分布式集群的计算资源，还能为提高任务执行的效率。

可以理解的是，在程序协调集群zookeeper中可以仅仅保留当前在运行的任务的最近N(即第一预设采集次数)个周期的元数据(计算下一个时间采集点所需)，因此zookeeper上的数据也不会很多，完全符合zookeeper的使用特性。

那么，在所述为执行缓慢的计算任务重新分配计算节点之后，还可以包括：

步骤106：从所述程序协调集群中获取执行缓慢的计算任务的中间结果元数据，并将所述中间结果的元数据发送至重新分配的计算节点，以触发所述重新分配的计算节点依据所述中间结果的元数据继续执行所述计算任务。

如果出现了为执行缓慢的计算任务重新分配计算节点的情况，则控制节点可以接着从程序协调集群中获取到执行缓慢的计算任务的中间结果 元数据，并将所述中间结果的元数据发送至重新分配的计算节点，以触发所述重新分配的计算节点依据所述中间结果的元数据继续执行所述计算任务。

可以理解的是，在计算任务执行完毕之后，才可以在程序协调集群例如zookeeper中删除该计算任务的中间结果的元数据，以保证程序协调集群的高性能。

参考图2所示，为本申请方法实施例在实际应用中的场景架构图。控制节点是分布式离线计算集群中负责分配任务的节点，当各种任务被提交到控制节点，控制节点可以根据任务所需的时间和各个计算节点的当前状态等，来将任务分配给合适的计算节点去执行。

可见，在本申请实施例中，针对最近的第一预设采集次数个周期内的计算参数，可以预测得出下一个采集时间点，使得针对计算任务的采集时间点可以动态变化，并且通过对计算任务的任务进度的监控，可以在发现任务执行缓慢的情况下，从距离该任务执行缓慢的最近的时间点来重新运行，而不是重新运行整个任务，从而可以提高任务执行的效率，并且节约了分布式离线计算集群的计算资源。

参考图3所示，示出了本申请一种任务调度方法实施例2的流程图，本实施例应用于分布式离线计算集群的控制节点中；本实施例可以包括以下步骤：

步骤301：响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第二计算参数，所述第二计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的健康状态。

在本实施例中，与实施例1的区别之处在于，本实施例中，获取到的第二计算参数除了各个计算节点的初始CPU使用率和初始内存使用率之外，还获取到的是各个计算任务的健康状态H_i。其中，该健康状态H_i用于表示计算任务是否在正常执行，例如可以采用0或1来表示，当健康状态的值为0时表示该计算任务的执行状态为不健康，当健康状态的值为1时表示该计算任务的执行状态为健康。

步骤302：在所述第二计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点。

本步骤的执行过程可以和步骤102相同，在此不再赘述。

步骤303：判断所述各个计算任务的健康状态是否表示对应的计算任务执行失败，如果是，则进入步骤305，如果否，则进入步骤304。

在本实施例中，可以根据各个计算任务的健康状态来判断，是否对应的计算任务执行失败。例如，如果某个计算任务的健康状态持续为0，则说明该计算任务在其当前所属的计算节点上执行失败。

步骤304：在计算的下一个时间采集点到来时，执行所述获取与所述控制节点相连的各个计算节点的第二计算参数的步骤，直至所述各个计算任务执行完毕。

如果某个计算任务没有执行失败，则可以在计算的下一个时间采集点到来时，接着获取与所述控制节点相连的各个计算节点的第二计算参数，进而根据当前获取到的第二计算参数来计算下下一个时间采集点。直至所述各个计算任务执行完毕。需要说明的是，在本实施例中，以第一预设采集次数为10次为例，那么每次就采用最近前10次所获取到的第二计算参数计算下一个时间采集点。

步骤305：所述执行失败的计算任务重新分配计算节点。

而如果任务执行失败，则也需要为执行失败的计算任务重新分配计算节点，具体过程可以参考步骤105的详细介绍，在此不再赘述。

在本实施例中，也可以在一开始判断得到计算任务执行失败的情况下，先不为该执行失败的计算任务重新分配计算节点，那么，在为执行失败的计算任务重新分配计算节点之前，还包括：

步骤C1：按照所述固定的时间采集段，继续获取所述执行失败的计算任务的第二计算参数。

当在某个时间点发现计算任务失败后，就放弃计算下一个时间采集点，而是又回归到固定的时间采集端，再持续获取计算任务的第二计算 参数。

步骤C2：在所述第二计算参数继续获取了第二预设采集次数之后，根据各个计算任务的健康状态判断所述执行失败的计算任务是否确实失败，如果否，则进入步骤C3，如果是，则进入步骤C4。

持续监测M_H(即第二预设采集次数)个周期后，再根据各个计算任务的健康状态判断所述执行失败的计算任务是否确实失败，如果发现任务健康状态都没有好转(例如，健康状态持续为零)，就认为该计算任务真正失败，需要说明的是，M_H可以为确认任务失败的最大检测次数，例如，可以设置为第一预设采集次数的一半，例如5次。

步骤C3：执行参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点的步骤。

如果计算任务不是真正失败，例如监控状态从0变为1，则可以认为该计算任务已经重新正常执行，在这种情况下，可以执行计算下一个时间采集点的步骤。

步骤C4：执行所述执行失败的计算任务重新分配计算节点的步骤。

而在计算任务确实已经失败的情况下，可以再为执行失败的计算任务重新分配计算节点。

在本实施例中，针对最近的第一预设采集次数个周期内的计算参数，可以预测得出下一个采集时间点，使得针对计算任务的采集时间点可以动态变化，并且通过对计算任务的健康状态的监控，可以在发现任务执行失败的情况下，从距离该任务执行失败的最近的时间点来重新运行，而不是重新运行整个任务，从而可以提高任务执行的效率，并且节约了分布式离线计算集群的计算资源。

对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属 于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

与上述本申请一种任务调度方法实施例1所提供的方法相对应，参见图4，本申请还提供了一种任务调度装置实施例1，本实施例的装置可以集成在控制节点上，在本实施例中，该装置可以包括：

第一获取模块401，用于响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第一计算参数，所述第一计算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的任务进度。

第一计算模块402，用于在所述第一计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点。

其中，所述第一计算模块402可以包括：

第一计算子模块，用于根据所述初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点的目标CPU使用率和目标内存使用率；第二计算子模块，用于依据所述目标CPU使用率和目标内存使用率计算下一次采集间隔；以及，第三计算子模块，用于依据所述下一次采集间隔和当前时间计算得到下一个时间采集点。

第一判断模块403，用于针对所述各个计算任务的任务进度组成的各个进度变化集合，判断所述各个进度变化集合是否表示对应的计算任务执行缓慢。

其中，所述第一判断模块403具体可以用于：判断所述进度变化集合中计算任务的变化趋势值是否小于预设的任务失败阈值。

第一分配模块404，用于在所述判断模块的结果为是的情况下，为执行缓慢的计算任务重新分配计算节点。

其中，所述第一分配模块404具体可以包括：

删除子模块，用于在所述执行缓慢的计算任务归属的计算节点上杀死所述执行缓慢的计算任务；加入子模块，用于将所述执行缓慢的计算任 务加入预先设置的重试队列；获取子模块，用于从所述重试队列中按照时间顺序获取执行缓慢的计算任务；以及，分配子模块，用于为获取到的计算任务依次分配其他计算节点。

第一触发模块405，用于在所述判断模块的结果为否的情况下，在所述计算的下一个时间采集点到来时，触发所述获取模块，直至所述各个计算任务执行完毕。

在实际应用中，第一计算参数还可以包括：各个计算任务的中间结果的元数据；

则本实施例所述的装置还可以包括：

存储模块，用于将所述中间结果的元数据存储至程序协调集群zookeeper中；

以及，

第二获取模块，用于从所述程序协调集群中获取执行缓慢的计算任务的中间结果元数据；

发送模块，用于将所述中间结果的元数据发送至重新分配的计算节点，以触发所述重新分配的计算节点依据所述中间结果的元数据继续执行所述计算任务。

可见，在本申请实施例中，针对最近的第一预设采集次数个周期内的计算参数，可以预测得出下一个采集时间点，使得针对计算任务的采集时间点可以动态变化，并且通过对计算任务的任务进度的监控，可以在发现任务执行缓慢的情况下，从距离该任务执行缓慢的最近的时间点来重新运行，而不是重新运行整个任务，从而可以提高任务执行的效率，并且节约了分布式离线计算集群的计算资源。

与上述本申请一种任务调度方法实施例2所提供的方法相对应，参见图5，本申请还提供了一种任务调度装置实施例2，本实施例的装置可以集成在控制节点上，在本实施例中，该装置可以包括：

第三获取模块501，用于响应于任务的触发，每隔固定的时间采集段，获取与所述控制节点相连的各个计算节点的第二计算参数，所述第二计 算参数包括：初始CPU使用率、初始内存使用率和各个计算任务的健康状态。

第二计算模块502，用于在所述第二计算参数获取了第一预设采集次数之后，参考所述各个计算节点的初始CPU使用率和初始内存使用率分别组成的初始CPU使用率序列和初始内存使用率序列，计算下一个时间采集点。

第二判断模块503，用于判断所述各个计算任务的健康状态是否表示对应的计算任务执行失败。

第二分配模块504，用于在所述第二判断模块的结果为是的情况下，为所述执行失败的计算任务重新分配计算节点。

第二触发模块505，用于在所述第二判断模块的结果为否的情况下，在所述计算的下一个时间采集点到来时，触发所述第二获取模块，直至所述各个计算任务执行完毕。

在实际应用中，本实施例所述的装置还可以包括：

第四获取模块，用于按照所述固定的时间采集段，继续获取预设个数的所述执行失败的计算任务的第二计算参数；第三判断模块，用于在所述第二计算参数继续获取了第二预设采集次数之后，根据所述预设个数的健康状态判断所述执行失败的计算任务是否确实失败；第三触发模块，用于在所述判断模块的结果为否的情况下，触发所述计算模块；以及，第三分配模块，用于在所述判断模块的结果为是的情况下，触发所述分配模块。

在本实施例中，针对最近的第一预设采集次数个周期内的计算参数，可以预测得出下一个采集时间点，使得针对计算任务的采集时间点可以动态变化，并且通过对计算任务的健康状态的监控，可以在发现任务执行失败的情况下，从距离该任务执行失败的最近的时间点来重新运行，而不是重新运行整个任务，从而可以提高任务执行的效率，并且节约了分布式离线计算集群的计算资源。

本申请实施例还提供了一种控制节点，该控制节点可以包括装置实 施例1或装置实施例2所述的任务调度装置。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的任务调度方法、装置及控制节点进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。