CN109634989A - 一种hive任务执行引擎选择方法和系统 - Google Patents

Abstract

本申请提供一种HIVE任务执行引擎选择方法和系统，所述方法包括计算任务拓扑图中的关键路径；计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务；对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎；重复上述步骤，直至确定每个任务的执行引擎。减少了对调度系统进行任务配置所需要的人力资源，减少了参数配置出错的失败风险；避免了配置出错引起的任务延迟。

Description

一种HIVE任务执行引擎选择方法和系统

【技术领域】

本申请涉及计算机技术领域，尤其涉及一种HIVE任务执行引擎选择方法和系统。

【背景技术】

Hive是一个开源软件，它用数据分析人员常用的结构化查询语言(StructuredQuery Language，简称SQL)来处理分布式存储系统中的数据。

Hive的执行引擎有三种，使用时间最长，最广泛，最稳定的执行引擎是MapReduce。MapReduce是开源的大数据处理平台Hadoop自带的分布式处理框架。Hive用MapReduce执行SQL任务时，需要0个或多个MapReduce任务来运行最终的结果。如果SQL计算的数据量比较小，不超过一定的值，例如10M(可以参数配置)，那么Hive可以把这些数据加载到执行Hive的内存中进行计算。如果数据量比较大，需要用MapReduce在集群上分布式计算。需要的MapReduce的个数根据SQL的表示的数据需要聚合的次数来决定。

MapReduce虽然使用时间长，最稳定，但是它也有缺点。每个MapReduce的输出结果，数据默认存储在分布式存储系统HDFS上。在HDFS上的数据默认有三个副本，分别存储在三台服务器上。好处是存储之后任何一台服务器损坏都不会导致数据丢失。坏处是造成比较大的网络压力，还有服务器的存储压力。

Hive的其他新的执行引擎，如Tez尝试解决这个问题。在Tez中，上面的MapReduce进行处理完后，不再写到分布式存储系统，而是调用下一阶段的Map任务。把Map任务输出保存到本机的硬盘上。然后等待Reduce来读取。这样的好处如下：中间的数据不需要保存在分布式存储系统上，节约存储容量和带宽，并且本地存储的速度比远程存储快；由于上阶段的Reduce和Map任务合并，所以减少任务的数量。

但是也并不是所有的任务都用Tez执行速度快，原因如下：

Hive中每个MapReduce程序运行时，Reduce任务的个数可以根据数据量自动调整。如我们可以设置每256M数据一个Reduce。当MapReduce在提交时，客户端先把要计算的文件大小加起来，配置Reduce的数量。如第一个MapReduce过滤掉大量的记录，所以后续的MapReduce需要计算的数据量较少时，就可以只有少量的Map任务和Reduce任务。而用Tez执行时，下一个阶段的Map任务和上个阶段的Reduce任务是合并执行的，并且Map任务执行时就要知道有多少个Reduce任务，因为在Map阶段数据要根据Reduce的个数进行分区，所以Tez是在提交时一下子确定所有任务的Reduce个数，所以有可能后续的Reduce个数很多,造成计算资源的浪费。

由于MapReduce计算框架使用非常广泛，并且长时间持续优化，所以在物理执行计划比Tez要优化很多，会合并一些Job，减少任务个数。

MapReduce和Tez框架各有优缺点，所以并不是一个框架一定比另的框架更好，要看具体的执行SQL和数据量。Hive调度系统是专门开发的用于调度任务的软件。

调度系统是Master Slave架构，Master负责任务的管理和Slave的管理。Slave是任务真正执行的服务器。Slave启动时向Master注册本Slave能并行执行的任务个数和执行机的组名，相同执行机组名的若干个执行机的配置参数相同。Master负责所有任务的调度，所有的任务都有所属的执行机的组名，那么任务可以分配到该执行机的组的任意一台执行机中。当定时任务到启动时间时，或者非定时任务的所有所依赖的任务都执行完毕时，该任务被添加到任务所配执行机的组名的队列中。有一个调度线程，如果执行机组的某执行机正在执行的任务数没有到达该执行机能并行执行任务的上限，则从该执行机的所在组的队列中取出一个任务，放到该执行机上运行。

现有技术，涉及到执行引擎的大的变更时，一般是在调度系统中手动为每个任务配置相关参数。如果配置参数后的执行时间比以前长，则恢复配置。否则继续保留新配置。现有技术的缺点在于：

1.对于调度系统中大量的任务都采用手工配置的方式，无疑增加了人工负担，现实中每人都有开发任务，没有这么多人力每个任务配置,并且在配置后还要观察任务是否执行时间缩短。

2.用户要记录哪些任务被配置，哪些任务没有被配置，需要设置配置计划等工作。而且在配置中如果参数配置出错，则会造成新的失败风险。

3.由于新的配置可能导致任务运行出错，如果是新的配置出错，则自动重试后还是会出错。后续任务无法运行。影响范围进一步扩大。必须在收到告警信息后才能进行手工处理，可能引起大量任务延迟。

【发明内容】

本申请的多个方面提供一种HIVE任务执行引擎选择方法和系统，用以进行小程序性能测试，提高测试的效率和准确性。

本申请的一方面，提供一种HIVE任务执行引擎选择方法，包括：

计算任务拓扑图中的关键路径；

计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务；

对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，计算任务拓扑图中的关键路径包括：

在任务拓扑图中，根据任务拓扑排序和各任务执行时间计算出执行时间最长的路径作为关键路径。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，根据所述可延迟时间选择可用新的执行引擎执行的任务包括：

选择所述可延迟时间大于执行时间的任务作为可用新的执行引擎执行的任务。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎包括：

选择执行时间短于上次执行时间的执行引擎，并将所述执行引擎的名称记录在任务属性中。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述方法还包括：

对关键路径上所选择的任务测试新的执行引擎后，如果任务运行时间减少，则重新计算关键路径，重复测试步骤。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述方法还包括：

对根据所述可延迟时间而未选择的任务的执行引擎进行调整。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，对根据所述可延迟时间而未选择的任务的执行引擎进行调整包括：

将根据所述可延迟时间而未选择的任务组成拓扑图，同一路径中仅任务变更执行引擎执行时间缩短后继续变更后续任务的执行引擎。

本申请的另一方面，公开了一种HIVE任务执行引擎选择系统，包括：

关键路径计算模块，关于计算任务拓扑图中的关键路径；

任务选择模块，用于计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务；

测试模块，用于对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述关键路径计算模块具体用于：

在任务拓扑图中，根据任务拓扑排序和各任务执行时间计算出执行时间最长的路径作为关键路径。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述任务选择模块具体用于：

选择所述可延迟时间大于执行时间的任务作为可用新的执行引擎执行的任务。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述测试模块具体用于：

选择执行时间短于上次执行时间的执行引擎，并将所述执行引擎的名称记录在任务属性中。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述系统还包括调度模块，用于对关键路径上所选择的任务测试新的执行引擎后，如果任务运行时间减少，则重复测试。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述系统还包括调整模块，用于对根据所述可延迟时间而未选择的任务的执行引擎进行调整。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述调整模块具体用于：

将根据所述可延迟时间而未选择的任务组成拓扑图，同一路径中仅任务变更执行引擎执行时间缩短后，继续变更后续任务的执行引擎。

本发明的另一方面，提供一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

本发明的另一方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如以上所述的方法。

由所述技术方案可知，本申请实施例，减少了对调度系统进行任务配置所需要的人力资源，减少了参数配置出错的失败风险；避免了配置出错引起的任务延迟。

【附图说明】

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

图1为本申请一些实施例提供的HIVE任务执行引擎选择方法的流程示意图；

图2为本申请一些实施例的拓扑图；

图3为本申请一些实施例的任务的可延迟时间示意图；

图4为本申请一些实施例的调整任务的可延迟时间后的拓扑图；

图5为本申请一些实施例的未测试执行引擎变更任务的拓扑图；

图6为本申请一实施例提供的HIVE任务执行引擎选择系统的结构示意图；

图7示出了适于用来实现本发明实施方式的示例性计算机系统/服务器012的框图。

【具体实施方式】

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

图1为本申请一些实施例提供的HIVE任务执行引擎选择方法的流程示意图，如图1所示，包括以下步骤：

步骤S11、计算任务拓扑图中的关键路径；

优选地，根据任务的依赖关系和耗时计算出关键路径，区分关键路径上的任务和非关键路径上的任务。

优选地，如图2的拓扑图所示，圆形内的字符代表任务名称，旁边的数字代表任务的耗时,单位为分钟。任务之间的连线代表任务间的依赖。连线的不带箭头这边的任务代表被依赖任务。如任务“B”依赖任务”A”。离开顶点的边的个数叫顶点的出度，代表被依赖任务的个数。到达顶点的边的个数叫顶点的入度，代表依赖的任务的个数。如“A”的入度为0，代表没有依赖任务，出度为2，代表被两个任务依赖。

对所述拓扑图中的任务进行拓扑排序。拓扑排序是计算任务执行顺序的一种方法。如每天0点，任务“A”开始运行，之后的运行顺序是这样计算的。当一个任务运行时，被依赖的任务必须完成。如任务“B”运行时，任务“A”必须完成。当一个任务完成时,系统删除所有以此任务为出度的边，如果删除后，某任务的入度为0，则代表所有依赖已经完成，则可以运行。如此不断循环，直到所有任务都运行完。

计算拓扑排序中的关键路径。关键路径是执行时间最长的路径，关键路径的计算过程如下：每个任务都有一个开始时间和结束时间。在拓扑排序中，如任务“A”的开始时间为0，结束时间为10；任务“D”的开始时间为10，结束时间为50；任务“F”的开始时间为50，结束时间为70；任务“E”的开始时间为70,结束时间为120；找到结束时间最长的任务，然后往前推，如果被依赖的任务的结束时间等于这个任务的开始时间，则循环往前找，直到找到没有依赖的任务。如此组成一个任务列表，如在此图中为A-D-F-E，即为关键路径。而另一条路径A-B-C-E为非关键路径。

关键路径有特殊的意义，代表了全部任务的最短可能完成完成时间。不论怎么调度，有多少任务可以同时运行，都不能少于关键路径上任务的执行时间之和。因此，关键路径上的任务要有最高的优先级，如任务A运行完后，如果资源紧张，要先运行任务D，然后才能运行非关键路径上的任务B。

步骤S12、计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务；

每个任务的可延迟时间，是这个任务的最晚开始执行时间，在这个最晚执行时间前执行，下一个任务的结束时间在规定时间内。每个任务的可延迟时间用Delta表示。Delta可正可负，正代表可以延迟的时间，负代表为了它的后续任务不能在规定的时间完成，已经延后的时间。为了计算所有任务的可延迟时间，把任务之间的连线的箭头指向反过来，如图3所示。

从最后的任务开始，每个任务的delta为(上一个任务的delta+(上一个任务的开始时间-此任务的结束时间)，如果没有上一个任务，则delta为(规定完成时间-任务结束时间)，在此上一个任务是原任务的下游任务，因为箭头方向反过来了。最开如上面的所有任务规定必须在150分钟内完成。每个任务的delta则任务“E”的delta为150-120＝30，代表E最多可以延迟30分钟运行。

任务在执行时，只选择delta大于执行时间的任务来尝试先用新的执行引擎执行。因为我们如果新的执行引擎失败或者在规定的时间内没有完成，则需要用旧的执行引擎重新运行，而不改变所有任务的最后完成时间。

步骤S13、对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎；

优选地，为每个任务添加属性：

is_execution_engine_tested:是否经过调度测试新的执行引擎,没有经过测试的为false,执行过测试的为true；

Execution_engine_name:执行引擎名称，值为mapreduce或tez。

优选地，任务的默认执行引擎为mapreduce。

在执行过程中，要根据任务的实际结束时间动态调整delta，如B的delta＝(delta+上次开始运行时间-本次开始运行时间),即本次开始运行时间比上次早，则delta增大，否则减少。

如果某任务的delta值比上次任务的执行时间大，则设置is_execution_engine_tested为true，execution_engine_name为tez；然后执行该任务；执行后监控该任务，如果已经运行了上次的执行时间仍没有结束，则杀死该任务，设置execution_engine_name为mapreduce，然后重新执行。后续这些任务运行时，如果is_execution_engine_tested为true，则不论是什么值，则都按照值设置。

通过本步骤，得到了使任务的执行时间更短的执行引擎。

步骤S14、重复上述步骤，直至确定每个任务的执行引擎。

通过为任务选择新执行引擎，任务的执行时间缩短，进而关键路径上的任务运行时间减少，很可能导致原关键路径的任务运行时间短于原非关键路径，因此，需要调整运行的顺序，重新计算关键路径，计算关键路径上每个任务的可延迟时间，选择可用新的执行引擎执行的任务；对所选择的任务测试新的执行引擎，动态调整任务的可延迟时间。

如图4所示，任务D运行了20分钟就结束了，这时任务B也结束。这个时候应该优先运行任务C，因为A-B-C-E变成了关键路径。

在任务的调度过程中，判断任务优先级的最好方法是用delta,delta值越小的任务的优先级越高。如任务A运行后，同时运行任务B和任务D，在任务B和任务D同时结束之后，任务F的delta值为50，而任务C的delta值变为40。所以C优先运行。

进过几轮调度后，当关键路径的任务运行时间不再减少，即无需调整运行顺序，调度结束。

优选地，所述方法还包括步骤S15、对根据所述可延迟时间而未选择的任务的执行引擎进行调整。

经过几轮的调度之后，大部分的任务的执行引擎已经确定，而少数的几个任务由于没有足够的delta而不能按上面的方法确定，这时可以采用概率的方法，执行引擎设置为tez的任务的数量除以is_execution_engine_tested设置为true的任务数量，如果大于0.5，则表示大部分任务设置执行引擎为tez能缩短执行时间，按照以下的方法调整。

举个例子如图5所示，任务2、任务3、任务4、任务5、任务6为未测试执行引擎变更的任务。

为了避免影响很大，如果从最后的任务中，同一个路径上只允许一个任务失败。如任务2运行失败，则不再尝试任务3。因为任务2失败则任2占用了2倍的执行时间。如果某任务变更执行引擎后，执行时间缩短，则后续任务仍可以继续变更。即将根据所述可延迟时间而未选择的任务组成拓扑图，同一路径中仅任务变更执行引擎执行时间缩短后继续变更后续任务的执行引擎。

具体算法如下：

为每个任务增加line_test_failed字段，代表所在路径是否有任务失败，默认为false。如2开始运行时line_test_failed为false，则变更执行引擎，在规定的时间没有完成，则杀死，把执行引擎重新设置为mapreduce。则把后续任务的line_test_failed设置为true。后续任务3执行时，line_test_failed为true，则不变更引擎。任务3运行后，把任务5的line_test_failed也设置为true。

任务4运行的时候line_test_failed为false。变更执行引擎成功后，不设置后续任务的line_test_failed。任务F执行时，还可以变更执行引擎。任务6如果变更成功，则不再设置任务5的line_test_failed。因为任务5的line_test_failed被任务3结束时已经设置，所以这一轮后，任务3和任务5没有变更执行引擎。

下一轮执行时，任务3先执行变更执行引擎测试，如果成功，则任务5也进行变更测试。如果任务3不成功，则任务5等到下一轮调度时再尝试。

执行多轮调度，直至各任务测试完成。

优选地，通过本实施例所述方法，实现了调度系统中HIVE任务执行引擎的自动配置，无需人工进行手工配制，节约了人力；自动处理配置错误，避免了配置出错后等待人工处理引起的人物延迟。

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

以上是关于方法实施例的介绍，以下通过装置实施例，对本发明所述方案进行进一步说明。

图6为本申请一些实施例提供的HIVE任务执行引擎选择系统的结构示意图，如图6所示，包括：

关键路径计算模块61，用于计算任务拓扑图中的关键路径；

优选地，根据任务的依赖关系和耗时计算出关键路径，区分关键路径上的任务和非关键路径上的任务。

优选地，如图2的拓扑图所示，圆形内的字符代表任务名称，旁边的数字代表任务的耗时,单位为分钟。任务之间的连线代表任务间的依赖。连线的不带箭头这边的任务代表被依赖任务。如任务“B”依赖任务”A”。离开顶点的边的个数叫顶点的出度，代表被依赖任务的个数。到达顶点的边的个数叫顶点的入度，代表依赖的任务的个数。如“A”的入度为0，代表没有依赖任务，出度为2，代表被两个任务依赖。

对所述拓扑图中的任务进行拓扑排序。拓扑排序是计算任务执行顺序的一种方法。如每天0点，任务“A”开始运行，之后的运行顺序是这样计算的。当一个任务运行时，被依赖的任务必须完成。如任务“B”运行时，任务“A”必须完成。当一个任务完成时,系统删除所有以此任务为出度的边，如果删除后，某任务的入度为0，则代表所有依赖已经完成，则可以运行。如此不断循环，直到所有任务都运行完。

计算拓扑排序中的关键路径。关键路径是执行时间最长的路径，关键路径的计算过程如下：每个任务都有一个开始时间和结束时间。在拓扑排序中，如任务“A”的开始时间为0，结束时间为10；任务“D”的开始时间为10，结束时间为50；任务“F”的开始时间为50，结束时间为70；任务“E”的开始时间为70,结束时间为120；找到结束时间最长的任务，然后往前推，如果被依赖的任务的结束时间等于这个任务的开始时间，则循环往前找，直到找到没有依赖的任务。如此组成一个任务列表，如在此图中为A-D-F-E，即为关键路径。而另一条路径A-B-C-E为非关键路径。

关键路径有特殊的意义，代表了全部任务的最短可能完成完成时间。不论怎么调度，有多少任务可以同时运行，都不能少于关键路径上任务的执行时间之和。因此，关键路径上的任务要有最高的优先级，如任务A运行完后，如果资源紧张，要先运行任务D，然后才能运行非关键路径上的任务B。

任务选择模块62，用于计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务。

每个任务的可延迟时间，是这个任务的最晚开始执行时间，在这个最晚执行时间前执行，下一个任务的结束时间在规定时间内。每个任务的可延迟时间用Delta表示。Delta可正可负，正代表可以延迟的时间，负代表为了它的后续任务不能在规定的时间完成，已经延后的时间。为了计算所有任务的可延迟时间，把任务之间的连线的箭头指向反过来，如图3所示。

从最后的任务开始，每个任务的delta为(上一个任务的delta+(上一个任务的开始时间-此任务的结束时间)，如果没有上一个任务，则delta为(规定完成时间-任务结束时间)，在此上一个任务是原任务的下游任务，因为箭头方向反过来了。最开如上面的所有任务规定必须在150分钟内完成。每个任务的delta则任务“E”的delta为150-120＝30，代表E最多可以延迟30分钟运行。

任务在执行时，只选择delta大于执行时间的任务来尝试先用新的执行引擎执行。因为我们如果新的执行引擎失败或者在规定的时间内没有完成，则需要用旧的执行引擎重新运行，而不改变所有任务的最后完成时间。

测试模块63，用于对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎。

每个任务添加属性：

is_execution_engine_tested:是否经过调度测试新的执行引擎,没有经过测试的为false,执行过测试的为true；

Execution_engine_name:执行引擎名称，值为mapreduce或tez。

优选地，任务的默认执行引擎为mapreduce。

在执行过程中，要根据任务的实际结束时间动态调整delta，如B的delta＝(delta+上次开始运行时间-本次开始运行时间),即本次开始运行时间比上次早，则delta增大，否则减少。如果某任务的delta值比上次任务的执行时间大，则设置is_execution_engine_tested为true，execution_engine_name为tez；然后执行该任务；执行后监控该任务，如果已经运行了上次的执行时间仍没有结束，则杀死该任务，设置execution_engine_name为mapreduce，然后重新执行。后续这些任务运行时，如果is_execution_engine_tested为true，则不论是什么值，则都按照值设置。

通过本步骤，得到了使任务的执行时间更短的执行引擎。

调度模块64，用于重复调度上述模块，直至确定确定每个任务的执行引擎。

如果关键路径上的任务运行时间减少，要调整运行的顺序，重新计算关键路径，计算关键路径上每个任务的可延迟时间，选择可用新的执行引擎执行的任务；对所选择的任务测试新的执行引擎，动态调整任务的可延迟时间。

如图4所示，任务D运行了20分钟就结束了，这时任务B也结束。这个时候应该优先运行任务C，因为A-B-C-E变成了关键路径。

在任务的调度过程中，判断任务优先级的最好方法是用delta,delta值越小的任务的优先级越高。如任务A运行后，同时运行任务B和任务D，在任务B和任务D同时结束之后，任务F的delta值为50，而任务C的delta值变为40。所以C优先运行。

进过几轮调度后，当关键路径的任务运行时间不再减少，即无需调整运行顺序，调度结束。

优选地，所述系统还包括调整模块65，用于对根据所述可延迟时间而未选择的任务的执行引擎进行调整。

经过几轮的调度之后，大部分的任务的执行引擎已经确定，而少数的几个任务由于没有足够的delta而不能按上面的方法确定，这时可以采用概率的方法，执行引擎设置为tez的任务的数量除以is_execution_engine_tested设置为true的任务数量，如果大于0.5，则表示大部分任务设置执行引擎为tez能缩短执行时间，按照以下的方法调整。

举个例子如图5所示，任务2、任务3、任务4、任务5、任务6为未测试执行引擎变更的任务。

为了避免影响很大，如果从最后的任务中，同一个路径上只允许一个任务失败。如任务2运行失败，则不再尝试任务3。因为任务2失败则任2占用了2倍的执行时间。如果某任务变更执行引擎后，执行时间缩短，则后续任务仍可以继续变更。即将根据所述可延迟时间而未选择的任务组成拓扑图，同一路径中仅任务变更执行引擎执行时间缩短后继续变更后续任务的执行引擎。

具体算法如下：

为每个任务增加line_test_failed字段，代表所在路径是否有任务失败，默认为false。如2开始运行时line_test_failed为false，则变更执行引擎，在规定的时间没有完成，则杀死，把执行引擎重新设置为mapreduce。则把后续任务的line_test_failed设置为true。后续任务3执行时，line_test_failed为true，则不变更引擎。任务3运行后，把任务5的line_test_failed也设置为true。

任务4运行的时候line_test_failed为false。变更执行引擎成功后，不设置后续任务的line_test_failed。任务F执行时，还可以变更执行引擎。任务6如果变更成功，则不再设置任务5的line_test_failed。因为任务5的line_test_failed被任务3结束时已经设置，所以这一轮后，任务3和任务5没有变更执行引擎。

下一轮执行时，任务3先执行变更执行引擎测试，如果成功，则任务5也进行变更测试。如果任务3不成功，则任务5等到下一轮调度时再尝试。

执行多轮调度，直至各任务测试完成。

优选地，通过本实施例所述系统，实现了调度系统中HIVE任务执行引擎的自动配置，无需人工进行手工配制，节约了人力；自动处理配置错误，避免了配置出错后等待人工处理引起的人物延迟。

在所述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

图7示出了适于用来实现本发明实施方式的示例性计算机系统/服务器012的框图。图7显示的计算机系统/服务器012仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统/服务器012以通用计算设备的形式表现。计算机系统/服务器012的组件可以包括但不限于：一个或者多个处理器或者处理单元016，系统存储器028，连接不同系统组件(包括系统存储器028和处理单元016)的总线018。

总线018表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

计算机系统/服务器012典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机系统/服务器012访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

系统存储器028可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)030和/或高速缓存存储器032。计算机系统/服务器012可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统034可以用于读写不可移动的、非易失性磁介质(图7未显示，通常称为“硬盘驱动器”)。尽管图7中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线018相连。存储器028可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。

具有一组(至少一个)程序模块042的程序/实用工具040，可以存储在例如存储器028中，这样的程序模块042包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块042通常执行本发明所描述的实施例中的功能和/或方法。

计算机系统/服务器012也可以与一个或多个外部设备014(例如键盘、指向设备、显示器024等)通信，在本发明中，计算机系统/服务器012与外部雷达设备进行通信，还可与一个或者多个使得用户能与该计算机系统/服务器012交互的设备通信，和/或与使得该计算机系统/服务器012能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口022进行。并且，计算机系统/服务器012还可以通过网络适配器020与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图7所示，网络适配器020通过总线018与计算机系统/服务器012的其它模块通信。应当明白，尽管图7中未示出，可以结合计算机系统/服务器012使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

处理单元016通过运行存储在系统存储器028中的程序，从而执行本发明所描述的实施例中的功能和/或方法。

上述的计算机程序可以设置于计算机存储介质中，即该计算机存储介质被编码有计算机程序，该程序在被一个或多个计算机执行时，使得一个或多个计算机执行本发明上述实施例中所示的方法流程和/或装置操作。

随着时间、技术的发展，介质含义越来越广泛，计算机程序的传播途径不再受限于有形介质，还可以直接从网络下载等。可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (16)

1.一种H IVE任务执行引擎选择方法，其特征在于，包括：

计算任务拓扑图中的关键路径；

计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务；

对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎。

2.根据权利要求1所述的方法，其特征在于，计算任务拓扑图中的关键路径包括：

在任务拓扑图中，根据任务拓扑排序和各任务执行时间计算出执行时间最长的路径作为关键路径。

3.根据权利要求1所述的方法，其特征在于，根据所述可延迟时间选择可用新的执行引擎执行的任务包括：

选择所述可延迟时间大于执行时间的任务作为可用新的执行引擎执行的任务。

4.根据权利要求1所述的方法，其特征在于，对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎包括：

选择执行时间短于上次执行时间的执行引擎，并将所述执行引擎的名称记录在任务属性中。

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

对关键路径上所选择的任务测试新的执行引擎后，如果任务运行时间减少，则重新计算关键路径，重复测试步骤。

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

对根据所述可延迟时间而未选择的任务的执行引擎进行调整。

7.根据权利要求6所述的方法，其特征在于，对根据所述可延迟时间而未选择的任务的执行引擎进行调整包括：

将根据所述可延迟时间而未选择的任务组成拓扑图，同一路径中仅任务变更执行引擎执行时间缩短后继续变更后续任务的执行引擎。

8.一种H IVE任务执行引擎选择系统，其特征在于，包括：

关键路径计算模块，关于计算任务拓扑图中的关键路径；

任务选择模块，用于计算所述关键路径上每个任务的可延迟时间，根据所述可延迟时间选择可用新的执行引擎执行的任务；

测试模块，用于对所选择的任务测试新的执行引擎，根据测试结果确定所选择的任务的执行引擎。

9.根据权利要求8所述的系统，其特征在于，所述关键路径计算模块具体用于：

在任务拓扑图中，根据任务拓扑排序和各任务执行时间计算出执行时间最长的路径作为关键路径。

10.根据权利要求8所述的系统，其特征在于，所述任务选择模块具体用于：

选择所述可延迟时间大于执行时间的任务作为可用新的执行引擎执行的任务。

11.根据权利要求8所述的系统，其特征在于，所述测试模块具体用于：

选择执行时间短于上次执行时间的执行引擎，并将所述执行引擎的名称记录在任务属性中。

12.根据权利要求8所述的系统，其特征在于，所述系统还包括调度模块，用于对关键路径上所选择的任务测试新的执行引擎后，如果任务运行时间减少，则重复测试。

13.根据权利要求8所述的系统，其特征在于，所述系统还包括调整模块，用于对根据所述可延迟时间而未选择的任务的执行引擎进行调整。

14.根据权利要求13所述的系统，其特征在于，所述调整模块具体用于：

将根据所述可延迟时间而未选择的任务组成拓扑图，同一路径中仅任务变更执行引擎执行时间缩短后，继续变更后续任务的执行引擎。

15.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1～7中任一项所述的方法。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1～7中任一项所述的方法。