CN107025224B - 一种监控任务运行的方法和设备 - Google Patents

Abstract

本申请实施例涉及通信技术领域，特别涉及一种监控任务运行的方法和设备，用以针对全链路ETL任务进行监控预警。本申请实施例的方法包括：检测每个ETL任务的状态；根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。由于能够在检测到故障ETL任务后，确定故障ETL任务的第一责任方和至少一个下游的ETL任务的第二责任方，从而能够针对全链路ETL任务进行监控预警，对链路上受到影响的ETL任务进行快速定位，为后续及时处理提供了基础。

Description

一种监控任务运行的方法和设备

技术领域

本申请涉及数据处理技术领域，特别涉及一种监控任务运行的方法和设备。

背景技术

ETL(Extract-Transform-Load，即数据抽取、转换、装载)作为数据仓库的核心，主要负责将数据从数据源向目标数据仓库转化，是实施数据仓库的重要环节。

ETL任务是指一个将数据从源数据库导出，并且按照一定规则进行转换，最后导入到目标数据库的过程。数据仓库新产生一个ETL任务后，需要为任务配置调度属性，以及配置该任务与其他任务之间的依赖关系，以保证新任务产生后，可以按预期的频率、规则以及顺序来调度执行，产出数据给业务系统使用。每个ETL任务既有可能依赖于其他任务，也有可能被其他的任务依赖，所有的ETL任务之间的相互关系就形成了一棵庞大的任务树，从任何一个树顶任务到叶子任务，都会形成一条数据链路。

由于任务之间相互依赖，如果链路中的一个任务运行出现问题(例如任务延迟、任务运行失败等)，会导致下游所有依赖它的ETL任务也无法按时产生数据，每个ETL任务的责任方(责任人或者责任系统)都应该清楚的了解自己负责的任务的影响范围以及是否被其他任务影响，并做到及时快速响应问题。

目前如果链路中的一个任务运行出现问题，针对出现问题的任务进行预警，预警效果比较差。

发明内容

本申请提供一种监控任务运行的方法和设备，用以解决现有技术中存在的目前只能针对出现问题的任务进行预警，预警效果比较差的问题。

本申请实施例提供的一种监控任务运行的方法，该方法包括：

检测每个ETL任务的状态；

根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；

针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。

本申请实施例根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。由于能够在检测到故障ETL任务后，确定故障ETL任务的第一责任方和至少一个下游的ETL任务的第二责任方，从而能够针对全链路ETL任务进行监控预警，对链路上受到影响的ETL任务进行快速定位，为后续及时处理提供了基础。

可选的，根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务之前，还包括：

检测每个ETL任务的重跑次数；

根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务，包括：

根据检测的状态和重跑次数，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务。

由于根据检测的状态和重跑次数确定故障ETL任务，使得确定的故障ETL任务更准确。

可选的，检测每个ETL任务的状态和重跑次数，包括：

周期检测每个ETL任务的状态和重跑次数。

可选的，所述故障条件包括下列条件中的部分或全部：

本次运行和上次运行都是失败状态，且重跑次数未发生变化；

本次运行和上次运行都是不成功状态，且当前监测到的重跑次数比前一次监测到的重跑次数大。

可选的，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方之后，还包括：

根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；

根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

由于本申请实施例根据第一责任方对应的第一通知方式向第一责任方发送故障信息，以及根据第二责任方对应的第二通知方式向第二责任方发送故障信息，相比于只监控任务本身的运行状态来说，可以发现更深层次的问题，同时本申请实施例中的预警机制使得ETL任务的责任方不仅可以在第一时间知道自己任务的问题所在，还可以知道其任务在全链路中的下游影响范围，对于被影响的ETL任务的责任方，可以在上游发生问题的第一时间就感知到自己是被哪个任务影响、是由于什么原因被影响、上游任务的责任方处理进度如何等，从而做到上下游双向透明，全链路上每一个任务的责任方都能做到快速响应，使得整个链路上的ETL任务数据按时产出。

可选的，所述故障信息包括下列信息中的部分或全部：

故障ETL任务的标识、下游的ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长；

所述预警信息包括下列信息中的部分或全部：

下游的ETL任务的标识、上游的故障ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长。

本申请实施例提供的一种监控任务运行的设备，该方法包括：

检测模块，用于检测每个ETL任务的状态；

任务确定模块，用于根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；

责任确定模块，用于针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。

可选的，所述检测模块还用于：

检测每个ETL任务的重跑次数；

所述任务确定模块具体用于：

根据检测的状态和重跑次数，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务。

可选的，所述检测模块具体用于：

周期检测每个ETL任务的状态和重跑次数。

可选的，所述故障条件包括下列条件中的部分或全部：

本次运行和上次运行都是失败状态，且重跑次数未发生变化；

本次运行和上次运行都是不成功状态，且当前监测到的重跑次数比前一次监测到的重跑次数大。

可选的，所述责任确定模块还用于：

确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方之后，根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

可选的，所述故障信息包括下列信息中的部分或全部：

故障ETL任务的标识、下游的ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长；

所述预警信息包括下列信息中的部分或全部：

下游的ETL任务的标识、上游的故障ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长。

附图说明

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

图1为本申请实施例监控任务运行的方法流程示意图；

图2为本申请实施例监控任务运行的完整方法流程示意图；

图3为本申请实施例监控任务运行的设备结构示意图。

具体实施方式

本申请实施例根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。由于能够在检测到故障ETL任务后，确定故障ETL任务的第一责任方和至少一个下游的ETL任务的第二责任方，从而能够针对全链路ETL任务进行监控预警，对链路上受到影响的ETL任务进行快速定位，为后续及时处理提供了基础。

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

如图1所述，本申请实施例监控任务运行的方法包括：

步骤100、检测每个ETL任务的状态；

步骤101、根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；

步骤102、针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。

可选的，根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务之前，检测每个ETL任务的重跑次数；

在从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务时，根据检测的状态和重跑次数，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务。

表1为ETL任务运行表的一份示例：

表1

表2为是ETL任务依赖配置表的一份简单示例，从下面的表可以得知任务8884的直接下游是8883,8882，由于8882的直接下游是8881，所以8884的所有下游包括8883,8882,8881：

父任务标识	任务标识	责任人
			8884	8883	张三
8884	8882	李四
			8882	8881	王五
…	…	…

表2

可选的，本申请实施例可以周期检测每个ETL任务的状态和重跑次数。

在实施中，本申请实施例可以在设定的时间通过采集ETL任务运行表获得ETL任务的运行信息。

比如可以每天一个固定时间进行采集。

ETL任务的运行信息包括但不限于下列信息中的部分或全部：

ETL任务的任务标识、ETL任务的状态、ETL任务的重跑次数和ETL任务的责任方信息。

ETL任务的状态分为成功状态、失败状态、未开始状态、运行中状态。而本申请实施例中的不成功状态为除成功状态之外的所有状态。

ETL任务的任务标识用于唯一标识一个任务，通过任务标识可以准确定位到一个ETL任务。

ETL任务的重跑次数表示一个ETL任务被反复执行的次数。如果该ETL任务本次运行失败后，在当前时间周期内被重新执行一次，则视为一次重跑，后面每次被重新执行，重跑次数都进行累加。

ETL任务的责任方信息可以是表明具体责任方的信息，比如数据仓库的开发人员等。

在实施中，故障条件可以根据需要进行设定。下面列举几个故障条件，需要说明的是下面列举的故障条件只是举例说明，其他能够确定故障ETL任务的条件都可以作为本申请实施例的故障条件。

故障条件1、本次运行和上次运行都是失败状态，且重跑次数未发生变化。

这里的本次运行为本次通过采集ETL任务运行表获得的状态；

这里的上次运行为上一次通过采集ETL任务运行表获得的状态。

比如本次通过采集ETL任务运行表获得的重跑次数为10次，而上一次通过采集ETL任务运行表获得的重跑次数也为10次，则确定本次运行和上次运行的重跑次数未发生变化。

故障条件2、本次运行和上次运行都是不成功状态，且当前监测到的重跑次数比之前监测到的重跑次数大。

当前监测到的重跑次数比前一次监测到的重跑次数大，也就表示重跑次数在增加。

可选的，针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方时，根据采集的ETL任务运行表可以确定故障ETL任务的第一责任方，根据ETL任务依赖配置表可以确定故障ETL任务的至少一个下游的ETL任务。

在确定下游的ETL任务后，根据ETL任务运行表就可以确定下游的ETL任务的相关信息。

下游的ETL任务的运行信息与上述ETL任务的运行信息相同，在此不再赘述。

可选的，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方之后，根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；

根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

本申请实施例的故障信息包括但不限于下列信息中的部分或全部：

故障ETL任务的标识、下游的ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长；

所述预警信息包括下列信息中的部分或全部：

下游的ETL任务的标识、上游的故障ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长。

上述第一通知方式和第二通知方式可以根据具体责任方的需求进行设定，比如有的责任方接收短信比较方便，则通知方式为按照预设的号码发送短信；

还比如的责任方接收邮件比较方便，则通知方式为按照预设的邮箱地址发送邮件；

还比如的责任方接收电话比较方便，则通知方式为按照预设的号码打电话播放设置的语音。

针对一个责任方，也可以不只采用一种通知方式，而是采用多种通知方式，比如可以采用语音和邮件两种方式。

在实施中，根据上面的故障条件确定故障ETL任务后，可以确定故障ETL任务已经故障的时长。

比如本次运行和上次运行都是失败的状态，且重跑次数x未发生变化的故障ETL任务t1，则记录任务t1处于这种状态的累计持续时间，比如m小时；

还比如本次运行和上次运行都是不成功的状态，且当前的重跑次数y和上一次相比在增加的故障ETL任务t2，记录其处于这种情况的累计持续时间，比如m小时。

确定故障ETL任务已经故障的时长的方式有很多中，比如对于每一个满足了故障条件的故障ETL任务，会记录第一次满足故障条件的系统时间，后面的每一次满足故障条件后，都会根据当前的系统时间和第一次满足故障条件的系统时间差来确定该任务已经满足这个故障条件的时长。

上述故障原因根据满足的故障条件不同，故障信息也不相同。

比如如果是满足上述故障条件1，则故障信息可以包括下列内容：

您负责的任务t1失败未响应持续m小时，会影响以下下游任务的数据产出：s1(这里可以列举所有下游的任务)。

t1的对应下游任务s1的预警信息可以包括下列内容：

您负责的任务s1的上游任务t1失败未响应持续m小时，会影响s1的数据产出。

比如如果是满足上述故障条件2，则故障信息可以包括下列内容：

您负责的任务t2重跑y次仍未成功，累计持续n小时，会影响以下下游任务的数据产出s2(这里可以列举所有下游的任务)。

t2的对应下游任务s2的预警信息可以包括下列内容：

您负责的任务s2的上游任务t2重跑y次仍未成功，累计持续n小时，会影响s2的数据产出。

上述故障信息和预警信息的具体内容只是举例说明，在实施中可以根据需要进行设定。

在实施中，故障信息和预警信息可以写入DBTEST数据库中，通过crontab命令进行定时(比如每天每小时在固定时间)，在设定时间达到后，读取DBTEST数据库中的预警内容，并通过设定的方式进行通知，比如短信、邮件或电话等方式。

本申请实施例中的ETL任务可以是实现ETL功能的任意一段程序，可以基于不同的计算平台，通过不同的语言来实现。例如计算平台是Oracle，那么开发脚本是存储过程，如果计算平台是ODPS，那么开发脚本是一个PERL，或者是单个的SQL封装。

如图2所示，本申请实施例监控任务运行的完整方法包括：

步骤201、根据设定的时间，周期采集ETL任务运行表获得ETL任务的运行信息，并将采集到的信息增加到数据库中。

步骤202、将本次采集的运行信息和上次采集的运行信息进行比较。

为了方便描述，下面以一个ETL任务进行说明，每一个ETL任务的处理方式都按照下列步骤执行即可。

步骤203、针对任何一个ETL任务，判断所述ETL任务当前采集到的重跑次数和前一次采集到的重跑次数相比是否增加，如果是，则执行步骤204；否则，执行步骤205。

步骤204、判断所述ETL任务本次获取的状态和上次获取的状态是否都是不成功，如果是，则确定所述ETL任务为故障ETL任务，并执行步骤206；否则，结束本流程。

步骤205、判断所述ETL任务本次获取的状态和上次获取的状态是否都是失败，如果是，则确定所述ETL任务为故障ETL任务，并执行步骤206；否则，结束本流程。

步骤206、确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。

步骤207、确定所述故障ETL任务故障的持续时长，并根据所述持续时长生成故障信息和预警信息。

步骤208、根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；

步骤209、根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

基于同一发明构思，本申请实施例中还提供了一种监控任务运行的设备，由于该设备解决问题的原理与本申请实施例监控任务运行的方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。

如图3所示，本申请实施例监控任务运行的设备包括：

检测模块300，用于检测每个ETL任务的状；

任务确定模块301，用于根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；

责任确定模块302，用于针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。

可选的，所述检测模块300还用于：

检测每个ETL任务的重跑次数；

所述任务确定模块301具体用于：

根据检测的状态和重跑次数，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务。

可选的，所述检测模块300具体用于：

周期检测每个ETL任务的状态和重跑次数。

可选的，所述故障条件包括下列条件中的部分或全部：

本次运行和上次运行都是失败状态，且重跑次数未发生变化；

本次运行和上次运行都是不成功状态，且当前监测到的重跑次数比前一次监测到的重跑次数大。

可选的，所述责任确定模块302还用于：

确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方之后，根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

可选的，所述故障信息包括下列信息中的部分或全部：

故障ETL任务的标识、下游的ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长；

所述预警信息包括下列信息中的部分或全部：

下游的ETL任务的标识、上游的故障ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长。

在实施中，本申请实施例可以通过使用LINUX的基本命令实现所有定时执行的脚本调度，脚本编写可以使用SHELL脚本语言，在数据存储过程中，还可以使用MYSQL数据库。上述方式都是基于后续实现成本相对较低而选择的。

除了上述方式，脚本编写也可用其他主流的计算机语言或者脚本语言，如：JAVA、PERL、PYTHON等，而数据库也可用其他常见数据库如ORACLE等实现数据存储。

从上述内容可以看出：本申请实施例根据检测的状态，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方。由于能够在检测到故障ETL任务后，确定故障ETL任务的第一责任方和至少一个下游的ETL任务的第二责任方，从而能够针对全链路ETL任务进行监控预警，对链路上受到影响的ETL任务进行快速定位，为后续及时处理提供了基础。

以上参照示出根据本申请实施例的方法、装置(系统)和/或计算机程序产品的框图和/或流程图描述本申请。应理解，可以通过计算机程序指令来实现框图和/或流程图示图的一个块以及框图和/或流程图示图的块的组合。可以将这些计算机程序指令提供给通用计算机、专用计算机的处理器和/或其它可编程数据处理装置，以产生机器，使得经由计算机处理器和/或其它可编程数据处理装置执行的指令创建用于实现框图和/或流程图块中所指定的功能/动作的方法。

相应地，还可以用硬件和/或软件(包括固件、驻留软件、微码等)来实施本申请。更进一步地，本申请可以采取计算机可使用或计算机可读存储介质上的计算机程序产品的形式，其具有在介质中实现的计算机可使用或计算机可读程序代码，以由指令执行系统来使用或结合指令执行系统而使用。在本申请上下文中，计算机可使用或计算机可读介质可以是任意介质，其可以包含、存储、通信、传输、或传送程序，以由指令执行系统、装置或设备使用，或结合指令执行系统、装置或设备使用。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (8)

1.一种监控任务运行的方法，其特征在于，该方法包括：

检测每个数据抽取、转换、装载ETL任务的状态；以及检测每个ETL任务的重跑次数；

根据检测的状态和重跑次数，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；

针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方；

其中，所述故障条件包括下列条件中的部分或全部：

本次运行和上次运行都是失败状态，且重跑次数未发生变化；

本次运行和上次运行都是不成功状态，且当前监测到的重跑次数比前一次监测到的重跑次数大。

2.如权利要求1所述的方法，其特征在于，周期检测每个ETL任务的状态和重跑次数。

3.如权利要求1～2任一所述的方法，其特征在于，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方之后，还包括：

根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；

根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

4.如权利要求3所述的方法，其特征在于，所述故障信息包括下列信息中的部分或全部：

故障ETL任务的标识、下游的ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长；

所述预警信息包括下列信息中的部分或全部：

下游的ETL任务的标识、上游的故障ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长。

5.一种监控任务运行的设备，其特征在于，该设备包括：

检测模块，用于检测每个ETL任务的状态；以及检测每个ETL任务的重跑次数

任务确定模块，用于根据检测的状态和重跑次数，从至少一个ETL任务中确定满足设定的故障条件的故障ETL任务；

责任确定模块，用于针对一个故障ETL任务，确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方；

其中，所述故障条件包括下列条件中的部分或全部：

本次运行和上次运行都是失败状态，且重跑次数未发生变化；

本次运行和上次运行都是不成功状态，且当前监测到的重跑次数比前一次监测到的重跑次数大。

6.如权利要求5所述的设备，其特征在于，所述检测模块具体用于：

周期检测每个ETL任务的状态和重跑次数。

7.如权利要求5～6任一所述的设备，其特征在于，所述责任确定模块还用于：

确定所述故障ETL任务的第一责任方和所述故障ETL任务的至少一个下游的ETL任务的第二责任方之后，根据预先设定的责任方和通知方式的绑定关系，确定所述故障ETL任务的第一责任方对应的第一通知方式，以及所述故障ETL任务的至少一个下游的ETL任务的第二责任方对应的第二通知方式；根据所述第一通知方式向所述第一责任方发送故障信息，以及根据所述第二通知方式向所述第二责任方发送预警信息。

8.如权利要求7所述的设备，其特征在于，所述故障信息包括下列信息中的部分或全部：

故障ETL任务的标识、下游的ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长；

所述预警信息包括下列信息中的部分或全部：

下游的ETL任务的标识、上游的故障ETL任务的标识、故障ETL任务的故障原因和故障ETL任务故障持续的时长。

Images