CN109710442A

CN109710442A - 一种任务的执行方法和装置

Info

Publication number: CN109710442A
Application number: CN201811567169.XA
Authority: CN
Inventors: 闫猛; 李涛
Original assignee: Kylin Seing Network Technology Ltd By Share Ltd
Current assignee: Kylin Seing Network Technology Ltd By Share Ltd
Priority date: 2018-12-20
Filing date: 2018-12-20
Publication date: 2019-05-03

Abstract

本申请实施例公开了一种任务的执行方法和装置，该方法包括：获取当前各数据链路中配置的任务的任务执行信息；如果所述任务执行信息中包括异常的任务执行信息，则输出所述异常的任务执行信息的提醒消息；根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型；根据所述目标任务所属的任务异常类型，确定所述目标任务的修复方式和相应的修复概率；根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理。利用本申请实施例，可以不需要管理人员通过人工操作的方式触发重新执行出现异常的任务，减少了频繁的人工操作，提高任务执行的效率。

Description

一种任务的执行方法和装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种任务的执行方法和装置。

背景技术

随着网络技术和终端技术的不断发展，用户通过网络和终端设备完成某一项业务已成为当前业务的主要处理方式，例如用户使用手机可以完成网上购物和支付转账等业务。而在各业务系统中，为了及时了解各项业务的服务状态，通常设置相应的告警系统，通过告警系统可以及时提醒管理人员对其中的异常信息进行处理。

当前，告警系统中会设置有告警的通知方式，如果某项业务或任务出现异常，告警系统能够及时的生成正确的通知消息，并将该通知消息通过设置的通知方式准确的推送给管理人员。而任务执行失败往往可以通过重新执行来进行恢复，因此，管理人员需要通过人工操作的方式触发相应的服务器重新执行该任务，或者，记录该任务的相关信息等。

然而，在大数据领域，随着数据链路日益复杂，需要设置的告警项也越来越多，而告警项越来越多时，管理人员需要花费大量时间去处理某些频繁发生的告警，例如需要频繁的通过人工操作的方式触发服务器重新执行相应任务等，从而使得任务执行的效率较低。

发明内容

本申请实施例的目的是提供一种任务的执行方法和装置，以实现重新执行出现异常的任务，减少频繁的人工操作，提高任务执行的效率。

为实现上述技术方案，本申请实施例是这样实现的：

本申请实施例提供的一种任务的执行方法，所述方法包括：

获取当前各数据链路中配置的任务的任务执行信息；

如果所述任务执行信息中包括异常的任务执行信息，则输出所述异常的任务执行信息的提醒消息；

根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型；

根据所述目标任务所属的任务异常类型，确定所述目标任务的修复方式和相应的修复概率；

根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理。

本申请实施例提供的一种任务的执行装置，所述装置包括：

信息获取模块，用于获取当前各数据链路中配置的任务的任务执行信息；

提醒模块，用于如果所述任务执行信息中包括异常的任务执行信息，则输出所述异常的任务执行信息的提醒消息；

异常类型确定模块，用于根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型；

修复方式确定模块，用于根据所述目标任务所属的任务异常类型，确定所述目标任务的修复方式和相应的修复概率；

任务修复模块，用于根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理。

由以上本申请实施例提供的技术方案可见，本申请实施例通过获取当前各数据链路中配置的任务的任务执行信息，如果该任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息，并根据该异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率，最终，可以根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理，这样，通过任务执行信息，确定出现异常的任务执行信息，进而可以确定出现异常的任务，然后，可以通过异常的任务执行信息对应的任务异常类型，确定相应的修复方式和修复概率，并基于该修复方式和修复概率对相应的任务进行修复，从而，设备可以通过修复方式自动修复出现异常的任务，或者提醒用户或技术人员按照修复方式进行修复，从而不需要管理人员通过人工操作的方式触发重新执行出现异常的任务，减少了频繁的人工操作，提高任务执行的效率。

附图说明

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

图1为本申请一种任务的执行方法实施例；

图2为本申请另一种任务的执行方法实施例；

图3为本申请又一种任务的执行方法实施例；

图4为本申请又一种任务的执行方法实施例；

图5为本申请一种任务的执行系统的结构示意图；

图6为本申请又一种任务的执行方法实施例；

图7为本申请又一种任务的执行方法实施例；

图8为本申请一种任务的执行装置实施例；

图9为本申请又一种任务的执行装置实施例；

图10为本申请又一种任务的执行装置实施例；

图11为本申请一种任务的执行设备实施例。

具体实施方式

本申请实施例提供一种任务的执行方法和装置。

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

实施例一

如图1所示，本申请实施例提供一种任务的执行方法，该方法可以应用于在某项任务在执行的过程中出现异常时重新执行该任务的处理中。该方法的执行主体可以为终端设备或服务器，其中，该终端设备可以如个人计算机等终端设备，服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。本申请实施例中以服务器为例进行详细说明，对于执行主体为终端设备的情况，可以参照服务器的情况执行，在此不再赘述。该方法具体可以包括以下步骤：

在步骤S102中，获取当前各数据链路中配置的任务的任务执行信息。

其中，数据链路可以是在数据通信网中，按一种链路协议的技术要求连接两个或多个数据站的链路，数据链路除了需要物理线路外，还需要通信协议来控制数据的传输，数据链路的本质可以是以数据传输为媒介构成的链路总和，可以包括链路、链路节点和链路关系等。任务可以是任意需要执行的任务，该任务可以包括如数据发送任务、数据接收任务等。任务执行信息可以是执行某一项任务的过程中所产生的相关信息，例如执行某项任务的执行者信息、执行的结果数据，执行该任务是否成功等信息。

在实施中，随着技术水平的不断提高，很多业务服务已从单单的线下，逐步发展为以线上为主，线上和线下共同发展的模式，这样，用户基于互联网，使用终端设备即可完成某一项业务，例如用户使用手机可以完成网上购物和支付转账等业务。由于不同业务需求用户提供的信息等可能不同，提供该业务服务的服务器的工作状态(如负载压力较大或CPU占用率较大等)在不同时刻可能不同，这样，有可能会导致该业务在处理的过程中出现异常。在各业务系统中，为了及时了解各项业务的服务状态，通常设置相应的告警机制，通过告警机制可以及时提醒管理人员对其中的异常信息进行处理。通常，常用的告警机制可以及时的将正确的通知使用正确的方式准确的推送给管理人员，但是在大数据领域，随着数据链路日益复杂，需要设置的告警项也越来越多。而告警项越来越多时，管理人员需要花费大量时间去处理某些频繁发生的告警。

此外，在数据链路发生异常时，相应的告警机制会发出相应的告警通知。而对于第一次发出告警通知的数据链路，而通常情况下，某数据链路第一次发生异常，往往是一种偶然情况，因此，对于该数据链路可以执行恢复程序，这样，可以在一定程度上减少人力资源的消耗。而对于无法通过恢复程序消除数据链路异常的情况，可以向相应的技术人员或用户提供修复方式等信息，以使技术人员或用户对相应的任务进行手动修复。

在大数据的数据处理过程中，为了数据分析或使用时尽可能灵活，每份数据会有很多中间状态。通过对数据的顺序处理，构成了数据处理链路，每个中间状态都是在执行数据清洗任务得来，每个任务均有输入数据和输出数据，但是，某数据链路可能会因为网络、设备内存、相关参数未找到、某模块执行异常等异常情况而导致个别任务执行失败。需要说明的是，对于重复的告警，告警平台将不再向管理人员发送，防止管理人员收到大量重复告警。

基于上述内容，可以根据需要处理的数据的顺序，确定数据的处理链路，从而形成数据链路。可以为每个数据链路配置任务，可以通过不同的数据链路完成相应的任务。而在执行数据链路中配置的各个任务的过程中，可以从中采集各个任务的任务执行信息。

在步骤S104中，如果上述任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息。

在实施中，当采集到各个任务的任务执行信息后，可以将采集到的任务执行信息存储在信息存储设备中，同时，可以对采集到的任务执行信息进行分析，例如，可以对采集到的任务执行信息进行分类，确定属于同一任务的任务执行信息，并可以在每个任务的任务执行信息中查找关于该任务是否执行成功的任务执行信息，或者，是否包括该任务执行的结果数据的任务执行信息，如果每个任务的任务执行信息中均包括该任务成功的任务执行信息，则表明上述各个任务均已成功完成，此时，可以不做任何处理。如果某一个或多个任务失败，或者，某一个或多个任务的任务执行信息中不包括该任务的结果数据等，则表明该任务或多个任务异常，上述一个或多个任务的任务执行信息即为异常的任务执行信息，此时，可以输出上述异常的任务执行信息的提醒消息，该提醒消息中可以包括上述一个或多个任务的任务标识(如任务的名称或编码等)，以及上述一个或多个异常的任务执行信息等。

在步骤S106中，根据上述异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型。

其中，任务异常类型可以包括多种，例如环境变量导致的任务执行异常、设备故障导致的任务执行异常或应用程序某相关模块的运行故障导致的任务执行异常等，具体可以根据实际情况设定，本申请实施例对此不做限定。

在实施中，在确定任务执行信息中包括异常的任务执行信息，则可以对异常的任务执行信息进行分析，确定其中出现异常的信息内容，可以通过其中出现异常的信息内容，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，具体地，可以对异常的任务执行信息中的每一项内容进行分析，确定每一项内容所表示的含义，从而可以确定出其中表示的含义为异常或错误的内容，或者，可以预先设定每一项内容对应的基准内容样式，然后，可以将异常的任务执行信息中的每一项内容提取出来，并将提取的某一项内容与对应的基准内容样式进行比对，如果两者相同或相似，则可以确定该项内容无异常，否则，可以确定该项内容异常。如果通过上述方式确定某项内容异常，则可以从该项内容中提取包含的字段信息，如果提取的字段信息中包括预定的关键字段，则可以确定该关键字段对应的任务异常类型，例如异常的任务执行信息中包括内容为A参数未查找到的关键字段的信息，则可以确定目标任务的任务异常类型为参数导致的任务执行异常。

在步骤S108中，根据上述目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率。

其中，修复方式可以包括多种，例如自动重新执行或手动修复等。修复概率可以是根据通过某修复方式进行任务修复后，该任务被修复的概率，具体如90％或30％等。

在实施中，可以预先存储有不同任务异常类型对应的修复方式和相应的修复概率的对应关系，该对应关系可以根据实际情况设定，具体如可以根据技术人员的使用经验设定，如表1所示。

表1

或者，还可以设定修复模型，通过对大量任务异常类型对应的修复方式和相应的修复概率的训练，得到训练后的修复模型，通过该修复模型确定目标任务的修复方式和相应的修复概率。

通过上述步骤S106的处理，确定目标任务所属的任务异常类型后，可以根据目标任务所属的任务异常类型，在如上述表1所示的对应关系中，确定目标任务所属的任务异常类型对应的修复方式和相应的修复概率，例如，目标任务所属的任务异常类型为A，则对应的修复方式和相应的修复概率为修复方式1、修复概率为90％、修复方式2、修复概率为60％等。或者，可以将目标任务所属的任务异常类型作为输入数据输入到上述修复模型中进行计算，得到目标任务的修复方式和相应的修复概率等输出结果等。

在步骤S110中，根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理。

在实施中，服务器得到目标任务的修复方式和相应的修复概率后，可以从中选取最大的修复概率对应的修复方式，并可以执行该修复方式对应的操作。例如，该修复方式为重新执行，则服务器可以重新执行目标任务，并获取目标任务重新执行的执行结果，如果该执行结果为目标任务执行失败，则可以根据异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率，根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理。如果该执行结果为目标任务执行成功，则可以输出目标任务执行成功的通知消息。

本申请实施例提供一种任务的执行方法，获取当前各数据链路中配置的任务的任务执行信息，如果该任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息，并根据该异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率，最终，可以根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理，这样，通过任务执行信息，确定出现异常的任务执行信息，进而可以确定出现异常的任务，然后，可以通过异常的任务执行信息对应的任务异常类型，确定相应的修复方式和修复概率，并基于该修复方式和修复概率对相应的任务进行修复，从而，设备可以通过修复方式自动修复出现异常的任务，或者提醒用户或技术人员按照修复方式进行修复，从而不需要管理人员通过人工操作的方式触发重新执行出现异常的任务，减少了频繁的人工操作，提高任务执行的效率。

实施例二

如图2所示，本申请实施例提供一种任务的执行方法，该方法可以应用于在某项任务在执行的过程中出现异常时重新执行该任务的处理中。该方法的执行主体可以为终端设备或服务器，其中，该终端设备可以如个人计算机等终端设备，服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。本申请实施例中以服务器为例进行详细说明，对于执行主体为终端设备的情况，可以参照服务器的情况执行，在此不再赘述。该方法具体可以包括以下步骤：

在步骤S202中，获取数据链路中配置的各任务的任务执行信息。

其中，任务执行信息中至少可以包括任务的输入数据、任务的执行时间、任务是否执行成功和任务执行的结果数据是否存在等，任务的输入数据可以包括该任务所需要的初始数据，任务的执行时间可以是任务执行的开始时间、结束时间或任务执行的时间段等。任务执行信息中可以包括多个维度，例如产品、数据链路中的位置和业务类型等维度。

需要说明的是，在实际应用中，服务器可以调用Shell脚本程序获取执行各个任务的过程中的任务执行信息，其中，Shell脚本程序是利用Shell的功能所写的一个程序，该程序是使用纯文本文件，将一些Shell的语法与指令写在该纯文本文件中，然后，通过正规表示法、管道命令以及数据流重导向等功能，以达到所需要的处理目的。此外，为了减少资源消耗，服务器可以在达到信息获取周期时，调用Shell脚本程序获取任务执行信息，其中，信息获取周期可以根据实际情况设定，具体如3分钟或5分钟等。

在步骤S204中，如果上述任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息。

在实施中，可以预先设置有对异常任务的判断方式和相应的判断规则，其中的判断方式和相应的判断规则可以根据实际情况设定，本实施例中提供可供选择的实现方式，可以包括以下内容：

其中的判断方式可以包括通过每个任务当前的执行情况进行判断，或者通过记载的信息进行判断等。对于通过每个任务当前的执行情况进行判断的情况，相应的判断规则可以为如果某任务在指定的时长内执行完成，则该任务为正常任务，否则，该任务为异常任务。对于通过记载的信息进行判断的情况，相应的判断规则可以为如果记载的信息中包括某任务正常的信息(例如，任务执行完成或任务执行成功等)，则该任务为正常任务，否则，该任务为异常任务。

当通过上述步骤S202的处理得到各任务的任务执行信息时，基于任务执行信息确定各个任务的执行情况，如果通过任务执行信息确定某一个或多个任务在指定的时长内未执行完成，则该一个或多个任务为异常任务。或者，基于任务执行信息的内容确定正常或异常任务的情况，可以分析每个任务的任务执行信息的内容，如果某一个或多个任务的任务执行信息内容中包括任务执行失败，或任务执行故障，或任务暂停，任务执行信息内容为空等，则可以确定该一个或多个任务为异常任务。

上述步骤S204的步骤内容与上述实施例一中步骤S104的步骤内容相同，步骤S204的具体处理过程还可以参见上述步骤S104中的相关内容，在此不再赘述。

在步骤S206中，根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型。

其中，异常的任务执行信息中可以包括任务失败的信息，或者，异常的任务执行信息中不包含目标任务的执行结果数据等。其中的任务失败的信息可以通过多种不同的情况产生，例如，由于服务器的CPU持续处于满荷运行状态达到预定阈值的时长超过预定时长而造成的任务失败，或者，由于服务器的内存处于溢出状态而造成的任务失败等。其中的异常的任务执行信息中不包含目标任务的执行结果数据的情况可能由多种不同的原因造成，例如，由于服务器的CPU处于繁忙状态，目标任务还未执行，或者，由于传输线路故障造成目标任务的执行结果数据无法输出等。

在步骤S208中，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率。

其中，修复方式和修复概率可以根据用户或技术人员针对相应的异常情况进行修复的过程或方案确定，例如服务器可以针对不同的异常情况，记录用户手动修复的方式，或记录相关技术人员的修复方式，并且可以记录用户或技术人员提供的修复方式进行任务修复后，该任务成功的次数和该任务失败的次数，从而得到该修复方式的修复概率等。

在步骤S210中，如果目标任务的修复方式为重新执行，且根据与修复方式相应的修复概率，确定目标任务满足预定任务恢复条件，则重新执行目标任务。

其中，任务恢复条件可以是使某一任务可以重新执行的条件，任务恢复条件可以包括多种，例如与该修复方式相应的修复概率大于预定的恢复阈值等。。

在实施中，可以预先设置是否满足预定任务恢复条件的判断方式和相应的判断规则，其中的判断方式和相应的判断规则可以根据实际情况设定，本实施例中提供可供选择的实现方式，可以包括以下内容：

其中的判断方式可以包括通过每个任务的任务执行信息的内容进行判断，或者通过某一项或多项指定信息进行判断等。对于通过每个任务的任务执行信息的内容进行判断的情况，相应的判断规则可以为如果某任务的任务执行信息中的内容指示该任务执行完成并执行成功，则该任务不满足预定任务恢复条件，否则，该任务满足预定任务恢复条件。对于通过某一项或多项指定信息进行判断的情况，相应的判断规则可以为如果与该修复方式相应的修复概率大于预定的恢复阈值，则该任务满足预定任务恢复条件，否则，该任务不满足预定任务恢复条件。

当通过上述步骤S204的处理得到异常的任务执行信息时，基于异常的任务执行信息确定对应的目标任务的执行情况，如果目标任务的任务执行信息中的内容指示该目标任务执行未完成或执行失败，且与该修复方式相应的修复概率大于预定的恢复阈值，则该目标任务满足预定任务恢复条件。或者，可以从目标任务的任务执行信息中查找是否包括目标任务的执行结果数据，如果不包含，且与该修复方式相应的修复概率大于预定的恢复阈值，则该目标任务满足预定任务恢复条件，然后，可以重新执行上述目标任务。

在重新执行上述目标任务的过程中，可以继续采集任务执行信息，并生成重新执行的各个任务的结果数据。如果上述一个或多个任务均成功，则可以继续执行上述步骤S204的处理，如果上述一个或多个任务中仍然存在执行失败的任务或不存在结果数据的任务，则可以再次重新执行该目标任务，直到该目标任务成功，或者，也可以将该目标任务进行告警，以通知相应的管理人员及时对该目标任务进行处理等。

在步骤S212中，获取目标任务重新执行的执行结果。

其中，执行结果可以是某一项任务在执行的过程中产生的相关数据，该执行结果可以说明该任务的完成情况，执行结果也可以包括多种，例如任务是否执行完成、执行任务的过程中产生的信息是否准确等。

在实施中，由于重新执行目标任务需要一定的时长，因此，重新执行目标任务的执行结果也会在一定的时长之后生成，为此，可以预先设定获取执行结果的周期或时间间隔，例如10分钟或5分钟等。当到达该周期或时间间隔后，可以获取目标任务重新执行的执行结果。

在步骤S214中，如果目标任务的修复方式为非重新执行，且与修复方式相应的修复概率大于预定的概率阈值，则输出包含该修复方式的任务修复提醒信息，以使用户根据该修复方式对目标任务进行任务修复。

在实施中，任务修复提醒信息中可以包括修复目标任务需要使用的修复方式的信息，例如将磁盘A中文件夹1中的a文件中的内容修改为另一个内容并保存，然后重新执行目标任务等。然后，用户可以根据任务修复提醒信息依次进行相应的操作，以对目标任务进行任务修复。

实施例三

如图3所示，本申请实施例提供一种任务的执行方法，该方法可以应用于在某项任务在执行的过程中出现异常时重新执行该任务的处理中。该方法的执行主体可以为终端设备或服务器，其中，该终端设备可以如个人计算机等终端设备，服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。本申请实施例中以服务器为例进行详细说明，对于执行主体为终端设备的情况，可以参照服务器的情况执行，在此不再赘述。该方法具体可以包括以下步骤：

在步骤S302中，获取数据链路中配置的各任务的任务执行信息。

在步骤S304中，如果上述任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息。

在步骤S306中，根据上述异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型。

在步骤S308中，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率。

在步骤S310中，如果目标任务的修复方式为重新执行，且根据与修复方式相应的修复概率，确定目标任务满足预定任务恢复条件，则重新执行目标任务。

其中，任务恢复条件可以是使某一任务可以重新执行的条件，任务恢复条件可以包括多种，例如与该修复方式相应的修复概率大于预定的恢复阈值等。

在步骤S312中，在确定目标任务满足预定任务恢复条件时开始计时，当到达第一预定时长时，采集重新执行目标任务的执行结果。

其中，第一预定时长可以为异常的任务执行信息对应的目标任务在预定时间段内执行时间的均值与第二预定时长的和，其中的预定时间段可以根据实际情况设定，具体如7天或10天等，执行时间可以根据预先记录的目标任务的实际执行时间确定，具体如2分钟或5分钟等，第二预定时长可以根据实际情况设定，具体如可以根据目标任务在预定时间段内执行时间的最大值确定，如目标任务在预定时间段内执行时间的最大值为5分钟，则第二预定时长可以为5分钟或大于5分钟等，此外，除了可以通过上述方式设定第二预定时长外，还可以根据实际情况设定，如设定第二预定时长为10分钟或20分钟等，本申请实施例对此不做限定。

在实施中，例如，针对相同的目标任务，最近7天(或10天等)内执行目标任务的执行时间包括1分钟、2分钟、3分钟、2分钟和5分钟，则上述均值可以为2.6分钟，如果第二预定时长为10分钟，则第一预定时长可以为12.6分钟或13分钟等。可以在确定目标任务满足预定任务恢复条件时开始计时，当到达12.6分钟或13分钟时，可以在上述时间段内产生的执行结果中查找重新执行目标任务的执行结果，如果未查找到重新执行目标任务的执行结果，则可以确定目标任务存在异常，此时，可以再次重新执行目标任务，或者，可以向管理人员或技术人员输出提醒消息，以便管理人员或技术人员对该目标任务进行处理。如果查找到重新执行目标任务的执行结果，但是该执行结果为执行失败，则可以确定目标任务存在异常，此时，可以再次重新执行目标任务，或者，可以向管理人员或技术人员输出提醒消息，以便管理人员或技术人员对该目标任务进行处理。如果查找到重新执行目标任务的执行结果，且该执行结果为执行成功，则可以继续后续任务的执行。

为了提高本方案的可实施性，并简化相应的处理过程，上述步骤S312的处理可以通过多种方式实现，以下提供一种可选的实现方式，具体可以包括以下内容：在确定目标任务满足预定任务恢复条件时开始计时，当到达第一预定时长时，调用预定的Shell脚本，获取第一任务执行信息对应的任务的结果数据。

上述步骤的具体处理过程可以参见上述步骤S312中的相关内容，在此不再赘述。

在步骤S314中，如果目标任务的修复方式为非重新执行，且与修复方式相应的修复概率大于预定的概率阈值，则输出包含该修复方式的任务修复提醒信息，以使用户根据该修复方式对目标任务进行任务修复。

上述实施例一～实施例三是以一个服务器作为执行主体实现的，而在实际应用中，可以根据实际情况将上述服务器拆分为多个不同的服务器(例如拆分为2个不同的服务器或3个不同的服务器等)，并可以通过多个不同的服务器之间的交互实现上述实施例一～实施例三中的处理过程。为了能够说明通过多个服务器可以实现上述处理过程，下述实施例三～实施例五进行详细说明，其中，下述实施例四～实施例六以2个不同的服务器为例进行说明，对于通过3个或3个以上的服务器实现的具体处理过程可以参见下述实施例中的相关内容，并可以根据不同服务器的功能进行调整，本申请实施例在此不再赘述。

实施例四

如图4所示，本申请实施例提供一种任务的执行方法，该方法可以应用于在某项任务在执行的过程中出现异常时重新执行该任务的处理中。该方法的执行主体可以为终端设备或服务器，其中，该终端设备可以如个人计算机等终端设备，服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。本申请实施例中以服务器为例进行详细说明，对于执行主体为终端设备的情况，可以参照服务器的情况执行，在此不再赘述。本申请实施例的执行主体可以为告警服务器，该方法具体可以包括以下步骤：

在步骤S402中，采集调度服务器中各数据链路中配置的任务的任务执行信息。

其中，调度服务器可以用于对待处理数据的顺序进行处理，构成了数据处理链路，并可以用于执行数据清洗任务等，调度服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。

在实施中，在业务处理体系中，通常可以包括调度系统和告警系统，目前主流的告警系统可以及时的将正确的通知使用正确的方式准确的推送给管理人员，但是在大数据领域，随着数据链路日益复杂，需要设置的告警项也越来越多。而告警项越来越多时，管理人员需要花费大量时间去处理某些频繁发生的告警。在数据链路发生异常时，在首次告警发出的基础上，可以执行恢复程序，这样，可以在一定程度上减少人力资源的消耗，数据链路发生异常后自动恢复可以是在两个系统的基础上实现，即上述调度系统和告警系统。

针对调度系统，在大数据的数据处理过程中，为了数据分析或使用时尽可能灵活，每份数据会有很多中间状态，调度系统通过对数据的顺序处理，构成了数据处理链路，每个中间状态都是由调度系统执行数据清洗任务得来，每个任务均有输入数据和输出数据，但调度系统可能会因为网络或内存等异常情况而导致个别任务执行失败。

针对告警系统，告警系统整体可以分为四部分，即信息收集代理(即信息收集Agent)、信息存储、异常触发(即异常Triger)和告警平台等。其中，信息收集Agent可以用于收集调度系统中的各任务在任务执行过程中的任务执行信息。信息存储可以用于使用数据库存储信息收集Agent采集的任务执行信息。异常Triger可以用于定时检查任务执行信息的内容，并在发现其中存在异常信息时，将该异常信息发送给告警平台处理。告警平台可以用于对异常Triger发送的异常信息进行处理，根据异常信息中内容的不同，可以进行告警、收敛、升级等操作。其中，需要说明的是，对于重复的告警，告警平台将不再向管理人员发送，防止管理人员收到大量重复告警。其中的升级操作可以是指告警手段的升级，即在异常状况长时间未解决的情况下，会使用更有效的通知方式，如由默认的短消息方式升级到电话的方式等。

如图5所示，本申请的执行主体可以是告警系统所在的告警服务器，基于上述内容，调度系统所在的调度服务器可以根据需要处理的数据的顺序，确定数据的处理链路，从而形成数据链路，可以为每个数据链路配置任务，调度服务器可以通过不同的数据链路完成相应的任务。而在调度服务器执行数据链路中配置的各个任务的过程中，告警服务器中的信息收集Agent可以从调度服务器中采集各个任务的任务执行信息。

在步骤S404中，如果上述任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息。

上述步骤S404的步骤内容与上述实施例一中步骤S104的步骤内容相同，步骤S404的具体处理过程可以参见上述步骤S104中的相关内容，在此不再赘述。

在步骤S406中，根据上述异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型。

在步骤S408中，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率。

在步骤S410中，如果目标任务的修复方式为重新执行，且根据与该修复方式相应的修复概率，确定目标任务满足预定任务恢复条件，则向调度服务器发送重新执行目标任务的通知消息。

在实施中，告警系统中的信息采集Agent(即告警服务器)从调度服务器中采集到各个任务的任务执行信息后，可以将采集到的任务执行信息存储在信息存储设备中，告警服务器可以对采集到的任务执行信息进行分析，例如，可以对采集到的任务执行信息进行分类，确定属于同一任务的任务执行信息，并可以在每个任务的任务执行信息中查找关于该任务是否成功的任务执行信息，或者，是否包括该任务执行的结果数据的任务执行信息，如果每个任务的任务执行信息中均包括该任务成功的任务执行信息，则表明上述各个任务均已成功完成，此时，报警平台可以不做任何处理，如果某一个或多个任务失败，或者，某一个或多个任务的任务执行信息中不包括该任务的结果数据，且根据与该修复方式相应的修复概率，确定目标任务满足预定任务恢复条件，则表明该任务或多个任务满足预定任务恢复条件，上述一个或多个任务的任务执行信息即为第一任务执行信息，此时，告警服务器可以向调度服务器发送通知消息，该通知消息中可以包括上述一个或多个任务的任务标识(如任务的名称或编码等)，以及上述一个或多个任务重新执行的指令等。

在步骤S412中，从调度服务器获取目标任务重新执行的执行结果。

在实施中，调度服务器接收到上述通知消息后，可以从该通知消息中提取需要重新执行的任务的任务标识，然后，可以基于提取的任务标识确定相应的任务，并可以重新执行上述确定的任务，即调度服务器重新执行第一任务执行信息对应的任务。在调度服务器重新执行上述任务的过程中，告警服务器可以继续采集任务执行信息，并确定重新执行的各个任务的执行结果。如果上述一个或多个任务均成功，则可以继续执行上述步骤S402的处理，如果上述一个或多个任务中仍然存在执行失败的任务或不存在结果数据的任务，则可以通知调度服务器再次重新执行该任务，直到该任务成功，或者，也可以将该任务通过告警系统中的告警平台进行告警，已通知相应的管理人员及时对该任务进行处理等。

在步骤S414中，如果目标任务的修复方式为非重新执行，且与该修复方式相应的修复概率大于预定的概率阈值，则输出包含该修复方式的任务修复提醒信息，以使用户根据该修复方式对目标任务进行任务修复。

实施例五

如图6所示，本申请实施例提供一种任务的执行方法，该方法可以应用于在某项任务在执行的过程中出现异常时重新执行该任务的处理中。该方法的执行主体可以为终端设备或服务器，其中，该终端设备可以如个人计算机等终端设备，服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。本申请实施例中以服务器为例进行详细说明，对于执行主体为终端设备的情况，可以参照服务器的情况执行，在此不再赘述。本申请实施例的执行主体可以为调度服务器，该方法具体可以包括以下步骤：

在步骤S602中，接收告警服务器发送的重新执行目标任务的通知消息。

其中，目标任务可以是上述图1所示的满足预定任务恢复条件的任务执行信息对应的任务。

在步骤S604中，重新执行上述目标任务，并生成重新执行目标任务的执行结果。

实施例六

如图7所示，本申请实施例提供一种任务的执行方法，该方法可以应用于在某项任务在执行的过程中出现异常时重新执行该任务的处理中。该方法的执行主体可以为调度服务器和告警服务器，其中，调度服务器或告警服务器可以是单一的服务器，也可以是由多个服务器组成的服务器集群。该方法具体可以包括以下步骤：

在步骤S702中，告警服务器采集调度服务器中各数据链路中配置的任务的任务执行信息。

其中，任务执行信息中至少可以包括任务的输入数据、任务的执行时间、任务是否执行成功和任务执行的结果数据是否存在等，任务的输入数据可以包括该任务所需要的初始数据，任务的执行时间可以是任务执行的开始时间、结束时间或任务执行的时间段等。

在实施中，管理人员或技术人员可以在告警服务器中设置用于从调度服务器中采集任务执行信息的Shell脚本程序，该Shell脚本程序可以是用各类命令预先放入到一个文件中，从而方便后续一次性执行的程序文件。当调度服务器在执行各数据链路中配置的任务的过程中，告警系统中的信息收集Agent可以调用上述Shell脚本程序，通过Shell脚本程序获取调度服务器在执行各个任务的过程中的任务执行信息，采集到的任务执行信息中可以包括多个维度，例如产品、数据链路中的位置和业务类型等维度。

需要说明的是，在实际应用中，为了减少资源消耗，告警系统中的信息收集Agent可以在达到信息获取周期时，启动Shell脚本程序获取任务执行信息，其中，信息获取周期可以根据实际情况设定，具体如1分钟或3分钟等。

在步骤S704中，如果上述任务执行信息中包括异常的任务执行信息，则告警服务器输出该异常的任务执行信息的提醒消息。

在实施中，告警系统中的信息收集Agent采集到任务执行信息后，可以将采集到的任务执行信息通过HTTP协议写入数据库(例如开源时序数据库InfluxDB等)中。告警系统中的异常Triger(即告警服务器)可以从上述数据库(例如开源时序数据库InfluxDB等)中获取调度服务器的任务执行信息。异常Triger可以对获取的任务执行信息进行分析，如果发现任务执行信息中存在异常的任务执行信息，具体如任务失败或者某项任务没有得到相应的结果数据，或者，某项任务已经完成，但是没有取得预定的效果，或者，某项任务在执行的过程中，某项子任务出现异常等，则表明当前存在出现异常的任务，此时，可以将上述任务执行信息作为异常信息，并可以通过HTTP协议，生成相应的提醒消息，并将其提供给告警平台。

在步骤S706中，告警服务器根据上述异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型。

在步骤S708中，告警服务器根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率。

在步骤S710中，如果目标任务的修复方式为重新执行，且根据与该修复方式相应的修复概率，确定目标任务满足预定任务恢复条件，则告警服务器向调度服务器发送重新执行目标任务的通知消息。

在实施中，可以根据实际情况设定任务恢复条件，例如任务失败，且与该修复方式相应的修复概率大于预定的概率阈值或者某项任务没有得到相应的结果数据，且与该修复方式相应的修复概率大于预定的概率阈值，或者，某项任务已经完成，但是没有取得预定的效果，且与该修复方式相应的修复概率大于预定的概率阈值，或者，某项任务在执行的过程中，某项子任务出现异常，且与该修复方式相应的修复概率大于预定的概率阈值等。

在实际应用中，告警平台的主体可以是信息处理管道，因此，异常Triger会通过HTTP协议接口，将上述异常信息(其中可以包括上述第一任务执行信息)写入该信息处理管道中，这样，该信息处理管道中可以包括异常Triger发送的异常信息。一组信息处理组件可以处理信息处理管道中的信息，每个组件可以从信息处理管道内获取信息。当某一个组件对该信息处理完成后，可以再将其放回信息处理管道中，以便下一个组件继续处理该信息。其中，信息处理组件中可以包括首次告警组件，如果某异常信息是首次被接收，由于该异常信息是任务失败或结果数据不存在等任务执行信息，，且与该修复方式相应的修复概率大于预定的概率阈值，因此，可以将上述异常信息作为满足预定任务恢复条件的任务执行信息，此时，可以使用初始通知方式将相应的告警信息发送给管理人员，然后，可以基于HTTP协议生成通知消息，并可以将该通知消息发送给调度服务器，以告知调度服务器重新执行出现异常的任务(即上述第一任务执行信息对应的任务)。

需要说明的是，异常Triger可以通过多种编程语言开发，例如，可以使用Java编程语言开发或C语言开发等，本申请实施例对此不做限定。在步骤S710中，调度服务器重新执行目标任务，生成重新执行目标任务的执行结果。

在步骤S712中，在确定目标任务满足预定任务恢复条件时开始计时，当到达第一预定时长时，告警服务器从调度服务器中采集重新执行目标任务的执行结果。

其中，第一预定时长可以为第一任务执行信息对应的任务在预定时间段内执行时间的均值与第二预定时长的和。预定时间段内可以根据实际情况设定，例如一个月内或10天内或7天内等。执行时间可以是某任务从开始执行开始到执行完成所需要的时间，如1分钟或3分钟等。预定时间段内执行时间的均值可以如一个月内或7天内任务执行所需的执行时间的平均值，具体如，7天内某任务的执行时间包括10个，则可以计算上述10个执行时间的平均值。第二预定时长可以根据实际情况设定，具体如10分钟或20分钟等。

在实施中，为了及时获取重新执行的任务的执行结果，并在获取执行结果的过程中减少资源损耗，可以在经过一定时长后获取执行结果，因此，在将上述通知消息发送给调度服务器的同时，还可以进行计时，具体地，可以设置计时器，当告警平台向调度服务器发送通知消息时，可以启动计时器进行计时。告警平台通过设置的计时器进行计时后，当计时的时长达到第一预定时长时，告警系统中的信息收集Agent可以继续从调度服务器中采集执行异常的任务执行信息对应的目标任务的执行结果。告警系统中的异常Triger可以通过采集的执行结果，确定上述异常的任务执行信息对应的目标任务是否执行成功，或者，目标任务的结果数据是否存在等。异常Triger可以将分析的结果通知给告警平台，告警平台可以通过当前设定的通知方式，将上述分析的结果发送给管理人员。管理人员可以根据实际情况，以及分析结果，确定后续如何处理上述异常的任务执行信息对应的目标任务。

为了提高本方案的可实施性，并简化相应的处理过程，上述步骤S710的处理可以通过多种方式实现，以下提供一种可选的实现方式，具体可以包括以下内容：当到达第一预定时长时，调用预定的Shell脚本，采集重新执行目标任务的执行结果。

在实施中，如上述步骤S702中的相关内容，信息收集Agent中可以设置有Shell脚本程序。告警平台通过设置的计时器计时的时长达到第一预定时长时，告警系统中的信息收集Agent可以调用预定的Shell脚本，并通过Shell脚本从调度服务器中采集重新执行目标任务的执行结果。

在步骤S714中，如果目标任务的修复方式为非重新执行，且与该修复方式相应的修复概率大于预定的概率阈值，则输出包含该修复方式的任务修复提醒信息，以使用户根据该修复方式对目标任务进行任务修复。

实施例七

以上为本申请实施例提供的任务的执行方法，基于同样的思路，本申请实施例还提供一种任务的执行装置，如图8所示。

所述任务的执行装置包括：信息获取模块801、提醒模块802、异常类型确定模块803、修复方式确定模块804和任务修复模块805，其中：

信息获取模块801，用于获取当前各数据链路中配置的任务的任务执行信息；

提醒模块802，用于如果所述任务执行信息中包括异常的任务执行信息，则输出所述异常的任务执行信息的提醒消息；

异常类型确定模块803，用于根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型；

修复方式确定模块804，用于根据所述目标任务所属的任务异常类型，确定所述目标任务的修复方式和相应的修复概率；

任务修复模块805，用于根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理。

本申请实施例中，所述任务修复模块805，包括：

重新执行单元，用于如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则重新执行所述目标任务；

结果获取单元，用于获取所述目标任务重新执行的执行结果。

本申请实施例中，所述预定任务恢复条件包括与所述修复方式相应的修复概率大于预定的恢复阈值。

本申请实施例中，所述任务执行信息中至少包括任务的输入数据、任务的执行时间、任务是否执行成功和任务的执行结果的数据是否存在。

本申请实施例中，所述信息获取模块801，用于采集调度服务器中各数据链路中配置的任务的任务执行信息；

所述重新执行单元，用于如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则向所述调度服务器发送重新执行所述目标任务的通知消息，以使所述调度服务器重新执行所述目标任务，生成重新执行所述目标任务的执行结果。

本申请实施例中，所述结果获取单元，用于在确定所述目标任务满足预定任务恢复条件时开始计时，当到达第一预定时长时，采集重新执行所述目标任务的执行结果。

本申请实施例中，所述第一预定时长为在预定时间段内所述目标任务执行时间的均值与第二预定时长的和。

本申请实施例中，所述第二预定时长为10分钟或20分钟。

本申请实施例中，所述结果获取单元，用于当到达第一预定时长时，调用预定的Shell脚本，采集重新执行所述目标任务的执行结果。

本申请实施例中，所述任务修复模块805，用于如果所述目标任务的修复方式为非重新执行，且与所述修复方式相应的修复概率大于预定的概率阈值，则输出包含所述修复方式的任务修复提醒信息，以使用户根据所述修复方式对所述目标任务进行任务修复。

本申请实施例提供一种任务的执行装置，获取当前各数据链路中配置的任务的任务执行信息，如果该任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息，并根据该异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率，最终，可以根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理，这样，通过任务执行信息，确定出现异常的任务执行信息，进而可以确定出现异常的任务，然后，可以通过异常的任务执行信息对应的任务异常类型，确定相应的修复方式和修复概率，并基于该修复方式和修复概率对相应的任务进行修复，从而，设备可以通过修复方式自动修复出现异常的任务，或者提醒用户或技术人员按照修复方式进行修复，从而不需要管理人员通过人工操作的方式触发重新执行出现异常的任务，减少了频繁的人工操作，提高任务执行的效率。

实施例八

基于上述实施例三～实施例五的内容，基于同样的思路，本申请实施例还提供一种任务的执行装置，如图9所示。

所述任务的执行装置包括：通知消息接收模块901和重新执行模块902，其中：

通知消息接收模块901，用于接收告警服务器发送的重新执行目标任务的通知消息；

重新执行模块902，用于重新执行所述目标任务，生成重新执行所述目标任务的执行结果。

实施例九

基于上述实施例三～实施例五的内容，基于同样的思路，本申请实施例还提供一种任务的执行装置，如图10所示。

所述任务的执行装置包括：信息获取模块1001、提醒输出模块1002、异常类型确定模块1003、修复方式确定模块1004、通知发送模块1005和结果获取模块1006，其中：

信息获取模块1001，用于获取当前各数据链路中配置的任务的任务执行信息；

提醒模块1002，用于如果所述任务执行信息中包括异常的任务执行信息，则输出所述异常的任务执行信息的提醒消息；

异常类型确定模块1003，用于根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型；

修复方式确定模块1004，用于根据所述目标任务所属的任务异常类型，确定所述目标任务的修复方式和相应的修复概率；

通知发送模块1005，用于如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则向所述调度服务器发送重新执行所述目标任务的通知消息，以使所述调度服务器重新执行所述目标任务，生成重新执行所述目标任务的执行结果；

结果获取模块1006，用于获取所述目标任务重新执行的执行结果。

本申请实施例中，所述结果获取模块1006，用于在确定所述目标任务满足预定任务恢复条件时开始计时，当到达第一预定时长时，采集重新执行所述目标任务的执行结果。

本申请实施例中，所述第二预定时长为10分钟或20分钟。

本申请实施例中，所述结果获取模块1006，用于当到达第一预定时长时，调用预定的Shell脚本，采集重新执行所述目标任务的执行结果。

本申请实施例中，还包括任务修复模块，用于如果所述目标任务的修复方式为非重新执行，且与所述修复方式相应的修复概率大于预定的概率阈值，则输出包含所述修复方式的任务修复提醒信息，以使用户根据所述修复方式对所述目标任务进行任务修复。

实施例十

基于上述实施例七和实施例八提供的任务的执行装置，基于同样的思路，本申请实施例还提供一种任务的执行系统，如图5所示。

所述任务的执行系统包括调度服务器和告警服务器，其中：

所述告警服务器，用于采集调度服务器中各数据链路中配置的任务的任务执行信息，如果所述任务执行信息中包括异常的任务执行信息，则输出所述异常的任务执行信息的提醒消息，根据所述异常的任务执行信息，确定所述异常的任务执行信息对应的目标任务所属的任务异常类型；根据所述目标任务所属的任务异常类型，确定所述目标任务的修复方式和相应的修复概率；根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理。

所述调度服务器，用于如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则根据所述告警服务器发送的通知消息，重新执行所述目标任务，生成重新执行所述目标任务的执行结果。

本申请实施例中，所述告警服务器，用于如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则向所述调度服务器发送重新执行所述目标任务的通知消息，以使所述调度服务器重新执行所述目标任务，生成重新执行所述目标任务的执行结果。

本申请实施例中，所述任务执行信息中至少包括任务的输入数据、任务的执行时间、任务是否执行成功和任务执行的结果数据是否存在。

本申请实施例中，所述告警服务器，用于基于HTTP协议通知所述调度服务器重新执行所述目标任务，并开始计时；

当到达第一预定时长时，从所述调度服务器采集重新执行所述目标任务的结果数据。

本申请实施例中，所述第一预定时长为所述第一任务执行信息对应的任务在预定时间段内执行时间的均值与第二预定时长的和。

本申请实施例中，所述第二预定时长为10分钟或20分钟。

本申请实施例中，所述告警服务器，用于如果所述目标任务的修复方式为非重新执行，且与所述修复方式相应的修复概率大于预定的概率阈值，则输出包含所述修复方式的任务修复提醒信息，以使用户根据所述修复方式对所述目标任务进行任务修复。

本申请实施例中，所述告警服务器，用于当到达第一预定时长时，调用预定的Shell脚本，从所述调度服务器采集重新执行所述目标任务的执行结果。

本申请实施例提供一种任务的执行系统，包括调度服务器和告警服务器，告警服务器获取当前各数据链路中配置的任务的任务执行信息，如果该任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息，并根据该异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率，最终，可以根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理，这样，通过任务执行信息，确定出现异常的任务执行信息，进而可以确定出现异常的任务，然后，可以通过异常的任务执行信息对应的任务异常类型，确定相应的修复方式和修复概率，并基于该修复方式和修复概率对相应的任务进行修复，从而，设备可以通过修复方式自动修复出现异常的任务，或者提醒用户或技术人员按照修复方式进行修复，从而不需要管理人员通过人工操作的方式触发重新执行出现异常的任务，减少了频繁的人工操作，提高任务执行的效率。

实施例十一

以上为本申请实施例提供的任务的执行系统，基于同样的思路，本申请实施例还提供一种任务的执行设备，如图11所示。

该任务的执行设备可以为上述实施例提供的服务器等。

任务的执行设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器1101和存储器1102，存储器1102中可以存储有一个或一个以上存储应用程序或数据。其中，存储器1102可以是短暂存储或持久存储。存储在存储器1102的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对任务的执行设备中的一系列计算机可执行指令。更进一步地，处理器1101可以设置为与存储器1102通信，在任务的执行设备上执行存储器1102中的一系列计算机可执行指令。任务的执行设备还可以包括一个或一个以上电源1103，一个或一个以上有线或无线网络接口1104，一个或一个以上输入输出接口1105，一个或一个以上键盘1106。

具体在本实施例中，任务的执行设备包括有存储器，以及一个或一个以上的程序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对任务的执行设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令：

获取当前各数据链路中配置的任务的任务执行信息；

本申请实施例中，所述根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理，包括：

如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则重新执行所述目标任务；

获取所述目标任务重新执行的执行结果。

本申请实施例中，所述获取当前各数据链路中配置的任务的任务执行信息，包括：

采集调度服务器中各数据链路中配置的任务的任务执行信息；

所述如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则重新执行所述目标任务，包括：

如果所述目标任务的修复方式为重新执行，且根据与所述修复方式相应的修复概率，确定所述目标任务满足预定任务恢复条件，则向所述调度服务器发送重新执行所述目标任务的通知消息，以使所述调度服务器重新执行所述目标任务，生成重新执行所述目标任务的执行结果。

本申请实施例中，所述获取所述目标任务重新执行的执行结果，包括：

在确定所述目标任务满足预定任务恢复条件时开始计时，当到达第一预定时长时，采集重新执行所述目标任务的执行结果。

本申请实施例中，所述第二预定时长为10分钟或20分钟。

本申请实施例中，所述当到达第一预定时长时，采集重新执行所述目标任务的执行结果，包括：

当到达第一预定时长时，调用预定的Shell脚本，采集重新执行所述目标任务的执行结果。

如果所述目标任务的修复方式为非重新执行，且与所述修复方式相应的修复概率大于预定的概率阈值，则输出包含所述修复方式的任务修复提醒信息，以使用户根据所述修复方式对所述目标任务进行任务修复。

本申请实施例提供一种任务的执行设备，获取当前各数据链路中配置的任务的任务执行信息，如果该任务执行信息中包括异常的任务执行信息，则输出该异常的任务执行信息的提醒消息，并根据该异常的任务执行信息，确定该异常的任务执行信息对应的目标任务所属的任务异常类型，根据目标任务所属的任务异常类型，确定目标任务的修复方式和相应的修复概率，最终，可以根据目标任务的修复方式和相应的修复概率对目标任务进行任务修复处理，这样，通过任务执行信息，确定出现异常的任务执行信息，进而可以确定出现异常的任务，然后，可以通过异常的任务执行信息对应的任务异常类型，确定相应的修复方式和修复概率，并基于该修复方式和修复概率对相应的任务进行修复，从而，设备可以通过修复方式自动修复出现异常的任务，或者提醒用户或技术人员按照修复方式进行修复，从而不需要管理人员通过人工操作的方式触发重新执行出现异常的任务，减少了频繁的人工操作，提高任务执行的效率。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种任务的执行方法，其特征在于，所述方法包括：

获取当前各数据链路中配置的任务的任务执行信息；

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理，包括：

获取所述目标任务重新执行的执行结果。

3.根据权利要求2所述的方法，其特征在于，所述预定任务恢复条件包括与所述修复方式相应的修复概率大于预定的恢复阈值。

4.根据权利要求1所述的方法，其特征在于，所述任务执行信息中至少包括任务的输入数据、任务的执行时间、任务是否执行成功和任务的执行结果的数据是否存在。

5.根据权利要求2所述的方法，其特征在于，所述获取当前各数据链路中配置的任务的任务执行信息，包括：

6.根据权利要求2所述的方法，其特征在于，所述获取所述目标任务重新执行的执行结果，包括：

7.根据权利要求6所述的方法，其特征在于，所述第一预定时长为在预定时间段内所述目标任务执行时间的均值与第二预定时长的和。

8.根据权利要求7所述的方法，其特征在于，所述第二预定时长为10分钟或20分钟。

9.根据权利要求5所述的方法，其特征在于，所述当到达第一预定时长时，采集重新执行所述目标任务的执行结果，包括：

10.根据权利要求1所述的方法，其特征在于，所述根据所述目标任务的修复方式和相应的修复概率对所述目标任务进行任务修复处理，包括：

11.一种任务的执行装置，其特征在于，所述装置包括：

12.根据权利要求11所述的装置，其特征在于，所述任务修复模块，包括：

13.根据权利要求12所述的装置，其特征在于，所述信息获取模块，用于采集调度服务器中各数据链路中配置的任务的任务执行信息；

14.根据权利要求11所述的装置，其特征在于，所述任务修复模块，用于如果所述目标任务的修复方式为非重新执行，且与所述修复方式相应的修复概率大于预定的概率阈值，则输出包含所述修复方式的任务修复提醒信息，以使用户根据所述修复方式对所述目标任务进行任务修复。