CN117193973A - 数据治理方法、装置、设备和存储介质 - Google Patents

Abstract

本发明实施例提供一种数据治理方法、装置、设备和存储介质，该方法包括：响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务对应的参考运行状态信息；根据实际运行状态信息和参考运行状态信息，确定至少一个任务中需要被治理的目标任务；根据所述目标任务的实际运行状态信息，确定目标任务的故障类型；根据故障类型，确定目标任务的数据治理方案。通过该方案，实现了对需要被治理的目标任务的针对性故障治理，避免资源浪费。

Description

数据治理方法、装置、设备和存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种数据治理方法、装置、设备和存储介质。

背景技术

资源池(Resources Pool)作为计算资源、存储资源和网络资源等多种资源的集合，实现了软、硬件资源的动态分配和调度使用，满足了云计算基础设施的需求。

通常资源池中的资源是有限的，当资源池中运行的任务超过一定数量时，会出现任务延迟等情况，例如某一任务未按预定时间点开始，或者是未按预定时间点结束等。

但是，在资源池的实际使用过程中，任务延迟并不一定是由于资源池的资源不足而导致的，如果盲目的选择购买资源，对资源池进行扩容，可能会导致资源的浪费，并不能真正的解决任务延迟的问题。为此，亟需一种数据治理方法，用以确定任务延迟的原因，治理任务延迟，避免资源浪费。

发明内容

本发明实施例提供一种数据治理方法、装置、设备和存储介质，用以对需要被治理的目标任务进行针对性的故障治理，避免资源浪费。

第一方面，本发明实施例提供一种数据治理方法，所述方法包括：

响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及所述至少一个任务对应的参考运行状态信息；

根据所述实际运行状态信息和所述参考运行状态信息，确定所述至少一个任务中需要被治理的目标任务；

根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型；

根据所述故障类型，确定所述目标任务的数据治理方案。

第二方面，本发明实施例提供一种数据治理装置，所述装置包括：

获取装置，用于响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及所述至少一个任务对应的参考运行状态信息；

处理模块，用于根据所述实际运行状态信息和所述参考运行状态信息，确定所述至少一个任务中需要被治理的目标任务；根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型；根据所述故障类型，确定所述目标任务的数据治理方案。

第三方面，本发明实施例提供一种电子设备，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现如第一方面所述的数据治理方法。

第四方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现如第一方面所述的数据治理方法。

在本发明实施例提供的方案中，响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务对应的参考运行状态信息。其中参考运行状态信息为任务正常运行状态下的运行状态信息。从而，根据至少一个任务的实际运行状态信息和参考运行状态信息，能够确定至少一个任务中需要被治理的目标任务，也即实际运行状态信息与参考运行状态信息存在差异的任务。之后，根据目标任务的实际运行状态信息，确定目标任务的故障类型，并根据故障类型，确定目标任务的数据治理方案，从而实现对目标任务的针对性治理，即基于目标任务的故障情况确定相应的数据治理方案，避免对所有故障类型的目标任务采用统一的治理方案而造成计算、存储资源的浪费。

附图说明

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

图1为本发明实施例提供的一种数据治理方法的流程图；

图2为本发明实施例提供的一种任务执行过程的示意图；

图3为本发明实施例提供的另一种数据治理方法的流程图；

图4为本发明实施例提供的又一种数据治理方法的流程图；

图5为本发明实施例提供的再一种数据治理方法的流程图；

图6为本发明实施例提供的一种数据治理装置的结构示意图；

图7为与图6所示实施例提供的数据治理装置对应的电子设备的结构示意图。

具体实施方式

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

需要说明的是，本发明实施例中所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

在云计算的应用场景中，任务的执行依赖于资源池中的计算资源和存储资源等各种资源，比如：计算任务在执行过程中通过调度、占用资源池中的计算资源完成计算等。实际应用中，往往会发生任务运行时间过长等问题，也即任务延迟。通俗来说，任务延迟就是任务在执行过程中，未按照预定时间执行，实际执行时间晚于预定时间。任务延迟会导致用户不能按时获取任务的执行结果，影响进一步的数据处理。

通常认为任务延迟是资源池中的资源不足导致的，可通过购买资源对资源池进行扩容以解决任务延迟的问题。但是，实际应用中，导致任务延迟的原因并不仅仅是资源池的资源不足，盲目的购买资源对资源池进行扩容，会导致资源浪费，也不能从根本上解决任务延迟的问题。

为解决上述至少一个技术问题，本发明实施例提供了一种数据治理方法，通过使用资源池内资源的任务在预设时间段内的实际运行状态信息，以及任务对应的参考运行状态信息，确定任务是否存在任务延迟的问题。若某一任务存在任务延迟问题，则对该任务进行治理。具体地，先确定该任务发生任务延迟的原因，然后，再根据任务延迟原因，对该任务进行治理。从而，可以有针对性的解决任务延迟问题，避免资源浪费。

图1为本发明实施例提供的一种数据治理方法的流程图，如图1所示，可以包括如下步骤：

101、响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务对应的参考运行状态信息。

102、根据实际运行状态信息和参考运行状态信息，确定至少一个任务中需要被治理的目标任务。

103、根据目标任务的实际运行状态信息，确定目标任务的故障类型。

104、根据故障类型，确定目标任务的数据治理方案。

本发明实施例提供的数据治理方法可以由一电子设备来执行，该电子设备可以是诸如PC机、笔记本电脑、智能手机等终端设备，也可以是服务器。该服务器可以是包含一独立主机的物理服务器，或者也可以为虚拟服务器，或者也可以为云端服务器或服务器集群。

为便于理解，先对一个任务利用资源池中的资源执行任务的完整过程作简要说明。图2为本发明实施例提供的一种任务执行过程的示意图。概括来说，如图2所示，一个任务的执行可以划分为三个阶段，分别为：调度任务阶段、等待用于执行任务的资源阶段、任务的执行阶段。

若将资源池中的资源按照用途进行划分，可以划分为调度资源和运行资源。其中，调度资源用于调度任务，运行资源用于实际运行任务。基于此，针对一个待执行任务，调度任务阶段，是指利用资源池中的调度资源调度待执行任务的阶段。由于在调度待执行任务之后，运行资源当前可能正在执行其他任务，因此，需要等待该运行资源执行完当前任务并处于空闲状态后，才能使用该运行资源执行待执行任务。等待用于执行任务的资源阶段，是指等待用于执行任务的资源执行完上一任务，处于可执行待执行任务状态的阶段。任务的执行阶段，是指运行资源开始运行待执行任务至结束运行待执行任务的阶段。

本实施例中，为便于对各任务的运行状态进行评估，根据任务执行对应的三个阶段所消耗的时长，从时间维度对各任务的运行状态进行了量化，用任务的总处理时长反映任务的运行状态信息。其中，某一任务的总处理时长为调度任务消耗的时长、等待用于执行任务的资源消耗的时长、任务的执行消耗的时长之和，任务的执行消耗的时长也为运行资源开始运行任务至结束运行任务的时长。简单来说，某一任务的总处理时长是指该任务从开始调度至结束运行之间的时间间隔。

可以理解的是，对于某一任务来说，基于该任务对应的数据和资源池中的资源，或者基于该任务对应的历史运行数据，能够确定该任务正常运行状态下的运行状态信息，比如：正常运行状态下该任务对应的总处理时长。其中，正常运行状态下该任务对应的总处理时长可以为一时长范围，并不局限于一个时长数值。同一任务在资源池中的资源配置不同的情况下，对应的总处理时长也可能不相同。本实施例中，也将任务在正常运行状态下的运行状态信息称为参考运行状态信息。

具体实施过程中，可以通过主动触发、设置触发条件(比如：任务结束运行后触发)或者设置定时任务的方式，触发数据治理任务，以对使用某一资源池内资源的至少一个任务进行评估，确定至少一个任务中是否存在任务延迟需要被治理的目标任务，若存在，则对目标任务进行数据治理，解决目标任务的任务延迟问题。

具体地，响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务对应的参考运行状态信息。其中，预设时间段可以根据设置的定时任务的时间间隔进行灵活配置，也可以根据实际的需要进行配置，比如：设置的相邻两个定时任务之间的时间间隔为1小时，则预设时间段可以为当前时刻之前的一小时内；或者实际需要对一天内的任务运行状态进行评估，则预设时间段可以为当前时刻之前一天内等。

为便于区分，将至少一个任务对应的实际运行状态信息中包含的总处理时长称为第一总处理时长，将至少一个任务对应的参考运行状态信息中包含的总处理时长称为第二总处理时长。

可选地，根据实际运行状态信息和参考运行状态信息，确定至少一个任务中第一总处理时长与第二总处理时长的第一差值大于预设的第一时间阈值的任务为需要被治理的目标任务。其中，目标任务对应的第一总处理时长与第二总处理时长的第一差值大于预设的第一时间阈值，也即目标任务的实际总处理时长超出了正常运行状态下该任务对应的总处理时长，任务处理超时，造成了任务延迟。

基于第一总处理时长和第二总处理时长，能够从至少一个任务中确定出存在任务延迟需要被治理的目标任务。然而，实际应用中，还存在一些任务，可能由于人为数据设置错误等原因，循环执行而无法确定其对应的总处理时长，但是这类任务确真实存在任务延迟的问题，这类任务在执行过程中往往会报错，被标识为运行故障。

因此，至少一个任务在预设时间段内的实际运行状态信息中还包括至少一个任务分别对应的运行状态指示标识。可选地，还可以确定至少一个任务中运行状态指示标识指示存在运行故障的任务为需要被治理的目标任务。

上述过程中，通过各任务对应的第一总处理时长和第二处理时长，从粗粒度将至少一个任务划分为两类，一种是需要被治理的、存在任务延迟问题的目标任务，另一种是不需要被治理的任务，完成了对至少一个任务的初步分类。

之后，针对需要被治理的目标任务进行进一步地细粒度划分，根据目标任务对应的实际运行状态信息，确定目标任务所属的故障类型，以根据故障类型对应的数据治理方案对目标任务进行数据治理，解决任务延迟的问题。

其中，故障类型是基于运行状态信息中的不同参数确定的，若目标任务对应的实际运行状态信息中的参数与某一故障类型x对应的参数匹配，比如：实际运行状态信息中的参数属于某一故障类型x对应的参数范围，则确定该目标任务存在故障类型x的故障，根据故障类型x对应的数据治理方案对目标任务进行数据治理。

需要说明的是，一个目标任务可能不至对应于一种故障类型，可能对应于多种故障类型。可选地，可以针对多种不同的故障类型组合，分别设置相应的数据治理方案，以在目标任务存在多种类型的故障时，进行综合数据治理。

本方案中，响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务在任务正常运行状态下的参考运行状态信息。从而，根据实际运行状态信息中至少一个任务各自从开始调度至结束运行的第一总处理时长和参考运行状态信息中至少一个任务各自从开始调度至运行结束的第二总处理时长，确定至少一个任务中第一总处理时长与第二总处理时长的第一差值大于预设的第一时间阈值的任务为需要被治理的目标任务，以及根据实际运行状态信息中至少一个任务分别对应的运行状态指示标识，确定至少一个任务中运行状态指示标识指示存在运行故障的任务为需要被治理的目标任务，以完成存在任务延迟需要被治理的目标任务的初步筛选。之后，根据目标任务的实际运行状态信息，确定目标任务的故障类型，以完成目标任务的二次分类。最后，根据故障类型，确定目标任务的数据治理方案，从而实现对目标任务的针对性治理，即基于目标任务的故障情况确定相应的数据治理方案，避免对所有故障类型的目标任务采用统一的治理方案而造成计算、存储资源的浪费。

实际应用中，每个任务在执行过程中对应的元数据会记录任务执行的完整信息，比如：总处理时长、计划开始调度时刻、实际开始调度时刻、开始运行的时间、结束运行的时间、任务的复杂度、任务之间的关联关系、任务的优先级等等。在图1所示的实施例中，依据至少一个任务对应的实际运行状态信息中的第一总处理时长和参考运行状态信息中的第二总处理时长，概括的确定处理存在任务延迟的目标任务。而进一步的确定目标任务的故障原因，也即确定目标任务的故障类型，则需要依赖元数据中的其他信息。

概括来说，导致目标任务发生任务延迟的故障原因可以分为三类，分别为：资源不足、数据结构异常和多任务挤占资源。以下结合具体实施例，分别说明确定目标任务对应的故障原因，也即故障类型的过程，以及不同的故障类型对应的数据治理方案。

图3为本发明实施例提供的另一种数据治理方法的流程图，如图3所示，可以包括如下步骤：

301、响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务对应的参考运行状态信息，实际运行状态信息包括：至少一个任务各自的计划调度时刻、实际调度时刻以及任务调度完成后至任务开始运行前的等待时长。

302、根据实际运行状态信息和参考运行状态信息，确定至少一个任务中需要被治理的目标任务。

303、若目标任务的实际调度时刻晚于计划调度时刻，则确定目标任务的故障类型为调度资源不足；若目标任务的实际调度时刻不晚于计划调度时刻，且目标任务对应的等待时长大于预设的第二时间阈值，则确定目标任务的故障类型为运行资源不足。

304、若目标任务的故障类型为调度资源不足或运行资源不足，则从资源池中预留资源给目标任务，以使目标任务在运行时使用预留资源。

其中，步骤301和步骤302的具体实施过程可参考前述实施例，本实施例中不再进行赘述。

本实施例中，实际运行状态信息还包括：至少一个任务各自的计划调度时刻、实际调度时刻以及任务调度完成后至任务开始运行前的等待时长。其中，计划调度时刻为进行任务设计时提前规划的任务调度时刻。

其中，至少一个任务各自的计划调度时刻、实际调度时刻以及任务调度完成后至任务开始运行前的等待时长，用于确定目标任务是否对应于资源不足这一故障类型。进一步地，资源不足还可划分为调度资源不足和运行资源不足。

可以理解的是，调度资源固定的情况下，能够调度的任务数量是有限的。当调度资源不足时，会导致任务不能被及时调度，从调度时间上反映就是实际调度时刻晚于计划调度时刻。因此，在确定目标任务是否存在调度资源不足这一故障类型时，若目标任务的实际调度时刻晚于计划调度时刻，则确定目标任务的故障类型为调度资源不足；若目标任务的实际调度时刻为计划调度时刻，则确定目标任务的不存在调度资源不足的故障。

针对调度资源不足这一故障类型，从资源池中预留资源给目标任务，以使目标任务在调度时使用该预留资源完成对目标任务的调度。可选地，可在完成调度之后释放该预留资源，以使该预留资源重新被其他任务占用。

任务完成调度之后，使用运行资源执行任务的过程中，前一任务结束运行后释放的运行资源以及资源池中的剩余运行资源均可用于后一任务的运行。但是，后一任务能够直接利用前一任务释放的运行资源以及资源池中的剩余运行资源的前提是：前一任务结束运行后释放的运行资源与资源池中的剩余运行资源足够多，至少等于后一任务执行所需要的运行资源。若前一任务结束运行后释放的运行资源以及资源池中的剩余运行资源不满足后一任务执行所需要的运行资源，则需要等待其他任务结束运行释放运行资源，直至资源池中整体的剩余运行资源(包括被释放的运行资源)满足后一任务执行所需的运行资源。因此，可以理解的是，当运行资源不足时，会导致任务被调度之后到开始运行任务之前的时间较长，也即等待用于执行任务的运行资源所消耗的时间较长。

基于此，在确定目标任务是否存在运行资源不足这一故障类型时，若目标任务的实际调度时刻不晚于计划调度时刻(即目标任务正常被调度)，且目标任务对应的等待时长大于预设的第二时间阈值，则确定目标任务的故障类型为运行资源不足。

其中，第二时间阈值可以为基于当前资源池中调度资源和运行资源的配置情况设置的一时间范围。可选地，该时间范围的下限为资源中存在空闲运行资源时对应的任务调度完成后至任务开始运行前的等待时长，上限为资源池中的运行资源全部被占用时对应的任务调度完成后至任务开始运行前的等待时长。

针对运行资源不足这一故障类型，从资源池中预留资源给目标任务，以使目标任务在运行时使用该预留资源执行目标任务。可选地，可在目标任务结束运行之后释放该预留资源，以使该预留资源重新被其他任务占用。

可选地，若目标任务的实际调度时刻晚于计划调度时刻，且目标任务对应的等待时长大于预设的第二时间阈值，则确定目标任务的故障类型为调度资源以及运行资源均不足。针对调度资源和运行资源均不足的这一故障类型，可认为是资源池中配置的资源不足，通过购买资源等方式解决资源不足的问题。

本方案中，通过至少一个任务各自的计划调度时刻、实际调度时刻以及任务调度完成后至任务开始运行前的等待时长，确定目标任务是否存在调度资源不足或运行资源不足的故障，当目标任务对应的故障类型为调度资源不足或运行资源不足时，通过从资源池中预留资源给目标任务的方式，解决目标任务延迟的问题。

图4为本发明实施例提供的又一种数据治理方法的流程图，如图4所示，可以包括如下步骤：

401、响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及至少一个任务对应的参考运行状态信息，实际运行状态信息包括：至少一个任务各自的开始运行时刻、结束运行时刻以及各任务的复杂度。

402、根据实际运行状态信息和参考运行状态信息，确定至少一个任务中需要被治理的目标任务。

403、若目标任务的开始运行时刻至结束运行时刻的第二差值大于预设的第三时间阈值，且目标任务的复杂度大于预设的复杂度阈值，则确定目标任务的故障类型为数据结构异常。

404、若目标任务的故障类型为数据结构异常，则根据数据结构对应的异常类型，确定目标任务的数据结构优化方案。

其中，步骤401和步骤402的具体实施过程可参考前述实施例，本实施例中不再进行赘述。

本实施例中，实际运行状态信息还包括：至少一个任务各自的开始运行时刻、结束运行时刻以及各任务的复杂度。其中，任务的复杂度与任务对应的数据结构相关，可通过与任务的数据结构关联的计算代码长度、数据量多少等信息表征，比如：当计算代码中的结构化查询语言(Structured Query Language，简称SQL)任务代码过长时，则任务的复杂度较高。

在任务的执行阶段，任务从开始运行到结束运行之间的时间间隔，不仅与资源相关，还与任务的复杂度相关。在任务的开发过程中，开发人员为各种任务设计相应的数据结构，当数据结构设置不当时，会导致任务的复杂度过高，从而导致任务从开始运行到结束运行之间的时间间隔过长，发生任务延迟。

因此，本实施例中，当目标任务的开始运行时刻至结束运行时刻的第二差值大于预设的第三时间阈值，且目标任务的复杂度大于预设的复杂度阈值，则确定目标任务的故障类型为数据结构异常。

可选地，第三时间阈值为与目标任务同类型的任务在任务复杂度低于预设的复杂度阈值时，对应的从开始运行时刻至结束运行时刻的时间差值。

可选地，复杂度阈值可以根据资源池中运行资源的配置情况进行设置；或者，根据至少一个任务中除目标任务外的其他任务的任务复杂度确定，比如：取其他任务的任务复杂度的均值作为复杂度阈值，或者取其他任务的任务复杂度的最大值为复杂度阈值；或者，根据目标任务中从开始运行时刻至结束运行时刻的第二差值小于等于预设的第三时间阈值的任务对应的任务复杂度，确定复杂度阈值，比如：取目标任务中从开始运行时刻至结束运行时刻的第二差值小于等于预设的第三时间阈值的任务对应的任务复杂度中的最大值或均值作为复杂度阈值。

针对数据结构异常这一故障类型，可根据数据结构对应的异常类型，确定目标任务的数据结构优化方案。其中，数据结构的异常类型包括：数据倾斜、SQL任务代码过长等。

具体实施过程中，若数据结构对应的异常类型为数据倾斜，则根据预设的优化规则，确定数据结构的优化参数，比如：在key-value中，进行key打散。一般地，相同的key总是会映射到相同的数据块上，当一个key对应存储有大量的value时，会导致数据分布不均。通过key打散，也即将一个大的key拆分为多个小的key,打散分到不同的数据块中，能够避免因为数据倾斜导致的数据分布不均。若数据结构对应的异常类型为SQL任务代码过长，则可将SQL任务拆分为多个小任务，以避免出现由于某一SQL任务代码过长，而发生数据倾斜。

本方案中，通过至少一个任务各自的开始运行时刻，结束运行时刻，以及各任务的复杂度，确定目标任务是否存在数据结构异常的故障，当目标任务对应的故障类型为数据结构异常时，通过根据数据结构的异常类型优化数据结构的方式，解决目标任务延迟的问题，而非直接为资源池添加资源，可以有效避免资源浪费。

图5为本发明实施例提供的再一种数据治理方法的流程图，如图5所示，可以包括如下步骤：

501、响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息、至少一个任务对应的参考运行状态信息以及至少一个任务之间的任务关联关系；实际运行状态信息包括：至少一个任务各自的计划调度时刻、开始运行时刻和结束运行时刻。

502、根据实际运行状态信息和参考运行状态信息，确定至少一个任务中需要被治理的目标任务。

503、根据实际运行状态信息，确定至少一个任务中在目标任务的开始运行时刻至结束运行时刻之间运行的第一任务，以及第一任务的总数量，第一任务包括目标任务；若目标任务的开始运行时刻至结束运行时刻之间的第三差值大于预设的第四时间阈值，且第一任务的总数量大于预设的数量阈值，则确定目标任务的故障类型为多任务挤占资源。

504、若目标任务的故障类型为多任务挤占资源，则根据任务关联关系，确定至少一个任务中与第一任务在执行过程中存在关联的第二任务；根据第一任务和第二任务的计划调度时刻，确定目标任务的计划调度时刻。

其中，步骤501和步骤502的具体实施过程可参考前述实施例，本实施例中不再进行赘述。

本实施例中，实际运行状态信息还包括：至少一个任务各自的计划调度时刻、开始运行时刻和结束运行时刻。

其中，至少一个任务各自的开始运行时刻和结束运行时刻，用于确定目标任务是否对应于多任务挤占资源这一故障类型，即是否是因为同时运行任务数量过多，导致任务相互之间挤占资源。至少一个任务各自的计划调度时刻用于对多任务挤占资源这一故障类型进行数据治理。

具体实施过程中，首先，根据实际运行状态信息中的开始运行时刻和结束运行时刻，确定至少一个任务中在目标任务的开始运行时刻至结束运行时刻之间运行的第一任务，其中，第一任务包括目标任务；之后，确定第一任务的总数量，若目标任务的开始运行时刻至结束运行时刻之间的第三差值大于预设的第四时间阈值，且第一任务的总数量大于预设的数量阈值，则确定目标任务的故障类型为多任务挤占资源。

其中，预设的数量阈值为：基于资源池中的资源配置情况，预设的能够同时运行的任务数量的最大值。第四时间阈值为与目标任务在同时运行的任务数量小于等于预设的数量阈值时，对应的从开始运行时刻至结束运行时刻的时间差值。

本实施例中，为了对多任务挤占资源这一故障类型进行数据治理，响应于数据治理任务的触发，还获取了至少一个任务之间的任务关联关系。

可以理解的是，不同的任务之间存在依赖关系，也即关联关系，比如：B任务的执行需要A任务的执行结果，即B任务依赖于A任务。鉴于任务之间的依赖关系，单一的只根据目标任务的计划调度时刻，重新对目标任务的调度时刻进行规划，可能会影响与目标任务存在关联关系的其他任务的执行。因此，本实施例中，当目标任务存在多任务挤占资源的故障时，基于任务之间的关联关系，重新规划目标任务的调度时刻，以避免出现同时执行多个任务的情形。

具体地，针对多任务挤占资源这一故障类型，先根据至少一个任务之间任务关联关系，确定至少一个任务中与第一任务在执行过程中存在关联的第二任务；之后，根据第一任务和第二任务的计划调度时刻，确定目标任务的计划调度时刻。

可选地，在根据第一任务和第二任务的计划调度时刻重新确定目标任务的计划调度时刻的同时，也可重新对除目标任务外的第一任务的计划调度时刻以及第二任务的计划调度时刻进行重新规划，以保证在相同时间段内同时运行的任务数量不超过预设的数量阈值。

可选地，实际运行状态信息还包括：至少一个任务各自的任务优先级；从而可以根据第一任务和第二任务的计划调度时刻和任务优先级，确定目标任务的计划调度时刻，以优先考虑调度任务优先级高的目标任务。

本方案中，通过至少一个任务各自的开始运行时刻，结束运行时刻，确定目标任务是否存在多任务挤占资源的故障。当目标任务对应的故障类型为多任务挤占资源时，根据至少一个任务之间的任务关联关系，确定至少一个任务中与第一任务在执行过程中存在关联的第二任务，并根据第一任务和第二任务的计划调度时刻，重新确定目标任务的计划调度时刻，以避免出现同时执行多个任务的情形，解决由于多任务挤占资源导致的目标任务延迟的问题。

以下将详细描述本发明的一个或多个实施例的数据治理装置。本领域技术人员可以理解，这些装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图6为本发明实施例提供的一种数据治理装置的结构示意图，如图6所示，该装置包括：获取模块11、处理模块12。

获取模块11，用于响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及所述至少一个任务对应的参考运行状态信息；

处理模块12，用于根据所述实际运行状态信息和所述参考运行状态信息，确定所述至少一个任务中需要被治理的目标任务；根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型；根据所述故障类型，确定所述目标任务的数据治理方案。

可选地，所述实际运行状态信息包括所述至少一个任务各自从开始调度至结束运行的第一总处理时长以及所述至少一个任务分别对应的运行状态指示标识，所述参考运行状态信息包括所述至少一个任务各自从开始调度至运行结束的第二总处理时长。所述处理模块12，具体用于确定所述至少一个任务中所述第一总处理时长与所述第二总处理时长的第一差值大于预设的第一时间阈值的任务为需要被治理的目标任务，或者，确定所述至少一个任务中所述运行状态指示标识指示存在运行故障的任务为需要被治理的目标任务。

可选地，所述实际运行状态信息还包括：所述至少一个任务各自的计划调度时刻、实际调度时刻以及任务调度完成后至任务开始运行前的等待时长。所述处理模块12，还具体用于若所述目标任务的实际调度时刻晚于计划调度时刻，则确定所述目标任务的故障类型为调度资源不足；若所述目标任务的实际调度时刻不晚于计划调度时刻，且所述目标任务对应的所述等待时长大于预设的第二时间阈值，则确定所述目标任务的故障类型为运行资源不足；若所述故障类型为所述调度资源不足或所述运行资源不足，则从资源池中预留资源给所述目标任务，以使所述目标任务在运行时使用所述预留资源。

可选地，所述实际运行状态信息还包括：所述至少一个任务各自的开始运行时刻、结束运行时刻以及各任务的复杂度。所述处理模块12，还具体用于若所述目标任务的开始运行时刻至结束运行时刻的第二差值大于预设的第三时间阈值，且所述目标任务的复杂度大于预设的复杂度阈值，则确定所述目标任务的故障类型为数据结构异常；若所述故障类型为所述数据结构异常，则根据所述数据结构对应的异常类型，确定所述目标任务的数据结构优化方案。

可选地，所述处理模块12，还具体用于若所述数据结构对应的异常类型为数据倾斜，则根据预设的优化规则，确定所述数据结构的优化参数。

可选地，所述实际运行状态信息还包括：所述至少一个任务各自的计划调度时刻、开始运行时刻和结束运行时刻。所述处理模块12，还用于响应于数据治理任务的触发，获取所述至少一个任务之间的任务关联关系；根据所述实际运行状态信息，确定所述至少一个任务中在所述目标任务的开始运行时刻至结束运行时刻之间运行的第一任务，以及第一任务的总数量，所述第一任务包括所述目标任务；若所述目标任务的开始运行时刻至结束运行时刻之间的第三差值大于预设的第四时间阈值，且所述第一任务的总数量大于预设的数量阈值，则确定所述目标任务的故障类型为多任务挤占资源；若所述故障类型为所述多任务挤占资源，则根据所述任务关联关系，确定所述至少一个任务中与所述第一任务在执行过程中存在关联的第二任务；根据所述第一任务和第二任务的计划调度时刻，确定所述目标任务的计划调度时刻。

可选地，所述实际运行状态信息还包括：所述至少一个任务各自的任务优先级；所述处理模块12，还具体用于根据所述第一任务和第二任务的计划调度时刻和任务优先级，确定所述目标任务的计划调度时刻。

图6所示装置可以执行前述实施例中介绍的步骤，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图6所示数据治理装置的结构可实现为一电子设备，如图7所示，该电子设备可以包括：存储器21、处理器22、通信接口23。其中，存储器21上存储有可执行代码，当所述可执行代码被处理器22执行时，使处理器22至少可以实现如前述实施例中提供的数据治理方法。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现如前述实施例中提供的数据治理方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (10)

1.一种数据治理方法，其特征在于，包括：

响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及所述至少一个任务对应的参考运行状态信息；

根据所述实际运行状态信息和所述参考运行状态信息，确定所述至少一个任务中需要被治理的目标任务；

根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型；

根据所述故障类型，确定所述目标任务的数据治理方案。

2.根据权利要求1所述的方法，其特征在于，所述实际运行状态信息包括所述至少一个任务各自从开始调度至结束运行的第一总处理时长以及所述至少一个任务分别对应的运行状态指示标识，所述参考运行状态信息包括所述至少一个任务各自从开始调度至运行结束的第二总处理时长；

所述根据实际运行状态信息和所述参考运行状态信息，确定所述至少一个任务中需要被治理的目标任务，包括：

确定所述至少一个任务中所述第一总处理时长与所述第二总处理时长的第一差值大于预设的第一时间阈值的任务为需要被治理的目标任务，或者，确定所述至少一个任务中所述运行状态指示标识指示存在运行故障的任务为需要被治理的目标任务。

3.根据权利要求2所述的方法，其特征在于，所述实际运行状态信息还包括：所述至少一个任务各自的计划调度时刻、实际调度时刻以及任务调度完成后至任务开始运行前的等待时长；

所述根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型，包括：

若所述目标任务的实际调度时刻晚于计划调度时刻，则确定所述目标任务的故障类型为调度资源不足；

若所述目标任务的实际调度时刻不晚于计划调度时刻，且所述目标任务对应的所述等待时长大于预设的第二时间阈值，则确定所述目标任务的故障类型为运行资源不足；

所述根据所述故障类型，确定所述目标任务的数据治理方案，包括：

若所述故障类型为所述调度资源不足或所述运行资源不足，则从资源池中预留资源给所述目标任务，以使所述目标任务在运行时使用所述预留资源。

4.根据权利要求2所述的方法，其特征在于，所述实际运行状态信息还包括：所述至少一个任务各自的开始运行时刻、结束运行时刻以及各任务的复杂度；

所述根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型，包括：

若所述目标任务的开始运行时刻至结束运行时刻的第二差值大于预设的第三时间阈值，且所述目标任务的复杂度大于预设的复杂度阈值，则确定所述目标任务的故障类型为数据结构异常；

所述根据所述故障类型，确定所述目标任务的数据治理方案，包括：

若所述故障类型为所述数据结构异常，则根据所述数据结构对应的异常类型，确定所述目标任务的数据结构优化方案。

5.根据权利要求4所述的方法，其特征在于，所述根据所述数据结构对应的异常类型，确定所述目标任务的数据结构优化方案，包括：

若所述数据结构对应的异常类型为数据倾斜，则根据预设的优化规则，确定所述数据结构的优化参数。

6.根据权利要求2所述的方法，其特征在于，所述实际运行状态信息还包括：所述至少一个任务各自的计划调度时刻、开始运行时刻和结束运行时刻，所述方法还包括：

响应于数据治理任务的触发，获取所述至少一个任务之间的任务关联关系；

所述根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型，包括：

根据所述实际运行状态信息，确定所述至少一个任务中在所述目标任务的开始运行时刻至结束运行时刻之间运行的第一任务，以及第一任务的总数量，所述第一任务包括所述目标任务；

若所述目标任务的开始运行时刻至结束运行时刻之间的第三差值大于预设的第四时间阈值，且所述第一任务的总数量大于预设的数量阈值，则确定所述目标任务的故障类型为多任务挤占资源；

所述根据所述故障类型，确定所述目标任务的数据治理方案，包括：

若所述故障类型为所述多任务挤占资源，则根据所述任务关联关系，确定所述至少一个任务中与所述第一任务在执行过程中存在关联的第二任务；

根据所述第一任务和第二任务的计划调度时刻，确定所述目标任务的计划调度时刻。

7.根据权利要求6所述的方法，其特征在于，所述实际运行状态信息还包括：所述至少一个任务各自的任务优先级；

所述根据所述第一任务和第二任务的计划调度时刻，确定所述目标任务的计划调度时刻，包括：

根据所述第一任务和第二任务的计划调度时刻和任务优先级，确定所述目标任务的计划调度时刻。

8.一种数据治理装置，其特征在于，包括：

获取装置，用于响应于数据治理任务的触发，获取至少一个任务在预设时间段内的实际运行状态信息，以及所述至少一个任务对应的参考运行状态信息；

处理模块，用于根据所述实际运行状态信息和所述参考运行状态信息，确定所述至少一个任务中需要被治理的目标任务；根据所述目标任务的所述实际运行状态信息，确定所述目标任务的故障类型；根据所述故障类型，确定所述目标任务的数据治理方案。

9.一种电子设备，其特征在于，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至7中任一项所述的数据治理方法。

10.一种非暂时性机器可读存储介质，其特征在于，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至7中任一项所述的数据治理方法。