[0001] 本发明涉及信息处理领域，特别涉及一种任务调度方法及一种任务调度装置。

[0002] Hadoop是一个基于Java实现的、开源的、包含分布式文件系统和MapReduce计算框架的项目，分布式开源系统Hadoop通过文件系统和计算系统的分离，各个计算节点无共享数据，实现机器的线性扩展，通过使用MapReduce计算模型实现计算方法的归一化，MapReduce计算模型将数据分析过程分为两个阶段：用以实现数据分拣&分堆的map阶段、用以实现数据汇总的reduce阶段，从而解决了海量数据的线性计算，主要是解决数据量大的问题。

[0003] Hive是Apache名下的开源SQL解析引擎，是基于Hadoop的一个数据仓库工具，可以将SQL(Structured Query Language，结构化查询语言，一种用于访问和处理数据库的标准的计算机语言)语句转换为MapReduce任务运行，从而实现了编程方法的简单化和结构化，熟悉SQL语句，就可以快速实现复杂的计算，提高了开发效率。

[0004] 但是基于Hadoop+Hive的解决方案，当任务之间存在依赖关系时，比如数据的计算必须等待数据的入库完成之后，需要通过其他方法来保证任务的顺序执行。目前保证任务能够顺序执行的方式，以数据的计算必须等待数据的入库完成为例，是在数据入库任务脚本完成之后生成一个文件，数据计算任务脚本启动之前先检测这个文件是否存在，不存在则需要等待，直至检测到有这个文件。基于这种方式，需要配置各任务执行的共享文件，配置过程比较复杂，且在各任务执行过程中，需要持续不断地向该共享区域写文件和读文件，过多的读写次数会严重影响到任务执行的效率。

[0025] 为使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步的详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不限定本发明的保护范围。

[0026] 图1示出了本发明一个实施例中的工作环境示意图。任务调度节点101与一个以上的任务执行节点102连接，任务调度节点101在检测到达到某个任务的触发条件时，分析该任务是否可以下发执行，若可以，将该任务下发给任务执行节点102进行执行。任务调度节点101下发的各任务之间可能会存在某种依赖关系，例如对数据的计算必须等待数据的入库，那么，数据计算任务依赖于数据入库任务的完成，需在数据入库任务完成之后才能保证该数据计算任务的正确执行。各任务之间的依赖关系可以通过任务依赖图来表示，该任务依赖图可以是一个有向无环图。该任务依赖图可存储在元数据存储节点103。元数据存储节点103中，还可以存储各任务的任务结果执行状态，例如执行成功、执行失败等等。

[0027] 图2示出了本发明另一个实施例的工作环境示意图，在该实施例中，相对于图1中所示的工作环境而言，还包括有配置展示节点100，用以对各任务的依赖关系进行配置，得到上述依赖关系图，得到的依赖关系图可以存储到元数据存储节点103。

[0028] 在图1、图2所示的工作环境中，各节点，包括配置展示节点100、任务调度节点101、任务执行节点102以及元数据存储节点103，可以分别采用独立的机器设备实现，以实现机器级别的任务调度。

[0029] 以各节点分别采用独立的机器设备实现为例，假设该任务调度节点101为任务调度设备服务器，图3中示出了一个实施例中的任务调度服务器101的结构示意图。如图3所示，该任务调度服务器101包括通过系统总线连接的处理器、存储介质、通信接口、电源接口和内存。其中，任务调度服务器101的存储介质存储有一种任务调度装置，该装置用于实现一种任务调度方法。任务调度服务器101的通信接口用于与配置展示节点100、各任务执行节点102以及元数据存储节点103连接和通信，任务调度服务器101的电源接口用于与外部电源连接，外部电源通过该电源接口向任务调度服务器101供电。

[0030] 结合图1、图2、图3所示的示意图，图4中示出了一个实施例中的任务调度方法的流程示意图，该方法实施于上述任务调度节点101。

[0031] 如图4所示，本实施例中的任务调度方法包括步骤：

[0032] S401：在达到当前任务触发条件时，触发当前任务；

[0033] S402：根据任务依赖图判断该当前任务是否有依赖的任务，若有，进入步骤S403；

[0034] 步骤S403：获取所依赖的各任务的任务执行结果状态，所述任务依赖图为各任务之间的依赖关系的有向无环图；

[0035] 步骤S404：根据所依赖的各任务的任务结果执行状态，判断所依赖的各任务是否均执行成功，若是，进入步骤S405；

[0036] 步骤S405：将所述当前任务下发给任务执行节点执行。

[0037] 根据如上所述的本发明实施例的方案，其基于任务依赖图来体现数据任务流、计算任务流等任务之间的依赖关系，在达到当前任务的触发条件时，先基于任务依赖图获得该当前任务所依赖的任务，并在所依赖的各任务的任务执行结果状态均为执行成功的情况下，才将该任务下发执行。其无需频繁地进行写文件和读文件的操作，直接基于任务执行结果状态即可确定所依赖的任务是否执行成功，克服了频繁的文件检查操作造成的任务执行效率低和可靠性低的问题，且避免了执行过程中才判定所依赖任务是否执行成功所造成的浪费资源和效率低下的问题，提高了存在依赖关系的各任务进行调度时的任务执行效率。

[0038] 其中，在上述步骤S404中判定当前任务所依赖的各任务中至少有一个未执行成功时，执行等待过程，说明当前任务无法执行，开始执行等待过程，并在等待时间大于或者等于预设超时时间阈值时，判定所述当前任务执行失败，发出失败告警信息。若在预设超时时间阈值内所依赖的各任务均执行完毕，则将该当前任务下发给任务执行节点执行。

[0039] 在将当前任务下发后，任务执行节点会执行该当前任务，并基于任务执行结果返回任务执行返回码。任务调度节点会接收任务执行节点返回的任务执行返回码，并基于任务执行返回码判断该任务执行节点执行当前任务是否成功。

[0040] 如果任务执行节点执行当前任务成功，则认为该当前任务执行成功，并更新当前任务的任务结果执行状态，以便于依赖于该当前任务的后续任务能够顺利执行。

[0041] 其中，在判断该任务执行节点执行当前任务不成功时，还可以进一步判断是否达到任务失败重试结束条件。

[0042] 若未达到任务失败重试结束条件，则将所述当前任务发送给另一个任务执行节点执行，直至某一个任务执行节点执行该当前任务成功或者达到任务失败重试结束条件，以避免任务执行节点出现故障导致的任务执行失败，实现机器级别的容错机制。

[0043] 若达到任务失败重试结束条件，则可以判定所述当前任务执行不成功，并更新当前任务的任务结果执行状态。

[0044] 其中，上述任务失败重试结束条件，可以采用各种可能的方式设置，例如设置任务执行时间、任务重试次数等等。在本发明的一个实施例中，将任务失败重试结束条件设置为预定失败重试次数阈值，并在当前任务的重试次数达到预定失败重试次数阈值时，判定达到任务失败重试结束条件。

[0045] 在上述当前任务执行成功后，还可以进一步判断当前任务是否为故障恢复后的执行任务，若是，则根据任务依赖图的顺序，触发当前任务的后续任务，直至后续无任务或者后续任务没有到达运行时间。提高了任务执行失败时的任务链恢复效率。

[0046] 如上所述，本发明实施例的基本思想，是实现数据流、计算流等任务的抽象，使用有向无环的任务依赖图来解决依赖关系，任务之间的依赖关系可以通过人工在配置展示节点100进行配置，配置得到的任务依赖图可以存储在元数据存储节点103，且各任务可以在固定的时间内定时触发。

[0047] 以下结合图5中所示的任务依赖图、图6示出的任务调度方法的交互流程示意图，就其中的一个任务调度过程进行举例说明。

[0048] 如图5所示，在该任务依赖图中，总共有四个任务：任务A、任务B、任务C、任务D，其中，任务B、任务C依赖于任务A，任务D依赖于任务B和任务C，该任务依赖图中的各个有向边可存储在元数据存储节点103中。

[0049] 如上所述，在该示例说明中，各任务是定时触发，假设当前到达了任务C的运行时间，当前任务为任务C。

[0050] 结合图6所示，在步骤S601中，任务调度节点会检测是否达到当前任务触发条件，即在到达任务C的运行时间时，判定达到任务C触发条件，并在步骤S602中进行定时触发。

[0051] 在触发当前任务C后，在步骤S603中，任务调度节点基于任务依赖图判断该任务C是否有依赖的任务，其中，该任务依赖图可以存储在任务调度节点本地，任务调度节点直接基于本地存储的任务依赖图即可判定，另一方面，该任务依赖图可以从元数据存储节点获取(该过程未在图6中示出)。

[0052] 若任务C有依赖的任务，则进入步骤S610，若任务C没有依赖的任务，则进入步骤S620。

[0053] 在步骤S610中，任务调度节点从元数据存储节点获得任务C所依赖的各任务的任务执行结果状态，并在步骤S611中判断所依赖的任务是否均执行成功。结合图5所示，则任务调度节点是从元数据存储节点获得任务A的任务结果执行状态，并判断任务A是否执行成功。

[0054] 若步骤S611的判定结果为否，即所依赖的任务至少有一个执行不成功，则进入步骤S612执行任务等待状态，并在步骤S613中对等待时间是否到达预设超时时间阈值进行监测，若在到达预设超时时间阈值时仍然有至少一个所依赖的任务执行不成功，则在步骤S614中发出任务C失败告警信息，该失败告警信息可以通过短信、微信等通信方式告知运维人员。运维人员在步骤S615中可分析任务C失败的根本问题并对其进行解决，例如机器故障恢复、数据量太大的分拆等等，并在故障问题解决后，可手动一键恢复任务C，然后可返回步骤S601重新触发该任务C。

[0055] 若步骤S611中判定任务C所依赖的各任务均执行成功，则进入步骤S620，若在步骤S613中监测到未到达预设超时时间阈值之前、任务C所依赖的各任务均执行成功，则进入步骤S620。

[0056] 在步骤S620中，任务调度节点将任务C下发给任务执行节点1，任务执行节点1执行该任务C，并在步骤S621中返回任务C的执行返回码。

[0057] 任务调度节点在接收到任务执行节点1返回的执行返回码后，在步骤S622中基于该执行返回码判断任务执行节点1执行该任务C是否成功，若任务执行节点1在执行该任务C成功，则认为该任务C执行成功，并进入步骤S627，基于该任务C的执行结果更新数据库，即将元数据存储节点中的任务C的任务执行结果状态更新为执行成功。

[0058] 若基于执行返回码判断出任务执行节点1执行任务C不成功，则进入步骤S623，任务调度节点判断是否达到该任务C的任务失败重试结束条件，例如，该任务C的重试次数是否达到预定失败重试次数阈值，若未达到，则进入步骤S624，将该任务C下发给另一任务执行节点K，任务执行节点K执行该任务C，并在步骤S625中返回任务C的执行返回码。

[0059] 任务调度节点在接收到任务执行节点K返回的执行返回码后，返回步骤S622，采用与步骤S622中同样的方式，基于步骤S62,5中的执行返回码判断任务执行节点K执行该任务C是否成功，若任务执行节点K执行该任务C成功，则认为该任务C执行成功，并进入步骤S627，若任务执行节点K执行该任务C不成功，则进入步骤S623。

[0060] 若步骤S623中判定达到该任务C的任务失败重试结束条件，则在步骤S626中判定该任务C执行失败。基于预定失败重试次数阈值的设置，只有在任务的重试次数达到或者超过预定失败重试次数阈值，任务调度节点才会认为该任务执行失败，记录失败信息，从而可以实现分布式调度，防止因为其中一台机器故障导致的任务失败，实现了机器级别的容灾。

[0061] 任务调度节点在步骤S626中判定任务C执行失败后，进入步骤S627，基于该任务C的执行结果更新数据库，即将元数据存储节点中的任务C的任务执行结果状态更新为执行失败。同时可进入步骤S614，发出任务C失败告警信息，运维人员可基于该失败告警信息对故障进行清除。

[0062] 在任务C执行成功的情况下，在步骤S627中更新数据库后，可进入步骤S628，判断该任务C是否为故障恢复任务。这是因为，该任务C的执行可能是基于前面故障恢复进一步拉起的任务，例如任务A执行失败、对任务A执行失败的原因解决后基于任务依赖图拉起的任务，或者是任务C本身执行失败后、对任务C执行失败的原因解决后重新触发的任务。而在故障任务解决的过程中，后续其他任务已经到达了触发时间，而由于任务依赖关系的存在，会导致后续一系列任务的执行失败。此时，若要逐个重新手动恢复各任务，尤其是在故障恢复时间较长的情况下，会造成极大的运维工作量。

[0063] 此时，若在步骤S628中判定出该任务C为故障恢复任务，则进入步骤S629，基于任务依赖图中的顺序，触发任务C的后续任务，直至后续无任务或者后续任务没有到达运行时间，从而可以提高任务执行失败时的任务链恢复效率。

[0064] 基于与上述任务调度方法相同的思想，本发明实施例还提供一种任务调度装置。图7中示出了一个实施例中的任务调度装置的结构示意图。该任务调度装置设置于图1、2所示的任务调度节点101。

[0065] 如图7所示，本实施例中的任务调度装置包括有：

[0066] 任务触发模块701，用于判断是否达到任务触发条件，并在达到当前任务触发条件时，触发当前任务；

[0067] 任务依赖性确定模块702，用于根据任务依赖图判断所述当前任务是否有依赖的任务，所述任务依赖图为各任务之间的依赖关系的有向无环图；

[0068] 任何可执行性确定模块703，用于在任务依赖性确定模块702的判定结果为是时，获取所依赖的各任务的任务执行结果状态，根据所依赖的各任务的任务结果执行状态，判断所依赖的各任务是否均执行成功；

[0069] 任务处理模块704，用于在任务依赖性确定模块702的判定结果为否时，或者任务可执行性确定模块703的判定结果为是时，将所述当前任务进行下发给任务执行节点执行。

[0070] 根据如上所述的本发明实施例的方案，其基于任务依赖图来体现数据任务流、计算任务流等任务之间的依赖关系，在达到当前任务的触发条件时，先基于任务依赖图获得该当前任务所依赖的任务，并在所依赖的各任务的任务执行结果状态均为执行成功的情况下，才将该任务下发执行。其无需频繁地进行写文件和读文件的操作，直接基于任务执行结果状态即可确定所依赖的任务是否执行成功，克服了频繁的文件检查操作造成的任务执行效率低和可靠性低的问题，且避免了执行过程中才判定所依赖任务是否执行成功所造成的浪费资源和效率低下的问题，提高了存在依赖关系的各任务进行调度时的任务执行效率。

[0071] 其中，在上述任务可执行性确定模块703在判定当前任务所依赖的各任务至少有一个未执行成功时，还可以执行等待过程，并在等待时间大于或者等于预设超时时间阈值时，判定所述当前任务执行失败，发出失败告警信息，并更新所述当前任务的任务结果执行状态。若任务可执行性确定模块703监测到在预设超时时间阈值内所依赖的各任务均执行完毕，则仍然将该当前任务下发给任务执行节点执行。

[0072] 在将当前任务下发后，任务执行节点会执行该当前任务，并基于任务执行结果返回任务执行返回码。任务调度节点会接收任务执行节点返回的任务执行返回码，并基于任务执行返回码判断该任务执行节点执行当前任务是否成功。

[0073] 基于此，在一个具体示例中，

[0074] 上述任务处理模块704，还用于接收所述任务执行节点返回的任务执行返回码，并基于所述任务执行返回码判断所述任务执行节点执行当前任务是否成功，若是，判定所述当前任务执行成功，并更新所述当前任务的任务结果执行状态。

[0075] 若任务处理模块704基于所述任务执行返回码判定所述任务执行节点执行当前任务不成功，则可以进一步判断是否达到任务失败重试结束条件，若否，将所述当前任务发送给另一个任务执行节点执行。从而可以避免任务执行节点出现故障导致的任务执行失败，实现机器级别的容错机制。

[0076] 若任务处理模块704判定达到任务失败重试结束条件，则可以直接判定所述当前任务执行不成功，并更新所述当前任务的任务结果执行状态。

[0077] 其中，上述任务失败重试结束条件，可以采用各种可能的方式设置，例如设置任务执行时间、任务重试次数等等。在本发明的一个实施例中，可以将任务失败重试结束条件设置为预定失败重试次数阈值，并在当前任务的重试次数达到预定失败重试次数阈值时，判定达到任务失败重试结束条件。

[0078] 由于该当前任务的执行可能是基于前面故障恢复进一步拉起的任务，例如所依赖的任务执行失败、对所依赖的任务执行失败的原因解决后基于任务依赖图拉起的任务，或者是当前任务本身执行失败后、对当前任务执行失败的原因解决后重新触发的任务。而在故障任务解决的过程中，由于后续其他任务已经到达了触发时间，而由于任务依赖关系的存在，会导致后续一系列任务的执行失败。此时，若要逐个重新手动恢复各任务，尤其是在故障恢复时间较长的情况下，会造成极大的运维工作量。

[0079] 据此，在一个具体示例中，上述任务处理模块704，还可以在当前任务执行成功后，判断所述当前任务是否为故障恢复后的执行任务，此时，上述任务触发模块707，还用于在任务模块704判定当前任务为故障恢复后的执行任务时，根据任务依赖图的顺序，触发所述当前任务的后续任务，直至后续无任务或者后续任务没有达到触发条件。

[0080] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

[0081] 以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

[0082] 以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。