CN108153583B - 任务分配方法及装置、实时计算框架系统 - Google Patents

Abstract

本申请提供了一种任务分配方法，该方法应用在实时计算框架系统的任务调度模块上，实时计算框架系统内还包括任务生成模块及执行节点，任务生成模块可以生成多个任务，任务调度模块获得任务生成模块所切分的多个任务后，将多个任务分配给执行节点，且分配的任务个数大于执行节点包含的处理核的个数。可见，相较于现有技术中为每个处理核分配一个任务而言，本申请提供的任务分配方法在每个处理周期内为处理核分配了更多的任务，从而延长了处理核的处理时长，进而提高了处理资源的使用率。另外，本申请还提供了一种任务分配装置及实时计算框架系统，用以保证所述方法在实际中的应用及实现。

Description

任务分配方法及装置、实时计算框架系统

技术领域

本申请涉及任务调度技术领域，更具体地，涉及任务分配方法及装置、实时计算框架系统。

背景技术

实时计算框架系统也可以称为流式处理框架，基本的工作原理是连续地接收数据流，以时间片(秒级)为单位拆分数据流，然后以类似批处理的方式处理每个时间片数据。

实时计算框架系统的一种具体用例为Spark Streaming框架系统，可以处理流式类型的业务数据。例如，在互联网应用中，网站的访问情况是实时变化的，可以将网站的访问数据作为业务数据，连续地输入至Spark Streaming框架内，以统计网站在各个时刻的访问量。

现有的实时计算框架系统，CPU的利用率较低。

发明内容

有鉴于此，本申请提供了一种任务分配方法，用于提高实时计算框架系统内处理核的利用率。

为实现所述目的，本申请提供的技术方案如下：

第一方面，本申请提供了一种任务分配方法，应用于实时计算框架系统中的任务调度模块，所述实时计算框架系统中还包括任务生成模块及执行节点，所述执行节点内包括一个或多个处理核，该方法包括：

获得任务生成模块所切分的多个任务；

将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务，以减少空载时间。

第二方面，本申请提供了一种任务分配装置，应用于实时计算框架系统，所述实时计算框架系统中还包括任务生成模块及执行节点，所述执行节点内包括一个或多个处理核，该装置包括：

任务获得单元，用于获得任务生成模块所切分的多个任务；

任务分配单元，用于将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务，以减少空载时间。

第三方面，本申请提供了一种实时计算框架系统，包括：任务生成模块、任务调度模块、多个执行节点；

所述任务生成模块，用于生成多个数据接收线程；获得所述执行节点上的待处理数据，并将所述待处理数据切分为多个任务；

所述任务调度模块，用于获得所述任务生成模块生成的多个数据接收线程；将所述多个数据接收线程近似平均地分配给各个所述执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内；获得所述任务生成模块所切分的多个任务；以及将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务；

所述执行节点，包含一个或多个处理核，用于运行所分配到的数据接收线程，以接收待处理数据；以及由所述处理核对任务进行处理。

由以上技术方案可知，本实施例提供了一种任务分配方法，该方法应用在实时计算框架系统的任务调度模块上，实时计算框架系统内还包括任务生成模块及执行节点，任务生成模块可以生成多个任务，任务调度模块获得任务生成模块所切分的多个任务后，将多个任务分配给执行节点，且分配的任务个数大于执行节点包含的处理核的个数。可见，相较于现有技术中为每个处理核分配一个任务而言，本申请提供的任务分配方法为处理核分配了更多的任务，从而延长了处理核的处理时长，进而提高了处理资源的使用率。

附图说明

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

图1为现有的实时计算框架系统处理任务的示例图；

图2为现有的处理周期内数据接收线程Receiver与处理线程Process Thread的运行状态示意图；

图3为本申请提供的任务分配方法实施例1的流程图；

图4为本申请提供的处理周期内数据接收线程Receiver与处理线程ProcessThread的运行状态示意图；

图5为现有的任务调度模块分配数据接收线程的示例图；

图6为本申请提供的任务调度模块分配数据接收线程的示例图；

图7A为本申请提供的实时计算框架系统的一种处理流程图；

图7B为本申请提供的实时计算框架系统的另一种处理流程图；

图8为本申请提供的任务分配装置实施例1的结构示意图；

图9为本申请提供的任务分配装置实施例2的结构示意图。

具体实施方式

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

Spark Streaming框架是实时计算框架系统的一个具体示例，本申请改进的对象不仅是Spark Streaming框架，而是实时计算这一类型的框架。为了便于理解，首先对实时计算框架系统这种类型的计算框架的进行简要说明。

实时计算框架系统不仅需要接收数据，还需要处理数据。

在实时计算框架系统内部，CPU(Central Processing Unit，中央处理单元)运行有处理线程，以实现对接收到的数据的处理。可以理解的是，只有数据的接收过程与数据的处理过程相适配，才能保证数据的实时计算。

然而，目前的实时计算框架系统中，接收线程连续不断地接收数据，处理线程常处于负荷状态或空闲状态。处理线程处于空闲状态时，导致CPU的利用率较低。

针对以上问题，现有技术提供了两种解决方案。

其一，资源的弹性处理。在实时计算过程中，若处理资源不足，则实时计算框架系统向资源管理系统申请额外的处理资源，来弥补处理能力的不足。若处理资源过剩，则通知资源管理系统回收冗余的处理资源。

但是，处理资源的回收是直接回收，由于处理资源上可能存储有处理后的缓存数据，资源回收导致这部分数据丢失，需要重新处理数据，数据的稳定性较低。并且，该方案也会降低数据的处理效率。

其二，背压(Back-Pressure)方式。若数据流的流入速度超过处理资源的处理能力时，则限制数据流的流入速度，以减少数据的处理延迟。然而，该种处理方式只能解决处理资源不足即处理线程处于负荷状态的问题，却不能解决处理资源过剩即处理线程处于空闲状态的问题。

可见，以上两种方案均不能有效解决CPU利用率低的问题。对此，发明人对导致CPU利用率低的原因进行了深入的研究，并根据研究结果提出了相应的解决方案。

发明人对实时计算框架系统的数据处理过程进行研究后发现，在实时计算框架系统中，数据被切分为小的单元，多个小单元的数据作为同一批次的数据提交给处理线程进行处理。实现该流程的结构如图1所示。

见图1，实时计算框架系统包括任务生成模块、任务调度模块及多个执行节点。其中，任务生成模块用于将待处理的数据切分为多个任务，任务调度模块将各个任务分配给执行节点，执行节点包括多个处理核如CPU，处理核用于处理执行节点接收到的任务。

数据接收线程(或称为数据接收器)连续地接收数据，因此，任务生成模块在连续不断地将数据切分为任务。但是，处理核并非连续地而是按照一定的周期处理数据。因此，任务调度模块按照处理周期为处理核分配任务。

发明人进一步发现，在每个处理周期内，任务调度模块为处理核分配的任务数量与执行节点内处理核的个数相同。例如，某执行节点内包含4个处理核，则每个处理周期内，任务调度模块为该执行节点分配4个任务。这样，在单个处理周期内，每个任务独占一个处理核，处理核仅用于处理此任务。

但是，在一个处理周期内，处理核处理完任务后，便进入空闲状态。见图2，其示出了数据接收线程Receiver与处理线程Process Thread的现有处理方式。如图2所示，批次(Batch)t、批次(Batch)t+1、批次(Batch)t+2表示三个处理周期，第二行中实线对应的状态为process(处理中)，状态process表示处理线程Process Thread在处理数据，虚线对应的状态为wait(等待中)，状态wait表示处理线程Process Thread处于空闲状态。

从图2中可以看出，任意一个处理周期内，数据接收线程Receiver连续不断地接收数据，然而，在处理线程Process Thread执行完处理工作后，处理核便进入空载状态，且处理效率越高，则空载状态的时长越长，也即处理核的利用率越低。

发明人经过上述研究，发现了导致处理核利用率低的原因，并针对性地提出了一种任务分配方法，以提高处理核的使用率。

见图3，其示出了本申请提供的任务分配方法实施例1的流程，该任务分配方法应用在任务调度模块上，也就是说由任务调度模块执行该任务分配方法实施例1的流程。如图3所示，该流程具体包括步骤301及S302。

S301：获得任务生成模块所切分的多个任务。

其中，待处理的数据输入任务生成模块后，由任务生成模块将数据切分为多个数据单元，一个数据单元即为一个任务。切分后的任务需要由任务调度模块进行调度分配。

S302：将多个任务分配给执行节点，其中为每个执行节点分配的任务个数大于执行节点包含的处理核的个数。

前已述及，执行节点包含一个或多个处理核，处理核可以是CPU，用于运行处理线程以处理各个任务。每个执行节点包含的处理核的个数可以相同也可以不同。

任务调度模块为每个执行节点分配的任务个数，需要大于该执行节点所包含的处理核的个数，且优选为执行节点内包含的处理核的个数的N倍，N为大于等于2的整数。在执行节点内部，会将获得的任务平均或近似平均地分配给各个处理核。这样，处理核处理的任务个数不止为1。相较于现有处理核而言，本申请中的处理核在每个处理周期内，处理的任务个数更多。

如图4所示，相较于图2中处理线程Process Thread在一个处理周期内的实线，图4中的实线更长，这就表示处理核的处理时间变长，也即表示处理核的使用率更高。需要说明的是，图示4中英文单词表示的含义参见有关图2的说明，此处并不赘述。

在实际应用中，本步骤的具体实现方式可以包括以下两种。

第一种实现方式，可以为分配参数预先设置参数值，任务调度模块根据该预设的参数值，将多个任务分配给执行节点。

具体地，实时计算框架系统内设置有分配参数，分配参数的参数值表示每个处理核可处理的任务个数。在实时计算框架系统处理数据前，预先设置分配参数的参数值。由于现有技术中在一个处理周期内，处理核只能处理一个任务，导致了处理核的空载时间较长，因此，为了解决该问题，设置的参数值需要大于1。这样，任务调度模块在任务分配时，便可以根据参数值及执行节点包含的处理核个数，确定出分配给执行节点的任务个数。例如，某执行节点包含4个处理核，分配参数的参数值为2，则任务调度模块确定出分配给该执行节点的任务个数为4*2即8个。

当然，分配参数的参数值可以并非局限于上述形式，还可以是执行节点可获得的任务个数，同样可以理解的是，该个数需要大于执行节点内包括的处理核的个数。这样，任务调度模块在分配任务时，便可以直接根据该参数值，确定出分配给执行节点的任务个数。

第二种实现方式，任务调度模块监测执行节点的运行状态，根据运行状态确定单个处理核在一个处理周期内能够处理的任务的最大值，进而将最大值对应个数的任务分配给执行节点。

其中，运行状态可以反映执行节点当前处理任务的能力，通过监测到的运行状态，便可以计算或统计出单个处理核在一个处理周期内能够处理的任务最大值。

执行节点包含处理核，在一个示例中，监测的运行状态是处理核在一个处理周期内处理任务的时长，该时长可以称为处理时长，进而将处理周期的整个时长除以处理核的处理时长后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。例如，处理周期的整个时长为1，处理核的处理时长为0.4，将1除以0.4后取整为2，进而确定单个处理核在一个处理周期内能够处理的任务的最大值为2。

实际应用中，不同类型的数据，划分为任务的数据量可能不同，从而处理核在一个处理周期内可以处理的任务数量也可能不同。或者，处理周期的时长也可能根据实际情况而设置为其他值，因此，在另一示例中，监测的运行状态可以包括处理周期的时长、任务的数据量大小及处理核的处理效率(单位时间内能处理的任务总数据量)。将处理周期的时长除以任务的数据量大小及处理核的处理效率后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

以上两种实现方式各有优势，第一种实现方式只需设置一次即可，简单且容易实现，第二种实现方式需要监测数据量的大小、处理周期的时长等参数，根据参数值的大小计算出分配的任务的个数，因此该种实现方式更加准确。

需要说明的是，不论使用上述何种实现方式确定分配的任务的个数，都需要注意的是，处理核处理所分配的任务的时长不能超过处理周期的时长。也就是说，需要保证在每个处理周期内处理核至少有一定时长的空载，而不能出现处理核在某个处理周期内未完成与该处理周期内的任务，否则会出现任务的堆积，反而影响任务的处理效率。

通过以上两种方式可以看出，步骤S302在将多个任务分配给执行节点后，要使得执行节点内每个处理核均对应于处理多个任务，才能保证执行节点内每个处理核都可以达到减少空载时间的目的。

由以上的技术方案可知，相对于现有技术，本申请提供的任务分配方法在每个处理周期内为处理核分配了更多的任务，从而延长了处理核的处理时长，提高了处理资源的使用率。另外，从待处理数据角度而言，单个待处理数据所需要的处理核数目变得更少，也使得处理核可以同时支持更多的待处理数据。

发明人在对实时计算框架系统的研究中还发现，实时计算框架系统处理数据的效率较低，主要原因是实时计算框架系统存在数据迁移的情况，即：任务被分配给某个执行节点后，若该执行节点待处理的任务数量过多，则某些任务会被迁移至其他空闲的执行节点进行处理，这样，任务的本地执行率较低，从而导致数据的处理效率较低，并且数据迁移也需要一定的数据传输成本，导致通信资源的浪费。

以上任务分配方法实施例1可以在一定程度上解决这个问题。在任务分配方法实施例1中，数据接收线程(即上述接收线程)被分配至执行节点后，由于执行节点上的处理核运行数据接收线程，以接收数据。接收到的数据由任务生成模块切分为任务，再由任务调度模块将各个任务重新分配给执行节点，由执行节点内的处理核来处理各个任务。

需要说明的是，该任务分配方法实施例1中，任务调度模块分为多个处理周期向执行节点分配任务，并且在一个处理周期内，为执行节点分配的任务个数大于该执行节点内处理核的个数。这样，执行节点内的处理核在一个处理周期内可以处理的数据变多，从而执行节点所接收到的数据可以在该执行节点本地完成处理，并不需要将该执行节点上的数据迁移至其他执行节点进行处理，进而在一定程度上解决了数据迁移导致的数据处理效率较低的问题。

发明人进一步研究数据迁移的原因后发现，实时计算框架系统在启动阶段，会生成数据接收线程。数据接收线程，在实时计算框架系统内，数据接收线程是一种特殊类型的任务，既然是任务，那么任务调度模块便会将数据接收线程分配给执行节点，由该执行节点实现数据接收的工作。

发明人在研究中重要的发现是，数据接收线程是被随机分配给各个执行节点的。如图5所示，任务调度模块将数据接收线程随机分配至各个执行节点上，因此，容易出现各个执行节点上数据接收线程的分配数量不均等的情况，从而导致执行节点间接收到的数据不均等。若有些执行节点上的数据较多自身处理进度较慢，则这些执行节点上积压的数据会被迁移至其他执行节点处理，进而导致数据的处理效率较低。

可见，在面对数据处理效率较低的问题时，发明人经过深入细致的分析，得出了问题产生的一个原因是数据接收线程被随机分配。因此，本申请提供了一种任务分配方法，以达到如图6所示的近似平均地分配数据接收线程的效果。

该任务分配方法同样应用在任务调度模块上，在上述任务分配方法实施例1的基础上，该任务分配方法还可以包括如下步骤A1及A2。

A1：获得多个数据接收线程。

其中，实时计算框架系统中会创建数据接收线程，数据接收线程执行接收待处理数据的工作。接收到的数据按照上述任务分配方法实施例1的流程由处理核进行处理。

任务调度模块获得多个数据接收线程的实现方式可以包括多种，本申请提供如下两种。

第一种，判断实时计算框架系统是否处于启动阶段，若是，则将启动阶段任务生成模块所生成的任务确定为数据接收线程。

数据接收线程一般是在实时计算框架系统启动阶段生成，且正常情况下，实时计算框架系统的启动阶段必定会生成数据接收线程。数据接收线程是一种实时计算框架系统内的一种特殊类型的任务，该任务由任务生成模块在实时计算框架系统启动阶段生成的。可以理解的是，由于实时计算框架系统在启动阶段并未进入数据处理阶段，该阶段内任务生成模块生成的任务并非切分待处理数据获得的任务。因此，可以将启动阶段，任务生成模块生成的任务确定为数据接收线程。

实时计算框架系统在启动阶段时，会执行注册步骤：即实时计算框架系统向资源管理系统申请资源，资源包括执行节点。资源管理系统为实时计算框架系统分配执行节点后，实时计算框架系统会将执行节点注册到主进程如Drive进程中。在完成注册步骤后，便通知任务生成模块便可以生成数据接收线程，以开始接收待处理的数据。

因此，本实现方式可以判断任务生成模块是否接收到注册完成的通知，若是，则将任务生成模块所生成的任务确定为数据接收线程。

第二种，并不判断实时计算框架系统是否处在启动阶段，而是在获得任务生成模块生成的任务后，将任务中具有预设属性特征的任务确定为数据接收线程。其中，所述预设属性特征为数据接收线程具有的属性特征。

虽然，数据接收线程与数据生成的任务均是任务，但两者类型不同，各自具有不同的属性特征。因此，在获得任务生成模块生成的多个任务后，根据数据接收线程具有的属性特征，在该多个任务中查找数据接收线程。

以上两种方式均可以确定出数据接收线程，且在确定出的数据接收线程为多个的情况下，按照步骤A2的方式将多个数据接收线程分配给各个执行节点。

A2：将多个数据接收线程近似平均地分配给各个所述执行节点；其中，近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内。

需要说明的是，近似平均是一种调度分配策略，使用该策略进行分配首要想实现的是完全平均的目的，但是，在具体实施中，会出现生成的数据接收任务并不能完全平均分配的情况，因此，只要达到每个执行节点分配得到的数据接收任务大致相同的效果即可。

衡量以上效果的一种具体方式是，各个执行节点分得的数据接收线程的个数差值在预设差值阈值范围内。该预设差值阈值可以是根据实时计算框架系统的具体性能而设置的数值，本申请并不做具体限定。

例如，假设获得的数据接收线程Receiver为8个，实时计算框架系统内的执行节点为4个，则为每个执行节点分配2个数据接收线程Receiver。当然，若获得的数据接收线程Receiver为9个，实时计算框架系统内的执行节点为4个，则可以为其中某执行节点分配3个数据接收线程Receiver，为其他每个执行节点各自分配2个数据接收线程Receiver。

为了实现上述近似平均的调度策略，具体地，可以首先将数据接收线程个数除以执行节点个数后取整，以得到为每个执行节点平均分配的数据接收线程的个数，若有多余的数据接收线程，再则将该数据接收线程随机分配给各个执行节点。

前已述及，发明人通过研究后发现，目前的实时计算框架系统内，数据接收线程是被随机分配的。本申请中，数据接收线程近似平均地分配在各个执行节点上，这样，数据接收线程接收到的数据便可以均匀地分配到各个执行节点上，从而减少了数据迁移的情况，提高了数据的处理效率。同时，也降低了数据迁移造成的通信成本。

需要说明的是数据接收线程分配到执行节点后，执行节点上包括多个处理核，数据接收线程可以运行在某个(些)处理核上，以使该处理核接收数据。接收到的数据可以首先被分配在本执行节点的其他处理核上进行处理。可见，若有处理核运行数据接收线程，则执行节点内的处理核并不能全部用来处理数据生成的任务，因此，可以将执行节点内的处理核分为两类，将运行数据接收线程的处理核确定为数据接收核，剩余的是数据处理核。数据接收核与数据处理核的个数可以是预先设置的数值。上述任务分配方法实施例1中，执行节点的处理核指的是数据处理核。

数据接收线程分配到执行节点后，任务调度模块触发每个所述执行节点分别运行各自所分配到的数据接收线程，使得各个所述执行节点接收到的数据近似平均，以减少数据迁移。需要说明的是，任务调度模块对执行节点的触发动作可以不是独立的动作，而与分配动作合并。即任务调度模块向执行节点分配数据接收线程后，也表示对执行节点执行了触发动作，从而执行节点便可以运行数据接收线程。

需要说明的是，本申请并不局限应用于Spark Streaming框架，还可以是其他实时计算框架系统。

本申请还提供了一种实时计算框架系统，该实时计算框架系统内包含任务生成模块、任务调度模块及多个执行节点。实时计算框架系统执行的实时计算流程的如图7A或7B所示。

见图7A，实时计算的一种流程可以包括如下步骤S701～S708。

S701：任务调度模块获得任务生成模块生成的多个数据接收线程。

S702：任务调度模块将多个数据接收线程近似平均地分配给各个执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内。

S703：执行节点运行数据接收线程，以接收待处理数据。

其中，执行节点内包含多个处理核，可以在该多个处理核中选择某个或某些处理核来运行数据接收线程，以实现数据接收的目的。为了便于与以下进行数据接收的处理核进行区分，可以将此处理核称为数据接收核。

S704：任务生成模块获得各个执行节点上的待处理数据。

S705：任务生成模块将待处理数据切分为多个任务。

S706：任务调度模块获得任务生成模块所切分的多个任务。

S707：任务调度模块在各个处理周期内，将多个任务分配给对应的执行节点，其中为所述执行节点分配的任务个数大于所述执行节点包含的处理核的个数。

其中，为执行节点所分配的多个任务，可以是由该执行节点所接收到的待处理数据切分后的任务中的多个任务。由于待处理数据切分后可以得到多个任务，该多个任务可以按照处理周期一批一批地分配给执行节点进行处理。每批分配的多个任务需要满足条件，即使得执行节点内的每个处理核均对应于处理多个任务。

需要说明的是，在执行节点为多个的情况下，每个执行节点包含的处理核的个数可以相同也可以不同，为每个执行节点分配的任务个数大于该执行节点包含的处理核的个数。

S708：执行节点内的处理核对任务进行处理。

其中，执行节点内的处理核除了运行数据接收线程以外，其他的处理核用来处理数据接收线程接收到的数据，该些处理处理核可以称为数据处理核。数据被任务生成模块切分为任务，因此，数据处理核处理接收到的任务即可。

需要说明的是，该流程中的其他步骤的说明可以参见上述任务分配方法中的说明，此处并不赘述。

图示中每个执行节点均会执行步骤S702～S708，需要说明的是，各个执行节点的执行并不局限于串行执行，该多个执行节点可以按照自己的执行流程并行执行。

见图7B，实时计算的另一种流程可以包括如下步骤S801～S808。该流程与上述图7A所示的流程不同之处为将步骤S707中任务调度模块的调度步骤替换为步骤S807，其他过程相同，因此，以下仅说明与图7A不同之处，其他过程可以参见上述说明，以下并不赘述。

S807：任务调度模块在各个处理周期内，将多个任务分配给执行节点。

其中，为所述执行节点分配的任务个数大于所述执行节点包含的处理核的个数。并且，并非按照执行节点与任务的对应关系进行分配，即为执行节点分配的任务并未仅限于由该执行节点所接收到的数据切分后的任务。任务调度模块在分配时，可以先按照执行节点与任务的对应关系进行分配，若发现为某执行节点出现超过预设数量的任务并未被及时处理，则可以将该执行节点上的任务分配给空闲的执行节点。这样，可以进一步提高执行节点上处理核的利用率，且进一步减少数据的迁移。

上述两种实时计算框架系统所实现的实时计算方法中，将数据接收线程近似平均地分配至各个执行节点上，以使各个执行节点所接收到的待处理数据较为平均，避免各个执行节点间接收到的数据严重不均导致的数据迁移情况，不仅保证了数据的本地化处理，而且提高了数据处理效率以及降低了数据迁移的通信成本。另外，本方法中，在分配待处理数据切分后的任务时，为每个执行节点分配的任务个数大于执行节点内处理核的个数，从而提高了处理核在每个处理周期内的利用率，进而进一步提高了数据的处理效率。

见图8，其示出了一种任务分配装置的结构，该装置应用于实时计算框架系统，所述实时计算框架系统中还包括任务生成模块及执行节点，所述执行节点内包括一个或多个处理核，该装置包括：任务获得单元81及任务分配单元82。

任务获得单元81，用于获得任务生成模块所切分的多个任务；

任务分配单元82，用于将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务，以减少空载时间。

在一个示例中，在执行所述将所述多个任务分配给所述执行节点的步骤时，所述任务获得单元具体用于：

获得为分配参数预先设置的参数值；其中所述参数值大于所述执行节点内包含的处理核的个数；依据所述参数值，将所述多个任务中所述参数值个数的任务分配给所述执行节点。

在一个示例中，在执行所述将所述多个任务分配给所述执行节点的步骤时，所述任务获得单元具体用于：

监测所述执行节点的运行状态；根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值；将所述最大值对应个数的任务分配给所述执行节点。

在一个示例中，运行状态包括：处理核在一个处理周期内处理任务的处理时长；则在执行在所述根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值的步骤时，所述任务获得单元具体用于：

将处理周期的时长除以处理核的处理时长后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

在一个示例中，运行状态包括：所述运行状态包括：处理周期的时长、任务的数据量大小及处理核的处理效率；则在执行在所述根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值的步骤时，所述任务获得单元具体用于：

将处理周期的时长除以任务的数据量大小及处理核的处理效率后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

见图9，其示出了另一种任务分配装置的结构，用于将数据接收线程分配给多个执行节点。该装置在上述图8的基础上，还包括：数据接收线程获得单元83、数据接收线程分配单元84及执行节点触发单元85。

数据接收线程获得单元83，用于获得多个数据接收线程；

数据接收线程分配单元84，用于将所述多个数据接收线程近似平均地分配给各个所述执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内。

执行节点触发单元85，用于触发每个所述执行节点分别运行各自所分配到的数据接收线程，使得各个所述执行节点接收到的数据近似平均，以减少数据迁移。

在一个示例中，在执行在所述获得多个数据接收线程的步骤时，所述数据接收线程获得单元具体用于：

判断所述实时计算框架系统是否处于启动阶段；若是，则将所述启动阶段内任务生成模块生成的任务确定为数据接收线程。

在一个示例中，在执行在所述获得多个数据接收线程的步骤时，所述数据接收线程获得单元具体用于：

获得任务生成模块生成的任务；将所述任务中具有预设属性特征的任务确定为数据接收线程。其中，所述预设属性特征为数据接收线程具有的属性特征。

本申请还提供了一种实时计算框架系统，具体包括：任务生成模块、任务调度模块、多个执行节点；

所述任务生成模块，用于生成多个数据接收线程；获得所述执行节点上的待处理数据，并将所述待处理数据切分为多个任务；

所述任务调度模块，用于获得所述任务生成模块生成的多个数据接收线程；将所述多个数据接收线程近似平均地分配给各个所述执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内；获得所述任务生成模块所切分的多个任务；以及将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务；

所述执行节点，包含一个或多个处理核，用于运行所分配到的数据接收线程，以接收待处理数据；以及由所述处理核对任务进行处理。

其中，任务调度模块执行将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务这个步骤时，可以有至少两种实现方式，分别为上述图7A中的步骤S707及图7B中的步骤S807。

执行节点可以具体为包含处理器及存储器的计算设备。任务生成模块、任务调度模块及执行节点可以分别部署在不同的计算设备上，或者任意两个或者三个部署在同一计算设备上。

计算设备可以包括处理器和存储器，其中存储器用于存储软件程序及数据，处理器通过运行存储在存储器内的软件程序、调用存储在存储器内的数据，执行相应的处理流程。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (17)

1.一种任务分配方法，其特征在于，应用于实时计算框架系统中的任务调度模块，所述实时计算框架系统中还包括任务生成模块及执行节点，所述执行节点内包括一个或多个处理核，该方法包括：

获得任务生成模块所切分的多个任务；

将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务，以减少空载时间；其中，包括：监测所述执行节点的运行状态；根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值；将所述最大值对应个数的任务分配给所述执行节点；所述运行状态包括处理核的处理效率；所述处理效率包括处理核单位时间内处理的任务总数据量。

2.根据权利要求1所述的任务分配方法，其特征在于，所述将所述多个任务分配给所述执行节点，包括：

获得为分配参数预先设置的参数值；其中所述参数值大于所述执行节点内包含的处理核的个数；

依据所述参数值，将所述多个任务中所述参数值个数的任务分配给所述执行节点。

3.根据权利要求1所述的任务分配方法，其特征在于，所述运行状态包括：处理核在一个处理周期内处理任务的处理时长；

则所述根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值，包括：

将处理周期的时长除以处理核的处理时长后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

4.根据权利要求1所述的任务分配方法，其特征在于，所述运行状态包括：处理周期的时长、任务的数据量大小及处理核的处理效率；

则所述根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值，包括：

将处理周期的时长除以任务的数据量大小及处理核的处理效率后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

5.根据权利要求1所述的任务分配方法，其特征在于，所述执行节点为多个；在所述获得任务生成模块所切分的多个任务之前，该方法还包括：

获得多个数据接收线程；

将所述多个数据接收线程近似平均地分配给各个所述执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内。

6.根据权利要求5所述的任务分配方法，其特征在于，在将所述多个数据接收线程近似平均地分配给各个所述执行节点之后，还包括：

触发每个所述执行节点分别运行各自所分配到的数据接收线程，使得各个所述执行节点接收到的数据近似平均，以减少数据迁移。

7.根据权利要求5所述的任务分配方法，其特征在于，所述获得多个数据接收线程，包括：

判断所述实时计算框架系统是否处于启动阶段；

若是，则将所述启动阶段内任务生成模块生成的任务确定为数据接收线程。

8.根据权利要求5所述的任务分配方法，其特征在于，所述获得多个数据接收线程，包括：

获得任务生成模块生成的任务；

将所述任务中具有预设属性特征的任务确定为数据接收线程；其中，所述预设属性特征为数据接收线程具有的属性特征。

9.一种任务分配装置，其特征在于，应用于实时计算框架系统，所述实时计算框架系统中还包括任务生成模块及执行节点，所述执行节点内包括一个或多个处理核，该装置包括：

任务获得单元，用于获得任务生成模块所切分的多个任务；

任务分配单元，用于将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务，以减少空载时间；其中，包括：监测所述执行节点的运行状态；根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值；将所述最大值对应个数的任务分配给所述执行节点；所述运行状态包括处理核的处理效率；所述处理效率包括处理核单位时间内处理的任务总数据量。

10.根据权利要求9所述的任务分配装置，其特征在于，在所述将所述多个任务分配给所述执行节点的方面，所述任务获得单元具体用于：

获得为分配参数预先设置的参数值；其中所述参数值大于所述执行节点内包含的处理核的个数；

依据所述参数值，将所述多个任务中所述参数值个数的任务分配给所述执行节点。

11.根据权利要求9所述的任务分配装置，其特征在于，所述运行状态包括：处理核在一个处理周期内处理任务的处理时长；

则在所述根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值的方面，所述任务获得单元具体用于：

将处理周期的时长除以处理核的处理时长后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

12.根据权利要求9所述的任务分配装置，其特征在于，所述运行状态包括：处理周期的时长、任务的数据量大小及处理核的处理效率；

则在所述根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值的方面，所述任务获得单元具体用于：

将处理周期的时长除以任务的数据量大小及处理核的处理效率后取整，得到单个处理核在一个处理周期内能够处理的任务的最大值。

13.根据权利要求9所述的任务分配装置，其特征在于，所述执行节点为多个；该装置还包括：

数据接收线程获得单元，用于获得多个数据接收线程；

数据接收线程分配单元，用于将所述多个数据接收线程近似平均地分配给各个所述执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内。

14.根据权利要求13所述的任务分配装置，其特征在于，还包括：

执行节点触发单元，用于触发每个所述执行节点分别运行各自所分配到的数据接收线程，使得各个所述执行节点接收到的数据近似平均，以减少数据迁移。

15.根据权利要求13所述的任务分配装置，其特征在于，在所述获得多个数据接收线程的方面，所述数据接收线程获得单元具体用于：

判断所述实时计算框架系统是否处于启动阶段；

若是，则将所述启动阶段内任务生成模块生成的任务确定为数据接收线程。

16.根据权利要求13所述的任务分配装置，其特征在于，在所述获得多个数据接收线程的方面，所述数据接收线程获得单元具体用于：

获得任务生成模块生成的任务；

将所述任务中具有预设属性特征的任务确定为数据接收线程；其中，所述预设属性特征为数据接收线程具有的属性特征。

17.一种实时计算框架系统，其特征在于，包括：任务生成模块、任务调度模块、多个执行节点；

所述任务生成模块，用于生成多个数据接收线程；获得所述执行节点上的待处理数据，并将所述待处理数据切分为多个任务；

所述任务调度模块，用于获得所述任务生成模块生成的多个数据接收线程；将所述多个数据接收线程近似平均地分配给各个所述执行节点；其中，所述近似平均表示各个执行节点分得的数据接收线程个数的差值在预设差值阈值范围内；获得所述任务生成模块所切分的多个任务；以及将所述多个任务分配给所述执行节点，使得所述执行节点内的每个处理核均对应于处理多个任务；其中，包括：监测所述执行节点的运行状态；根据所述运行状态，确定单个处理核在一个处理周期内能够处理的任务的最大值；将所述最大值对应个数的任务分配给所述执行节点；所述运行状态包括处理核的处理效率；所述处理效率包括处理核单位时间内处理的任务总数据量；

所述执行节点，包含一个或多个处理核，用于运行所分配到的数据接收线程，以接收待处理数据；以及由所述处理核对任务进行处理。

Images