一种任务分配方法、装置、设备及计算机可读介质与流程

本申请涉及计算机技术领域，尤其涉及一种任务分配方法、装置、设备及计算机可读介质。

背景技术：

随着大数据行业的快速发展，各种基于大数据的服务也逐渐增多。一般的，用户对开发工具的界面操作可以获取所需的数据；例如，用户在开发工具中通过拖拽一些预先配置的维度和指标，并将这些指标提交，以启动大数据中的调度任务，过一段时间后，任务计算完成会返回结果，用户即可得到所需的数据。但是，用户通过大数据服务获取所需的数据时，会存在以下问题：

由于用户提交的任务量较大，而服务器集群能够处理任务的资源有限，例如a、b两个任务队列对应的资源池在一定时间内分别最多能处理50个任务，而用户向a任务队列中提交了80个任务，向b任务队列中提交了10个任务，这样就造成a任务队列对应的资源池所接收的任务大幅度地超过了a任务队列对应的资源池的最大资源处理量50个，那么这时候就会造成服务器集群发生堵塞，从而服务器的计算速度也随之大幅度地降低；而b任务队列对应的资源池却只处理了10个任务，还剩余40个任务的资源处理量，使得b任务队列对应的资源池处于空闲状态，极大地浪费了b任务队列对应的资源池的处理资源；

因此，如何合理地将任务分配至服务器集群的资源池对应的任务队列中成为亟待解决的技术问题。

技术实现要素：

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种任务分配方法、装置、设备及计算机可读介质。

第一方面，本申请提供了一种任务分配方法，所述方法包括：

响应于待处理任务的任务处理请求，获取至少两个资源池的剩余资源和每个所述资源池所属服务器集群的集群性能参数；

获取待处理任务的任务数据；

根据所述任务数据以及各个资源池所属服务器集群的集群性能参数，确定不同资源池所属服务器集群处理所述待处理任务时的所需资源量；

将所述剩余资源大于或等于所述所需资源量的至少一个资源池作为待选资源池，计算每个待选资源池处理所述待处理任务的预估处理时间；

根据每个待选资源池所属服务器集群处理所述待处理任务的预估处理时间，确定所述待处理任务的目标资源池；

将所述待处理任务分配至所述目标资源池。

可选地，所述确定所述待处理任务的目标资源池，包括：

将预估处理时间最小的待选资源池作为所述目标资源池。

可选地，所述确定所述待处理任务的目标资源池，还包括：

判断所述预估处理时间最小的待选资源池对应的任务列表是否为空；

若预估处理时间最小的待选资源池对应的任务列表为空，执行所述将预估处理时间最小的待选资源池作为所述目标资源池的步骤。

可选地，所述确定所述待处理任务的目标资源池，还包括：

若预估处理时间最小的待选资源池对应的任务列表不为空，获取每个待选资源池对应的任务列表中等待任务的预估处理时间；

根据每个待选资源池对应的任务列表中等待任务的预估处理时间，计算每个待选资源池在预设时间段内处理任务的数量；

选择预设时间段内处理任务的数量最多的待选资源池作为目标资源池。

可选地，所述获取每个所述资源池所属服务器集群的集群性能参数，包括：

获取每个资源池所属服务器集群中的hive配置参数，以及获取每个资源池所属服务器集群的数据读速率dr和数据写速率dw；

根据所述hive配置参数确定每个资源池所属服务器集群中单个归约函数配置的参考数据处理量，每个任务最多配置的归约函数配置量，以及，单个归约函数配置最大数据处理量和最小数据处理量。

可选地，获取待处理任务的任务数据，包括：

获取所述待处理任务中所包含数据表所对应的数据集的数据量值；以及，获取所述待处理任务的维度；

将所有表的数据集的数据量值相加得到待处理总数据量；

将所述待处理总数据量和维度，作为所述待处理任务的任务数据。

可选地，确定不同资源池所属服务器集群处理所述待处理任务时的所需资源量，包括：

针对每个资源池所属服务器集群，利用参考数据处理量、最大数据处理量和最小数据处理量计算平均数据处理量；

利用总数据量除以平均数据处理量计算映射函数个数；

利用归约函数配置量、总数据量和参考数据处理量计算归约函数个数；

利用映射函数个数和归约函数个数，计算所述所需资源量。

可选地，所述计算每个待选资源池处理所述待处理任务的预估处理时间，包括：

根据所述待处理任务的映射函数个数和归约函数个数，计算所述待处理任务的任务权重；

根据所述任务权重和所述维度，确定所述待处理任务的任务复杂度；

根据所述任务复杂度、每个待选资源池所属服务器集群的数据读速率dr和数据写速率dw，计算每个待选资源池处理所述待处理任务的预估处理时间。

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

判断是否存在剩余资源大于或等于所述所需资源量的资源池；

若不存在所述剩余资源大于或等于所述所需资源量的资源池，将所述待处理任务加入至批量等待列表中，并检测任意一个或多个资源池是否有资源释放操作；若任意一个或多个资源池有资源释放操作，执行判断是否存在剩余资源大于或等于所述所需资源量的资源池的步骤，直至出现剩余资源大于或等于所述所需资源量的资源池。

第二方面，本申请实施例提供一种任务分配装置，包括：

资源池数据获取模块，用于响应于待处理任务的任务处理请求，获取至少两个资源池的剩余资源和每个所述资源池所属服务器集群的集群性能参数；

任务数据获取模块，用于获取待处理任务的任务数据；

任务确定模块，用于根据所述任务数据以及各个所述服务器集群的集群性能参数，确定不同资源池所属服务器集群处理所述待处理任务时的所需资源量；

时间计算模块，用于将所述剩余资源大于或等于所述所需资源量的至少一个资源池作为待选资源池，计算每个待选资源池处理所述待处理任务的预估处理时间；

目标资源池确定模块，用于根据每个待选资源池处理所述待处理任务的预估处理时间，确定所述待处理任务的目标资源池；

任务分配模块，用于将所述待处理任务分配至所述目标资源池对应的任务列表中。

可选地，所述目标资源池确定模块，还用于将预估处理时间最小的待选资源池作为所述目标资源池；

或者，目标资源池确定模块，还用于判断所述预估处理时间最小的待选资源池对应的任务列表是否为空；若预估处理时间最小的待选资源池对应的任务列表为空，将预估处理时间最小的待选资源池作为所述目标资源池。

可选地，所述目标资源池确定模块，还用于判断所述预估处理时间最小的待选资源池对应的任务列表是否为空；若预估处理时间最小的待选资源池对应的任务列表不为空根据每个待选资源池对应的任务列表中等待任务的预估处理时间，测算每个待选资源池在预设时间段内处理任务的数量；选择预设时间段内处理任务的数量最多的待选资源池作为目标资源池。

第三方面，本申请提供了一种计算机设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述第一方面任一所述的方法。

第四方面，本申请还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行上述第一方面任一所述的方法。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：

本申请实施例提供的该方法，在分配任务时，首先将资源池的剩余资源作为参考因素，先确定剩余资源大于或等于待分配任务所需资源量的至少一个资源池作为待选资源池，然后计算每个待选资源池处理所述待处理任务的预估处理时间，并且根据不同待选资源池对待处理任务的预估处理时间，进一步确定出待处理任务的目标资源池，最终，将待处理任务分配至所述目标资源池对应的任务列表中。

该方法在服务器集群中的任务分配时，既考虑了资源池的剩余资源与待处理任务的匹配情况，而且同时考虑了待处理任务的预估处理时间，所以可以避免任务分配时服务器集群出现阻塞的情况，并且使得待处理任务的分配更加合理，使得待处理任务的处理更加高效。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

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

图1a是根据本申请实施例的任务分配方法的硬件环境的示意图；

图1b是根据本申请实施例的任务分配方法的任务交互的示意图；

图2为本申请实施例提供的一种任务分配方法流程示意图；

图3为本申请实施例提供的另一种任务分配方法流程示意图；

图4为本申请实施例提供的一种任务分配方法流程示意图；

图5a为本申请实施例提供的另一种任务分配方法流程示意图；

图5b为本申请实施例提供的一种任务分配方法的逻辑图；

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

具体实施方式

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

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本申请的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

可选地，在本实施例中，上述数据处理方法可以应用于如图1a所示的由终端101和至少一个服务器103所构成的硬件环境中。如图1a所示，服务器103通过网络与终端101进行连接，可用于为终端或终端上安装的客户端提供服务(如多媒体服务、游戏服务、应用服务、理财服务、购物服务等)，可在服务器上或独立于服务器设置数据库，用于为服务器103提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端101并不限定于pc、手机、平板电脑等。本申请实施例的任务分配方法可以由服务器103来执行。

图2是根据本申请实施例的一种任务分配方法的流程示意图。

本申请实施例中，该任务分配方法可以应用于图1a中的服务器103，并且服务器103构成服务器集群中，服务器集群的设置上，可以为本地服务器集群，也可以为在线的云服务器集群。

在类型上，服务器集群可以为高可用集群、负载均衡集群或者科学计算集群，更具体第，服务器集群可以为hadoop集群。hadoop集群是一种分布式系统基础架构，基于hadoop集群可以提供高吞吐量来访问数据的优点，hadoop集群广泛应用于大数据领域。在hadoop集群的基础上可以进一步开发更多功能的框架系统。其中，hadoop集群的框架中重要的一部分为hdfs(hadoopdistributedfilesystem，分布式文件系统)，hdfs为大量的数据提供了分布式存储。

以hadoop集群为例，yarn(yetanotherresourcenegotiator，通用的资源管理平台)是一种的hadoop资源管理器，它是一个通用资源管理系统，可为服务器集群提供统一的资源管理和调度。通过yarn对服务器集群中的资源进行统一管理和分配，使得服务器集群在资源利用率、资源统一管理和数据共享等方面均有较好的效果。在本申请实施例中，该任务分配方法可以应用在yarn中。

参见图2所示，本申请实施例提供的该任务分配方法，可以包括以下步骤：

s101，响应于待处理任务的任务处理请求，获取至少两个资源池的剩余资源和每个所述资源池所属服务器集群的集群性能参数。

本申请实施例中，服务器集群的资源可以被预先划分为多个资源池，资源池可以采用均分的方式，例如：技术人员设置资源池为5个，那么将服务器集群的总资源等分为5份，例如：服务器集群的总资源为10000个，那么每个资源池的大小为2000个。另外，在资源池划分时，还可以全部采用人工划分，其中，资源池的数量，以及每个资源池的大小，都可以自由设置。例如：服务器集群的总资源为10000个，可以预先划分为3个资源池，并且a资源池的资源设置为500个，b资源池的资源设置为300个，c资源池的资源设置为200个。

对于每个资源池而言，为了避免出现当前处理的任务资源超过该资源池的最大资源，进而造成集群堵塞情况，所以，每个资源池可以设置一个最大处理资源比例，例如：最大处理资源比例为资源总量的80％，或者，最大处理资源比例为所有资源的90％，例如：某资源池k资源总量为1000个，其对应的最大处理资源比例为80％，进而该资源池k在运行时，最大处理资源的量应为：1000*最大处理资源比例＝1000*80％＝800个。

在本申请实施例中，每个资源池的剩余资源为资源池当前的空闲资源或者可用资源，在具体应用中，每个资源池的资源总量是已知的，例如：前述a资源的资源总量设置为500个，a资源池当前正在运行的任务已占用的资源量是300个，那么在a资源池的最大处理资源比例为100％的情况下，剩余资源s＝最大处理资源的量-已占用的资源量＝资源总量*最大处理资源比例-已占用的资源量＝500*100％-300＝200个。如果a资源池的最大处理资源比例为80％，那么剩余资源s＝最大处理资源的量-已占用的资源量＝资源总量*最大处理资源比例-已占用的资源量＝500*80％-300＝100个。

在本申请实施例中，每个资源池都预先配置有一个对应的任务队列，任务队列中可以有多个等待任务，等待任务处于等待状态。当接收到任务请求后，会将该任务请求对应的任务分配到某一个资源池对应的任务队列中。在本申请实施例中，可以按照约定的时间，定期将任务队列中的等待任务，提交至各自对应的服务器集群，在具体应用中，任务列表可以按照每5分钟提交一次等待任务。

参考图1b所示，图中包括服务器集群1、服务器集群2……服务器集群n，其中，服务器集群1对应资源池1，资源池1对应任务队列1；服务器集群2对应资源池2，资源池2对应任务队列2；服务器集群n对应资源池3，资源池3对应任务队列3。

在每个任务队列中可以含有一个或多个任务，也可以没有任务，参见图1b所示，在任务队列1中，含有tsak11、tsak12、tsak13、tsak14、……、tsak1n多个等待任务，同理任务队列2和任务队列3中均多个等待任务。

用户提交任务请求后，该任务请求对应的任务会被根据资源池中的资源的情况分配到对应的资源池，也即分配到与该资源池对应的任务队列中，进行等待，任务队列中的任务可以被提交至对应服务器集群中进行处理。

在本申请实施例中，每个所述资源池所属服务器集群的集群性能参数可以通过服务器集群的配置参数读取得到，其中，集群性能参数包括但不局限于：每个归约函数(reduce，reduce是mapreduce数据模型中的一个函数类型，用于对数据进行处理)能处理的参考数据处理量(blocksize)，每个任务最多可配置的reduce函数配置量(maxreduce)，以及，单个reduce函数配置最大数据处理量(maxsize)和最小数据处理量(minsize)。

s102，获取待处理任务的任务数据。

在本申请一个具体实现方式时，当用户提交待处理任务的任务处理请求时，可以从任务处理请求中提取该待处理任务的任务标识，例如：任务id或任务编号。

通过任务标识，可以查找到跟该任务标识对应的sql语句(structuredquerylanguage，结构化查询语言)，通过sql语句可以查询得到对应的各种表的数据集的数据量的大小，也即数据量值，这些数据量值可以作为任务数据的一部分。

以一个查询任务为例，在某网站的一次抽奖活动中，查询参与抽奖的所有用户的位置以及年龄段，那么用户输入该查询请求后，对应的sql查询语句，查询语句会对应查询不同的数据表，例如：抽奖名单数据表；用户身份信息表，以及，用户位置信息表等，不同数据表的内容不同，其对应的数据量也是不同的，通过与本次查询任务相关的各种表的数据集的数据量的大小，可以来判断出本次任务的复杂程度。

在本申请实施例中，任务数据还可以包括：待处理任务的维度d和指标。这里指标是用于衡量事物发展程度的单位或方法，它还有个it上常用的名字，也就是度量。例如：人口数、gdp、收入、用户数、利润率、留存率、覆盖率等。很多公司都有自己的kpi指标体系，就是通过几个关键指标来衡量公司业务运营情况的好坏。指标需要经过加和、平均等汇总计算方式得到，并且是需要在一定的前提条件进行汇总计算，如时间、地点、范围，也就是我们常说的统计口径与范围。

另外，维度d是指是事物或现象的某种特征，如性别、地区、时间等都是维度。其中时间是一种常用、特殊的维度，通过时间前后的对比，就可以知道事物的发展是好了还是坏了，如用户数环比上月增长10％、同比去年同期增长20％，这就是时间上的对比，也称为纵比；另一个比较就是横比，如不同国家人口数、gdp的比较，不同省份收入、用户数的比较、不同公司、不同部门之间的比较，这些都是同级单位之间的比较，简称横比。

在本申请实施例中，维度d可以为用户维度、视频维度、用户输入筛选后维度，视频输入维度中的一个或多个。其中，用户维度取值可以为5；视频维度取值可以为200；用户输入筛选后维度可以为2；视频输入筛选后维度可以为20。

s103，根据所述任务数据以及各个资源池所属服务器集群的集群性能参数，确定不同资源池所属服务器集群处理所述待处理任务时的所需资源量。

对于任意一个待处理任务而言，由于其需要查询的数据量级，查询的数据的广度等不同，所以，每个待处理任务的处理难度是不同的，例如：如果查询一下当前用户中的性别比例，由于每个用户的数据在存储时已经录入了性别这一数据维度，那么只需要统计出性别这一维度的数据，然后计算“男性”、“女性”的数量的比例，即可得到。而，如果，是查询当前用户中位于特定城市的具有舞蹈爱好的女性，那么查询时，不仅需要查询位置，还需要查询性别，还需要查找爱好，所以该待处理任务的难度很显然比仅查询性别比例，难度要大。

而对于资源池对应的服务器，其当前的硬件配置会对其处理任务的能力也有影响，例如：数据读速率，或在，数据写速率等。

在该步骤中，通过所述任务数据可以了解待处理任务的难度，通过各个资源池所属服务器集群的集群性能参数，可以了解服务器集群的数据处理能力，结合这两个数据，就可以确定出不同资源池所属服务器集群处理所述待处理任务时的映射函数个数(map，map是mapreduce数据模型中的一个函数类型，用于对数据进行处理)和reduce函数个数；

当确定出现map函数个数和reduce函数个数后，就可以知道待处理任务被处理时，需要的所需资源量，在具体应用中，可以根据历史任务处理情况，预先存储map函数个数与所需资源量的对应关系，以及，reduce函数个数与所需资源量的对应关系，进而可以直接查询的方式，得到map函数个数和reduce函数个数对应的所需资源量。

s104，将所述剩余资源大于或等于所述所需资源量的至少一个资源池作为待选资源池，计算每个待选资源池所属服务器集群处理所述待处理任务的预估处理时间。

作为可以处理待处理任务的首选条件，是资源池的当前剩余资源必须满足待处理任务的所需资源量，例如：剩余资源大于，或，至少等于待处理任务的所需资源量。

但当资源池的数量为两个或两个以上时，可能存在两个或两个以上的资源池可能都会满足待处理任务的所需资源量的要求，此时待处理任务还面临无法选择资源池的情况。

为此，在资源池的剩余资源满足要求时，可以将资源池作为待选资源池，然后在分析每个待选资源池所属服务器集群在处理待处理任务的预估处理时间，预估处理时间可以作为除剩余资源外的，在资源池选择时的第二个参考的维度。

s105，根据每个待选资源池处理所述待处理任务的预估处理时间，确定所述待处理任务的目标资源池。

在本申请实施例，分配待处理任务到哪一个资源池，其目的是为了使得待处理任务的处理效率最高，为此，在本申请实施例中，根据预估处理时间来确定目标资源池时，一种情况下，可以按照预估处理时间的大小来分配，例如：将预估处理时间最小的资源池，确定为目标资源池。以保证目标资源池在处理待处理任务时，相比其它的资源池而言，可以更加高效。

s106，将所述待处理任务分配至所述目标资源池。

一旦确定出目标资源池，在该步骤中，可以直接将待处理任务加入到目标资源池对应的任务列表中，作为一个等待任务，当任务列表按照设定的提交间隔，可以在下一次提交给目标资源池对应的服务器集群。

本申请实施例提供的该方法，如果当前资源池无法处理待处理任务，那么待处理任务不会被分配至任意一个资源池的任务列表中，只有满足前述的分配条件，才会分配至目标资源池。

本申请实施例提供的该任务分配方法，在分配任务时，首先将资源池的剩余资源作为参考因素，先确定剩余资源大于或等于待分配任务所需资源量的至少一个资源池作为待选资源池，然后计算每个待选资源池处理所述待处理任务的预估处理时间，并且根据不同待选资源池对待处理任务的预估处理时间，进一步确定出待处理任务的目标资源池，最终，将待处理任务分配至所述目标资源池对应的任务列表中。

该方法在服务器集群中的任务分配时，既考虑了资源池的剩余资源与待处理任务的匹配情况，而且同时考虑了待处理任务的预估处理时间，所以可以避免任务分配时服务器集群出现阻塞的情况，并且使得待处理任务的分配更加合理，并且待处理任务的处理更加高效。

在本申请一个实施例中，提供了一种任务分配方法，参见图3所示，该方法可以包括以下步骤：

s201，响应于待处理任务的任务处理请求，获取至少两个资源池的剩余资源和每个所述资源池所属服务器集群的集群性能参数。

s202，获取待处理任务的任务数据。

s203，根据所述任务数据以及各个资源池所属服务器集群的集群性能参数，确定不同资源池所属服务器集群处理所述待处理任务时的需资源量。

s204，将所述剩余资源大于或等于所述所需资源量的至少一个资源池作为待选资源池，计算每个待选资源池处理所述待处理任务的预估处理时间。

前述步骤s201-204的详细描述，可以参考前述步骤s101-s104的描述，在此不再赘述。

s205，根据每个待选资源池所属服务器集群处理所述待处理任务的预估处理时间，将预估处理时间最小的待选资源池作为所述目标资源池。

在该步骤中，可以将每个待选资源池所属服务器集群处理所述待处理任务的预估处理时间进行比较，例如：进行一一对比，将较短预估处理时间的与其它预估时间进行比较，直至确定最小的预估处理时间，或者，将所有预估处理时间进行排序，按照排序，选取最小的预估处理时间。

选取预估处理时间最小，可以使得待分配任务被分配后，可以被快速、高效率处理。

s206，将所述待处理任务分配至所述目标资源池对应的任务列表中。

在前述图3所示实施例中，在选择目标资源池时，将预估处理时间最小的待选资源池，直接作为目标资源池，而实际在任务分配时，虽然预估处理时间最小的待选资源池，表示该待选资源池处理待处理任务是较优的，基于待处理任务单个任务而言。当待选资源池的任务队列中有多个等待任务时，在进行分配时，不仅需要考虑待分配任务本申请，还需要考虑任务列表中等待任务。为此，在图3所示实施例的基础上，参见图4所述，在步骤s204之后，该方法还可以包括以下步骤：

s207，判断所述预估处理时间最小的待选资源池对应的任务列表是否为空。

在具体应用中，可以读取预估处理时间最小的待选资源池对应的任务列表，然后判断该任务列表中任务的数量，如果数量为0，表示该任务类表为空。

若预估处理时间最小的待选资源池对应的任务列表为空，执行步骤s205，否则，执行步骤s208。

本申请实施例提供的该方法，如果预估处理时间最小的待选资源池为资源池a，那么a资源池对应的任务列表为空时，表示当前该a资源池，没有任务在运行，同时对于待处理任务而言，相比于其它资源池，a资源池由于预估处理时间最小，所以a资源池是最优的资源池，进而可以直接确定为目标资源池，相反，如果a资源池中还有其它任务正在运行，那么就需要重新确定的目标资源池。

s208，获取每个待选资源池对应的任务列表中等待任务的预估处理时间。

每个任务在加入到对应资源池的任务列表之前，都可以采用前述的步骤对各自对应的资源池的处理时间进行预估，得到各自的预估处理时间。在本申请数量中，可以将预估处理时间单独存储，在该步骤中，可以直接取预先存储的每个等待任务的预估处理时间。

s209，根据每个待选资源池对应的任务列表中等待任务的预估处理时间，测算每个待选资源池在预设时间段内处理任务的数量。

在本申请实施例中，预设时间段可以为技术人员手动设置的，例如：预设时间段可以为30分钟。

任务类表中的等待任务，每间隔一段时间才提交各自所在资源池对应的服务器集群。所在等待时，可以根据每个待选资源池对应的任务列表中等待任务的预估处理时间，测算每个待选资源池在预设时间段内处理任务的数量。

具体可以为，某一个队列q中，按照先后顺序存储有，q1、q2、q3、q4和q5这5个等待任务，其中，q1的预估处理时间为5分钟，q2的预估处理时间为7分钟，q3的预估处理时间为8分钟，q5的预估处理时间为9分钟，q6的预估处理时间为3分钟。

由于队列中的任务从q1开始处理，那么q1、q2、q3、q4、q5的预估处理时间相加等于29分钟，那么在30分钟内，该队列q对应的资源池可以处理的任务数量为q1、q2、q3、q4、q5这5个。

对于队列p来说，按照先后顺序存储有，p1、p2、p3这3个等待任务，其中，p1的预估处理时间为15分钟，p2的预估处理时间为7分钟，p3的预估处理时间为18分钟。由于p1+p2的预估处理时间相加为22分钟，p1+p2+p3的预处理时间相加为40分钟。因此在30分钟内，该队列p对应的资源池可以处理的任务数量为p1和p2两个。

s210，选择预设时间段内处理任务的数量最多的待选资源池作为目标资源池。

参见前述209中的描述，队列p相对于队列q，在预设时间段内测算的处理任务的数量最多，表示该待选资源池中的任务队列中已经分配的等待任务的处理的效率最高。也即，如果将待分配任务分配至该队列p中，那么虽然当前无法被处理，但是一旦任务中的其它的等待任务被处理完，就可以处理待处理任务。

在本申请实施例中，还可以设置一个提交任务队列，在待处理任务提交后，可以将待处理任务放入到该提交任务队列中，提交任务队列为共用队列，对于提交任务队列中的待分配任务，如果可以被分配，则直接分配至对应资源池的任务队列时，而如果经过计算，无法被分配至任意一个资源池对应的任务队列时，则继续保留在提交任务队列中继续等待分配资源池。在步骤s210之后，执行步骤s207。

本申请实施例提供的该方法，在待选资源池的任务列表中有等待处理的等待任务时，可以测算每个待选资源池在预设时间段内处理任务的数量，并且优选在预设时间段内处理任务的数量最多的待选资源池，作为目标资源池，由于目标资源池对任务列表中的等待任务处理效率最高的，所以将待分配任务分配给目标资源池后，也可以很快被处理。

本申请实施例提供了一种任务分配方法，如图5a所示，该方法可以包括以下步骤：

stp1，响应于待处理任务的任务处理请求，获取每个资源池所属服务器集群中剩余资源。

在资源池被分配处理任务时，都会有任务处理记录，也即占用的资源的记录，为此，在该步骤中，可以直接从yarn的资源管理系统中读取到剩余资源。

stp2，获取每个资源池所属服务器集群中的hive配置参数，以及获取每个资源池所属服务器集群的数据读速率dr和数据写速率dw。

stp3，根据所述hive配置参数确定每个资源池所属服务器集群中单个reduce函数配置的参考数据处理量(blocksize)，每个任务最多配置的reduce函数配置量(maxreduce)，以及，单个reduce函数配置最大数据处理量(maxsize)和最小数据处理量(minsize)。

其中，可以通过查看服务器集群中的配置参数(具体可以通过查看服务器集群配置信息中hive.exec.reducers.bytes.per.reducer命令行的内容)，来获取每个资源池所属服务器集群中单个reduce配置的参考数据处理量，记录为，blocksize。另外，可以通过查看服务器集群中的配置参数(具体可以通过查看服务器集群配置信息中hive.exec.reducers.max命令行的内容)，来获取每个任务最多配置的reduce配置量，记录为maxreduce。

在本申请实施例中，通过资源池所属服务器集群的磁盘的硬件参数，可以获取每个资源池所属服务器集群的数据读速率dr和数据写速率dw，在本申请实施中，服务器集群的读的速率如：dr＝100mb/s和磁盘顺序写速率dw＝70mb/s。

在本申请实施例中，将参考数据处理量、reduce函数配置量、最大数据处理量、最小数据处理量、数据读速率dr和数据写速率dw，作为集群性能参数。

stp4，获取所述待处理任务的维度。

待处理任务的维度d可以直接解析待处理任务得到。在本申请实施例中，维度d可以为用户维度、视频维度、用户输入筛选后维度，视频输入维度中的一个或多个。其中，解析得到的用户维度取值可以为5；视频维度取值可以为200；用户输入筛选后维度可以为2；视频输入筛选后维度可以为20。

stp5，获取所述待处理任务各个表的数据集的数据量值。

在本申请实施例中，获取待处理任务中sql语句中每个表的数据集大小可以为：s1,s2,s3,s4,s5...。

stp6，将所有表的数据集的数据量值相加得到待处理总数据量；

参见步骤stp5，在该步骤中，待处理总数据量可以采用以下方式计算得到：sum(s1+s1+s2+s3+s4+s5+...)，记录为totalsize。

参见前述步骤stp4-stp6，在本申请实施例中，将所述待处理总数据量和维度，作为所述待处理任务的任务数据。

stp7，针对每个资源池所属服务器集群，利用参考数据处理量、最大数据处理量和最小数据处理量计算平均数据处理量。

在本申请实施例中，平均数据处理量，可以用splitsize来表示，参见前述描述，splitsize＝max{minsize,min{maxsize,blocksize}}。

stp8，利用总数据量除以平均数据处理量计算map函数个数。

在本申请实施例中，map函数个数可以用m表示，并且map函数个数的计算公式可以为m＝totalsize/splitsize。

stp9，利用reduce函数配置量、总数据量和参考数据处理量计算reduce函数个数。

在本申请实施例中，reduce函数个数可以用r表示，并且reduce函数个数的计算公式可以为：r＝min(maxreduce，totalsize/blocksize)。

stp10，利用map函数个数和reduce函数个数，预估所述所需资源量。

根据资源池对应的服务器集群在历史任务处理时，每个历史任务都是通过map函数个数reduce来实现，为此，通过历史任务处理时所占用的资源量，可以确定map函数个数与资源量的对应关系，以及确定和reduce函数个数与资源量的对应关系。

在步骤中，可以根据历史任务处理时的对应关系，在指导待处理任务的map函数个数和reduce函数个数的基础上，可以通过查表的方式预估出该待处理任务的所需资源量。

stp11，根据所述待处理任务的map函数个数和reduce函数个数，计算所述待处理任务的任务权重。

在本申请实施例中，任务权重可以用weight表示，并且任务权重的计算公式为weight＝m*r+c；c为常数，可以为自然数或小数，通常c默认为0，并且c的值技术人员可以通过程序控制进行改变。

在本申请实施例中，在需要对某一个任务进行优先处理时，可以通过设置c的数值较大，那么待处理任务的任务权重也就相应变大。权重越大表示计算待处理任务占用资源越多，进行可以加速一些任务运行。比如一些运营紧急需要结果，那么我们可以降低该任务权重，加速任务的运行。

stp12，根据所述任务权重和所述维度，确定所述待处理任务的任务复杂度。

在本申请实施例中，任务复杂度用complexity表示，并且任务复杂度的计算公式为：complexity＝(m*r+c)*d，其中d是维度，例如：用户维度取值为5；视频维度取值200；用户输入筛选后维度为2；视频输入筛选后维度为20；维度取值的大小和任务复杂度呈正相关。详细可以参见前述步骤s102或步骤stp4中的描述。

stp13，根据所述任务复杂度、以及，每个待选资源池所述服务器集群的数据读速率dr和数据写速率dw，计算每个待选资源池处理所述待处理任务的预估处理时间。

在本申请实施例中，预估处理时间用time来表示，预估处理时间用time的计算公式为：time＝complexity*dr/dw。

因此，在该步骤中，可以通过任务复杂度、数据读速率dr和数据写速率dw来算计得到预估处理时间。

stp14，判断所述预估处理时间最小的待选资源池对应的任务列表是否为空。

如果任务列表为空，执行stp15，否则，执行s17。

stp15，将预估处理时间最小的待选资源池作为所述目标资源池。

stp16，将所述待处理任务分配至所述目标资源池对应的任务列表中。

stp17，获取每个待选资源池对应的任务列表中等待任务的预估处理时间；

stp18，根据每个待选资源池对应的任务列表中等待任务的预估处理时间，测算每个待选资源池在预设时间段内处理任务的数量；

stp19，选择预设时间段内处理任务的数量最多的待选资源池作为目标资源池。

在步骤stp19之后，跳转至步骤stp16。

图5b为本申请实施例提供的一种任务分配方法的逻辑图。

参见前述图3实施例的描述，由于可以设置一个提交任务队列，在待处理任务提交后，可以将待处理任务放入到该提交任务队列中，提交任务队列为共用队列，对于提交任务队列中的待分配任务，如果可以被未被分配，则直接分配至对应资源池的任务队列时，而如果经过计算，无法被分配至任意一个资源池对应的任务队列时，则继续保留在提交任务队列中。

参见图5b所示，在用户提交待处理任务后，可以将待处理任务加入到提交至任务队列中，针对待处理任务，在每个资源池中，分别获取计算每个待选资源池对待处理任务的预估处理时间。如图所示，图中包括：获取任务数据，例如前述步骤s102；然后获取集群信息，这里集群信息可以是指前述步骤中的剩余资源和集群性能参数，例如步骤s101；然后再进行任务处理相关计算，例如，前述步骤中的s103，最后计算预估处理时间，例如前述步骤s104。

当每个待选资源池对待处理任务的预估处理时间计算完成后，可以判断是否存在目标资源池，例如：前述步骤s105，或者，s205，或者，s207-s210等，如果存在目标资源池，那么就可以将提交任务列表中的待分配任务提交至该目标资源池的任务队列中，例如步骤s106，以便目标资源池可以对待处理任务进行处理，最终输出待处理任务的处理结果给用户。

根据本申请实施例的另一个方面，还提供了一种任务分配装置，图6为根据本申请实施例提供的任务分配装置的结构示意图的结构示意图，如图6所示，该装置可以包括：

资源池数据获取模块11，被配置为响应于待处理任务的任务处理请求，获取至少两个资源池的剩余资源和每个所述资源池所属服务器集群的集群性能参数；

任务数据获取模块12，被配置为获取待处理任务的任务数据；

任务确定模块13，被配置为根据所述任务数据以及各个所述服务器集群的集群性能参数，确定不同资源池所属服务器集群处理所述待处理任务时的所需资源量；

时间计算模块14，被配置为将所述剩余资源大于或等于所述所需资源量的至少一个资源池作为待选资源池，计算每个待选资源池处理所述待处理任务的预估处理时间；

目标资源池确定模块15，被配置为根据每个待选资源池处理所述待处理任务的预估处理时间，确定所述待处理任务的目标资源池；

任务分配模块16，被配置为将所述待处理任务分配至所述目标资源池对应的任务列表中。

在本申请实施例提供的该任务分配装置中，在分配任务时，首先将资源池的剩余资源作为参考因素，先确定剩余资源大于或等于待分配任务所需资源量的至少一个资源池作为待选资源池，然后计算每个待选资源池处理所述待处理任务的预估处理时间，并且根据不同待选资源池对待处理任务的预估处理时间，进一步确定出待处理任务的目标资源池，最终，将待处理任务分配至所述目标资源池对应的任务列表中。

该装置在服务器集群中的任务分配时，既考虑了资源池的剩余资源与待处理任务的匹配情况，而且同时考虑了待处理任务的预估处理时间，所以可以避免任务分配时服务器集群出现阻塞的情况，并且使得待处理任务的分配更加合理，并且待处理任务的处理更加高效。

在本申请一个实施例中，所述目标资源池确定模块，还用于将预估处理时间最小的待选资源池作为所述目标资源池；

在本申请一个实施例中，目标资源池确定模块，还用于判断所述预估处理时间最小的待选资源池对应的任务列表是否为空；若预估处理时间最小的待选资源池对应的任务列表为空，将预估处理时间最小的待选资源池作为所述目标资源池。

在本申请一个实施例中，所述目标资源池确定模块，还用于判断所述预估处理时间最小的待选资源池对应的任务列表是否为空；若预估处理时间最小的待选资源池对应的任务列表不为空根据每个待选资源池对应的任务列表中等待任务的预估处理时间，测算每个待选资源池在预设时间段内处理任务的数量；选择预设时间段内处理任务的数量最多的待选资源池作为目标资源池。

根据本申请实施例的又一方面还提供了一种计算机设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意一个方法实施例提供的步骤。

上述计算机设备中的存储器、处理器通过通信总线和通信接口进行通信。所述通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，简称pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。

存储器可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

根据本申请实施例的又一方面还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质。

可选地，在本申请实施例中，计算机可读介质被设置为存储用于所述处理器执行任意一个方法实施例提供的步骤的程序代码。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本申请实施例在具体实现时，可以参阅上述各个实施例，具有相应的技术效果。

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

本领域普通技术人员可以意识到，结合本发明实施例中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。