CN113722141B - 数据任务的延迟原因确定方法、装置、电子设备及介质 - Google Patents

Abstract

本公开提供了数据任务的延迟原因确定方法、装置、电子设备及介质，涉及数据处理技术领域，尤其涉及大数据处理领域。具体实现方案为：针对内部任务的各内部实例，获得其对应的全链路运行诊断信息，基于该全链路运行诊断信息中包含的实例延迟诊断结果，确定延迟的内部实例及其上游延迟实例的运行诊断信息，根据目标实例信息和其各个上游的全链路运行诊断信息，按照设定的延迟归因策略，确定目标内部实例的延迟原因。本公开中，基于全链路运行诊断信息定位数据任务延迟的原因，实现了数据任务延迟的自动化归因，大大节约人力成本。

Description

数据任务的延迟原因确定方法、装置、电子设备及介质

技术领域

本公开涉及数据处理技术领域，尤其涉及大数据处理中数据任务的延迟原因确定方法、装置、电子设备及存储介质。

背景技术

随着业务发展，很多企业都会生产、加工大量的数据。从数据产生到数据呈现，会经过多个部门、多个团队的加工处理，数据链路十分复杂。任何一个数据任务节点发生延迟，都会使下游核心数据遭受延迟风险，因此，需要对数据链路进行分析，以确定出数据任务的延迟原因。

发明内容

本公开提供了一种用于自动确定数据任务的延迟原因的数据任务的延迟原因确定方法、装置、电子设备及介质。

根据本公开的一方面，提供了一种数据任务的延迟原因确定方法，包括：

针对各个内部任务的各个内部实例，从该内部实例的实例信息中获得该内部实例对应的全链路运行诊断信息；

基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的目标内部延迟实例和上游延迟实例的运行诊断信息；

基于所述目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因。

根据本公开的另一方面，提供了一种数据任务的延迟原因确定装置，包括：

运行诊断信息获取模块，用于针对各个内部任务的各个内部实例，从该内部实例的实例信息中获得该内部实例对应的全链路运行诊断信息；

目标内部延迟实例获取模块，用于基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的目标内部延迟实例和上游延迟实例的运行诊断信息；

延迟原因确定模块，用于基于所述目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行任一所述的数据任务的延迟原因确定方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据任一所述的数据任务的延迟原因确定方法方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据任一所述的数据任务的延迟原因确定方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开提供的数据任务的延迟原因确定方法的第一实施例的示意图；

图2是本公开中获取数据任务的内部实例的实例信息的第一实施例的示意图；

图3是本公开中获取数据任务的内部实例的实例信息的第二实施例的示意图；

图4是本公开中获取数据任务的内部实例的实例信息的第三实施例的示意图；

图5是本公开中获取数据任务的内部实例的实例信息的第四实施例的示意图；

图6是本公开中获取数据任务的内部实例的实例信息的第五实施例的示意图；

图7是本公开中获取数据任务的内部实例的实例信息的流程示意图；

图8是根据本公开提供的数据任务的延迟原因确定方法的第二实施例的示意图；

图9是根据本公开提供的数据任务的延迟原因确定方法的一种流程示意图；

图10是根据本公开提供的数据任务的延迟原因确定装置的第一实施例的示意图；

图11是根据本公开提供的数据任务的延迟原因确定装置的第二实施例的示意图；

图12是根据本公开提供的数据任务的延迟原因确定装置的第三实施例的示意图；

图13是用来实现本公开实施例的数据任务的延迟原因确定方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为了自动确定数据任务的延迟原因，本公开提供了一种数据任务的延迟原因确定方法、装置、电子设备及存储介质。

参见图1，图1为根据本公开提供的数据任务的延迟原因确定方法的第一实施例的流程示意图，上述方法具体可以包括以下步骤：

步骤S110、针对各个内部任务的各个内部实例，从该内部实例的实例信息中获得该内部实例对应的全链路运行诊断信息；

步骤S120、基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的目标内部延迟实例和上游延迟实例的运行诊断信息。

步骤S130、基于所述目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因。

本公开提供的数据任务的延迟原因确定方法，针对内部任务的各内部实例，获得其对应的全链路运行诊断信息，基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的内部延迟实例和上游延迟实例的运行诊断信息，根据目标实例信息和其各个上游的全链路运行诊断信息，按照设定的延迟归因策略，确定目标内部实例的延迟原因。本公开中，基于全链路运行诊断信息定位数据任务延迟的原因，实现了数据任务延迟的自动化归因，大大节约人力成本。

本公开实施例中，全链路的数据处理任务可以基于研发团队被划分为不同的任务组，每个任务组包含至少一个任务。本公开提供的数据任务的延迟原因确定方法，是针对每个任务组来实现的，该任务组中的各个任务被称为内部任务，其他任务组中的任务被称为外部任务。

通常，数据任务的执行过程分为依赖检查，即检查任务依赖的上游数据是否就绪和引擎(Spark)计算两个阶段；Spark计算阶段是指将任务逻辑提交给集群运行的过程。本公开实施例中，可以在数据任务执行过程中，采集实例信息。

本公开实施例中，在采集实例信息之前，可以预先采集并注册各内部任务包含的元数据，上述元数据可以包括以下三种数据：当前内部任务对下游任务承诺产出时效的核心数据、对当前内部任务承诺产出时效的上游外部数据，以及其他中间节点数据。其中，前两种数据可以是由人工收集，而上述其他中间节点数据则可由系统自动注册。在对上述元数据进行注册时，具体可以是从数据归属、数据类型、数据分区类型以及时效几个方面对上述数据进行注册：

从数据归属方面，在注册数据时可以区分数据属于内部数据还是外部数据，并确定数据的接口人信息，对于一个业务来说，其一般可以包括不同的任务，而不同的任务可以由不同的团队来完成，因此，本公开中，对于一个任务来说，该任务内部的产生的数据就可以被注册成内部数据，相应的，不是由该任务产生，而是由其他任务产生的数据则可以被注册为外部数据。

从数据类型方面，在注册数据时可以区分一个数据属于哪种数据类型，即可以表明数据的属性。通常的数据类型可以分为两种，一种是数仓表(如Hive Metastore表)数据，一种是分布式文件系统(如HDFS，Hadoop分布式文件系统)数据。数仓即数据仓库(DataWarehouse)，是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策，数据仓库的数据一般数据量大，且数据维度较多，本公开中对于数仓表数据，可以注明其命名空间、库名、表名、分区键以及更新周期等信息。分布式文件系统(Distributed File System，DFS)是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连；或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统，本公开中，对于分布式文件系统数据，则可以注明其集群地址、数据就绪文件的路径、时间通配占位符等信息。

从数据分区类型方面来说，可以明确数据的分区键(如event_day(事件日期)，event_hour(事件小时)等)和数据的更新周期(如Day、Hour、Minute等)。

从时效方面，可以注明上述当前内部任务对下游任务承诺产出时效的核心数据、对当前内部任务承诺产出时效的上游外部数据，以及其他中间节点数据的可保证的或是期望的产出时效、一个月最大延迟次数信息等。

作为一种实施方式，上述内部任务的元数据可以统一存储在一个元数据表中。这样，本实施例中，可以针对每个内部任务的每个内部实例，基于预先注册的元数据信息，采集包含该内部实例及所有与其相关的各个相关实例的全链路数据血缘信息，和包含实例延迟诊断结果的全链路运行诊断信息。

本公开实施例中，通过对内部任务的元数据进行统一存储，实现了各数据的归一化存储，提高了各实例调用相应元数据的便利性，也提高了获取内部实例的实例信息的便利性。

作为本公开实施例的一种具体实施方式，上述步骤S110具体可以是：

从定时采集的各个内部任务的各个内部实例的实例信息中，获得该内部实例对应的全链路运行诊断信息。

上述采集各内部实例的实例信息的定时时刻可以根据采集周期得到，而采集周期可以是相关人员根据实际的业务需求人为设置，例如可以设置采集周期是1小时，并将基准时间设置为某个整点时刻，那么定时时刻就是各整点，如7点、8点、9点等，相应的，在各整点，系统就可以自动采集各内部任务实例的实例信息，并将信息显示在报表中。上述基准时间也可以设置为实例数据产生的时间，此处不做具体限定。

在本公开的一种实施例中，如图2所示，上述各内部任务的各内部实例的实例信息可以是采用以下步骤采集：

步骤S210、按预设第一定时时刻，初始化每个内部实例的实例信息。

如上所述，在注册内部任务的元数据时，会注册数据的更新周期，该更新周期可以是一天、一小时或一分钟等，因此，本公开实施例中可以按照一定的初始化周期，定时对各内部任务实例的实例信息进行初始化，该实例的初始化周期可以根据上述数据的更新周期进行设置。

例如，对于天级数据(更新周期为一天)，可以设置对应实例的初始化周期为一天，如可在每天凌晨00：00进行对应的实例初始化；对于小时级(更新周期为一小时)，可以设置对应实例的初始化周期为一小时，如可在每个整点进行对应的实例初始化。

步骤S220、针对每个内部实例，采集全链路数据血缘信息；

步骤S230、在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息；

该定时时刻即上述采集内部实例的实例信息的时刻。

本实施例中，可以涉及三个定时周期：

(1)实例初始化周期：如天级别表可以每天初始化一次，小时级可以每小时初始化一次。上述的预设第一定时时刻，就是基于实例初始化周期得到的。

(2)运行诊断信息的采集周期：针对已初始化好、并且还未采集、且未处于锁定状态的实例，可以定时采集。上述的第二定时时刻，就是基于运行诊断信息的采集周期得到的。

(3)数据更新周期：即注册元数据时，用于区分一个数据是按天、按小时等更新分区。

如上所述，本公开实施例中，采集的各内部实例的实例信息除包括该内部实例的全链路运行诊断信息之外，还可以包含内部实例以及各相关实例的血缘信息。上述实例之间的血缘信息可以指的是实例与实例之间的依赖关系，例如，对于一个内部实例来说，其运行过程中可能需要使用上游实例产生的数据，而其运行产生的数据则可以被下游实例使用，这就是实例与其上游、下游实例的依赖关系。如上所述，定时采集的内部任务的元数据可以包括当前内部任务对下游任务承诺产出时效的数据、对当前内部任务承诺产出时效的上游外部数据，以及其他中间节点数据，因此，从这些数据中即可以构建各内部任务的各实例与其相关实例之间的血缘关系，形成实例血缘拓扑。

作为一种具体实施方式，上述血缘关系可以以实例关系表的形式进行存储，一个实例的实例关系表中可以存储该实例的实例血缘信息，即可以存储该实例的上游实例ID、下游实例ID以及上游拓扑深度信息等。上述各实例的ID可以由开发人员在存储各内部任务的实例时人为设置。

步骤S240、将所述全链路运行诊断信息，添加至该内部实例的实例信息中。

也就是说，各内部实例的实例信息中可以包含该实例的全链路数据血缘信息，以及包含实例延迟诊断结果的全链路运行诊断信息。

本实施例中，可以对全链路运行诊断信息进行预处理，预处理的目的是为延迟归因做判断。预处理的过程，可以包括：

1.获取内部实例运行诊断信息，进行格式处理后存储；

2.若内部实例发生延迟，则可根据上下游关系，得到其上游内部延迟实例、上游外部延迟实例。

现有技术中，未实现基于全链路的自动化归因。延迟归因本质上还是只针对单任务节点，是针对一个实例，人工查任务详情，按拓扑人工逐一向上查上游实例，定位原因的时间长，效率低。可以就是或在延迟归因排查过程中，仍然需要人工干预定位原因，未能释放人力。

本公开实施例中，通过定时采集各内部任务的各内部实例的实例信息，可以获取各内部实例的上游实例信息，无需人工对上游实例进行逐一查找，提高定位上游实例的效率，且采集的各内部实例信息中可以包含实例间的全链路血缘信息，实现了基于实例血缘关系的全链路拓扑的自动获取，无需人工对各实例之间的关系进行梳理，大大节省人工成本，提高数据任务延迟原因确定的效率。

作为本公开的一种实施例，基于图2，如图3所示，上述步骤S220，可以细化为：

步骤S220'、针对每个内部实例，基于预先注册的元数据信息，采集包含该内部实例及所有与其相关的各个相关实例的全链路数据血缘信息；

相应的，上述步骤S230可以细化为：

步骤S230'、在第二定时时刻到达的情况下，基于预先注册的元数据信息和所述全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息。

本公开实施例中，使用用户可以在操作页面中输入或选择要查询的数据任务名称。系统则可以从上述注册的各内部任务的元数据信息中，往上游追溯用户要查询的数据的处理过程，不断查询其上游数据节点，一直查找到数据源节点。从下往上的节点拓扑类似于树这一数据结构，根节点为要查询的数据，其余节点均是该数据的直接或间接上游数据。本公开中，为了一次性获取到全链路的运行诊断信息，可以对树进行扁平化处理，即可以遍历树的所有节点，存储于数组后统一返回。

本公开实施例中，上述返回数据可以封装为一个API(Application ProgramInterface，应用程序接口)，API是一些预先定义的接口(如函数、HTTP接口)，或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节，该API中还可以包含各实例的历史时效统计值、任务各阶段时间点、任务各阶段耗时等。

本公开实施例中，可以确定用户输入需要查询的数据任务名称的时刻为基准时间，在确定任务的基准时间后，就可以通过上述API获取与基准时间相对应的用户选择的目标数据任务的内部实例的实例信息，以及目标数据任务的各内部实例的上下游实例的实例信息。上述实例信息中就可以包含该时间对应的实例的运行状态信息。

上述基准时间可以与上述分区一致，如若基准时间选定为2021-01-0101:00:00，那么其对应的数据分区就可以是event_day为20210101，event_hour为01，相应的，在采集实例信息时，就可通过API采集相应分区中的数据信息来对实例进行运行状态的诊断。

本公开实施例中，可以基于预先注册的元数据获取目标任务的各内部实例的全链路运行诊断信息以及其与相关实例的血缘关系，而预先注册的元数据是统一存储的，因此可以大大节省实例信息的获取时间，提高获取实例信息的便利性。

参见图4，上述步骤S230可以包括以下步骤：在第二定时时刻到达的情况下：

步骤S410、获取并锁定一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；

对于一个内部任务来说，其一般可以包含一个或多个实例，本公开实施例中，可以获取选定的内部任务的任一未获得全链路运行诊断信息且处于未锁定状态的实例作为当前内部实例。

步骤S420、判断当前内部实例是否就绪；若当前实例已就绪，则执行步骤S430；若当前实例未就绪，则执行步骤S440；

步骤S430、基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息。

在锁定当前内部实例后，即可通过上述API查询该内部实例的全链路运行诊断信息。采集时，可以判断上述基准时间对应的数据分区是否就绪，即该分区中的数据是否可以被加载，例如，若实例正在运行中，则该实例对应的数据分区就是未就绪的。若该数据分区就绪，则可以进行实际产出时效的计算与实例是否延迟的判断；若该数据分区未就绪，则可以解锁该实例，获取并锁定下一个内部实例。

当然，在采集上述当前内部实例的实例信息后，也可以解锁该实例，此处不作具体限定。

步骤S440、解锁该内部实例；

步骤S450、锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例，返回步骤S420。

经过上述步骤S410～步骤S450即可获取目标数据任务中的各内部实例的全链路运行状态。

本公开实施例中，每次定时采集实例信息的对象是：未采集运行信息且未被锁定的内部实例，对于本次定时时刻到达时未就绪的实例(例如，正在运行的实例)，则可以将该实例在该定时时刻未就绪的信息添加至相应的实例信息中，并在下一定时时刻对其进行是否就绪的判断，若就绪则可以采集其实例信息，若未就绪，则再到下一定时时刻判断其是否就绪。本发明实施例中，通过定时采集未就绪实例的实例信息，无需一直对其进行锁定、解锁操作，节省资源消耗，且进一步提高采集实例信息的便利性。

本公开实施例中，可以采用Spark例行调度和实例加锁的方法实现对各内部实例的并发控制。基于Spark例行调度，可以将多个需要运行的Spark应用(Spark Application)加入队列中，以实现这些应用的并发处理，可提高实例信息的采集效率。而为防止占用过多的队列资源，可以限制Spark应用的个数。每一个任务在执行运行诊断逻辑的前后，会分别执行Application的入场登记和退场登记。如果入场登记时发现运行中的Application个数已达到设定的最大个数，则不执行诊断逻辑，直接退出。多个正在运行的SparkApplication，会从同一张实例表获取待查询数据实例，为防止同一个数据实例被重复查询，会对正在查询的数据实例进行加锁，只有该数据未就绪时，才会释放锁，等待下次查询。

上述Spark Application可以是Spark提交脚本(Spark-submit)提交的Spark应用程序，一个完整的Spark应用程序可以包括获取数据输入、处理数据、输出结果几个步骤。对于本公开实施例，上述Spark Application数据的结果就可以是数据任务内部实例的运行状态，即该实例是否产生延迟。

本公开实施例中，通过采用锁定的方式对各实例的实例信息进行采集，通过对正在查询的数据实例进行加锁，只有该数据未就绪时，才会释放锁，等待下次查询，可以防止同一个数据实例被重复查询。

基于图2，参见图5，在本公开其他实施例中，上述步骤S230可以包括：

步骤S231、在第二定时时刻到达的情况下，针对该内部实例及其每个相关实例，基于该内部实例的指定基准时间对应的实际产出时效，确定该实例是否发生延迟，得到该内部实例及其每个相关实例的实例延迟诊断结果；

如上所述，在进行链路延迟原因确定时，会确定一个的基准时间，也就是说，进行延迟原因确定具体是确定某一时间内各实例的运行是否有延迟。

本公开实施例中，可以根据基准时间从上述元数据表中获取对应的实例的期望产出时效，并计算出实例的实际产出时效，并将该实际产出时效与期望的产出时效进行比较来得到该实例是否延迟的判断结果。

步骤S232、将该内部实例及其每个相关实例的实例延迟诊断结果，确定为该内部实例对应的全链路运行诊断信息。

与上述内部实例的血缘信息相似，本公开实施例中，上述各内部实例的实例信息也可以以实例表的形式进行存储。一个内部实例的实例表中可以存储该实例的运行诊断信息、时效信息以及是否延迟的信息。

本公开实施例中，可以根据实例的实际产出时效以及期望产出时效确定各实例是否发生延迟，实现了对全链路数据的时效性监控，可以在一个较长时间范围内，统计各内部实例的实例信息，无需实时对实例信息进行采集，且无需人工计算，节省了人力成本，提高了实例的全链路运行诊断便利性。

本公开实施例中，基于图5，参见图6，上述步骤S231具体可以包括：

步骤S2311、在第二定时时刻到达的情况下，针对该内部实例及每个相关实例，基于所述指定基准时间及预设的数据更新周期，确定与更新周期对应的目标数据分区；

如上所述，若基准时间为2021-01-01 01:00:00，那么其对应的数据分区就是event_day＝20210101，event_hour＝01对应的分区。

步骤S2312、基于目标数据分区中的数据产出时刻，计算目标数据分区的实际产出时效，基于实际产出时效和期望产出时效，确定该实例是否发生延迟，得到实例延迟诊断结果。

数据分区的产出时效可以采用以下方法计算：如果更新周期为Day(一天)，则其产出时效(h)＝[数据时间产出时间戳(s)-基准时间戳(s)-24*3600]/3600；如果更新周期为Hour/Minute(一小时/一分钟)，那么其实际产出时效(h)＝[数据时间产出时间戳(s)-基准时间戳(s)]/3600。

计算出目标数据分区的实际产出时效后，即可将其与该目标数据的期望产出时效进行比较，对于数据提供方已明确保证产出时效的数据，实际产出时效大于可保证时效，则判断为发生延迟；对于未保证时效的数据，期望时效采用执行运行诊断后返回的四分位时效，若实际产出时效大于期望时效，则判断为发生延迟。例如：可以将对采集到实际时效进行统计，把所有统计的实际时效数值由小到大排列并分成四等份，处于三个分割点位置的数值，就是四分位数(Quartile)，本实施例中可以将较小四分位时效作为期望时效，当然在其他实施例中也可以将中位数作为期望时效。

本公开实施例中，根据目标数据的分区计算其实际产出时效，并将实际产出时效与该数据的期望产出时效进行比较判断实例是否发生延迟，实现了实际产出时效的自动计算，和实际产出时效与期望产出时效的比较，从而实现了实例是否延迟的自动判断，无需人工介入，节省人力成本。

本实施例中，每个内部实例的实例信息可以存储在该实例的实例表中。每个实例表可以用实例表ID来标识。

如图7所示，图7是本公开中运行诊断信息采集存储的执行流程图：

步骤1、基于元数据表中的数据基本信息和待监测实例的实例表ID，选定内部实例对应的监测实例表。

数据基本信息包含了数据的数据类型(数仓表/分布式文件系统)、更新周期(一天/一小时/一分钟)以及数据归属(内部/外部)。

监测实例表中可以包含实例表的实例表ID、对应的实例的分区信息、时效信息以及实例运行信息。

步骤2、在该实例表中锁定一实例，将该实例的实例信息输入预设的运行诊断API，并利用该API进行运行诊断，以获取该实例运行诊断信息、该实例的上游实例运行诊断信息、该实例上游实例的上游实例运行诊断信息等等。

步骤3、判断该实例对应的数据分区是否就绪(数据分区是否就绪判断)，若该数据分区未就绪，则解锁该实例，选择下一实例进行锁定，返回步骤2；若该数据分区就绪，则进行该实例的时效计算与是否延迟判断，并将计算以及判断的结果写入数据基本信息。

步骤4、更新对应的数据基本信息以及实例表。

步骤5、获取并更新该实例的实例血缘信息，上述血缘信息可以包括该实例的上游实例ID、下游实例ID以及该实例到数据源的拓扑深度。

如上所述，各内部实例的实例信息中包含该实例是否发生延迟的判断结果以及该实例的上下游实例信息，因此，可以基于各内部实例的实例信息获取到发生延迟的目标内部延迟实例，并获取到该目标内部延迟实例以及其各上游实例的全链路诊断信息，之后即可基于上述信息对该目标实例的延迟原因进行确定。

因此，基于图1，参见图8，上述步骤S130可以包括：

步骤S131、基于预设的内部任务的范围，从各个目标上游实例中获得目标外部上游实例；

通常，在实际应用中，一个业务可以包含多个任务，例如，对于广告业务来说，其包括的任务可以是筛选、匹配、排序、展示等，而每个任务可能是分给不同的人来做的，而每个任务可能需要用到其他任务产生的数据，例如，对于排序任务来说，其可能需要用到匹配任务产生的结果。

上述目标实例是选定的要查询的数据任务的内部实例，而对应的目标外部上游实例，就是目标实例需要依赖的其他任务的实例。

步骤S132、基于各个目标外部上游实例的上游全链路运行诊断信息，判断是否有目标外部上游实例发生延迟；

步骤S133、若有目标外部上游实例发生延迟，则确定目标内部延迟实例的延迟原因为外部数据延迟；

本公开实施例中，目标数据任务的内部实例作为上游外部实例的下游节点，可明确感知到外部的数据发生延迟，但并不能确定具体是哪个外部实例发生了延迟，因此，本公开实施例可以将非本任务内部数据的数据延迟，统一归纳为外部数据延迟。

步骤S134、若没有目标外部上游实例发生延迟，则基于目标内部延迟实例的资源耗时信息，确定是否为内部资源耗时延迟。

当使用spark-submit提交一个Spark作业之后，这个作业就会启动一个对应的驱动器(Driver)进程。Driver进程要做的第一件事情，就是向集群管理器申请运行Spark作业需要使用的资源。具体申请资源的大小取决于用户设置的资源参数。如果此时计算队列限额(quota)不足，或用户申请资源过大，可能会导致申请资源的时间过长，进而导致数据发生延迟。

Spark中的Driver即运行上述Application的主(main)函数并创建SparkContext，创建SparkContext的目的是为了准备Spark应用程序的运行环境，在Spark中有SparkContext负责与ClusterManager(集群管理器)通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后，Driver同时负责将SparkContext关闭。上述Executor具体可以是Executor框架，Executor框架是一个用于统一创建与运行的接口，可以实现线程池的功能。

是否是资源问题造成的延迟可以是由资源等待耗时占比的大小确定，可由相关人员自定义阈值。上述资源等待耗时占比＝资源等待耗时/(资源等待耗时+任务计算时长)*100％。在判断是否是资源问题造成的延迟时，需要排除内部的非延迟实例。对于某些内部实例，任务计算时间较小，会导致资源等待耗时占比较大。如果内部实例未发生延迟，就没有必要关注资源等待耗时占比，因此需要排除这类实例。

步骤S135、若目标内部延迟实例，未确定为外部数据延迟且未确定为内部资源耗时延迟，则确定目标内部延迟实例的延迟原因为其他原因。

除以上两种可明确表示的问题外，数据延迟的原因还可以包括任务本身问题、权限问题、集群问题、平台问题等，这需要根据具体任务具体分析，本公开中可以统一归纳为其它原因。

本公开中，若确定出的延迟原因为其他原因，则可以通过人工分析的方式获得具体的延迟原因。具体的，可以是将各内部任务详情显示在屏幕上，由人工基于任务详情分析出具体的延迟原因。

在本公开的延迟归因策略中，数据延迟归因具有唯一性，归因优先级由高到低依次为：外部数据延迟>内部资源耗时延迟>其它原因。

后续，一段时间后，可以对各个内部实例的延迟情况进行统计分析，来得到上述三种延迟原因的占比。

本公开实施例中，实现了基于目标内部实例的目标实例信息以及目标实例的上下游实例的实例信息对目标内部实例的延迟原因的自动化确定，无需人工多次追溯上游数据，降低了数据维护的人力，且可以从归因的历史数据中统计出各类延迟原因占比，使数据稳定性治理更具有针对性。

参见图9，图9是本公开中基于目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因的一种流程示意图：

本实施例中，采集到各实例及其上游实例的实例信息后，可以将各实例的实例信息保存至实例列表中。

如图9所示，步骤1、在流程开始后，从内部实例延迟列表中选择一个内部延迟实例，并从上游实例列表中确定该内部延时实例依赖的上游实例列表进行分析(待分析实例)。

作为一种具体实施方式，实例列表中可以包含内部实例延迟列表以及其上游实例列表，上述内部实例延迟列表中可以包含任务的各内部实例中发生延迟的内部实例，上述上游实例列表中可以包含上述内部延迟实例的上游外部实例列表以及上游内部实例列表。

步骤2、将上述待分析实例拆分为内部实例列表以及外部实例列表。

上述内部实例列表中可以包括任务的各内部实例的实例信息，例如上述内部延迟实例信息，以及内部延迟实例的上游内部实例的实例信息，而外部实例列表则可以包含与上述内部实例关联的其他任务的实例的实例信息，如上述上游外部实例。

步骤3、对外部实例列表进行分析，确定其中是否包含延迟实例，若包含延迟实例，则可以确定延迟的原因是外部数据延迟；若外部实例列表中不包含延迟实例，则可确定内部实例列表中是否包含延迟实例，若内部实例列表中不包含延期实例，则延迟原因为任务问题/其他问题；若内部实例列表中包含延迟实例，则判断该延迟实例的资源等待耗时占比是否超过(>)预设阈值，该预设阈值可以是开发人员基于实际需求确定。若大于，则可确定延迟的原因是内部资源耗时延迟，若不大于，则可以确定延迟的原因是任务问题或者其他问题。

步骤4、确定延迟原因后，更新实例信息后结束流程。

更新时，可以将延迟原因写到内部实例的实例表中。

可见，本公开实施例中，实现了元数据的统一管理以及实例全链路自动化归因，且在采集内部实例及相关内部实例以及外部实例的实例信息时计算时效，并基于时效判断是否发生延迟，实现了所有数据的时效闭环监控，对于内部数据和外部数据，时效监控实现100％覆盖。通过定期复盘各份数据的时效达成情况，可以促使数据提供方及时发现问题并优化，进一步提升数据产出稳定性。

下面，针对现有技术的大数据延迟归因方式，对本公开提供的数据任务的延迟原因确定方法的有益效果进行详细分析。

现有技术中，大数据延迟归因普遍采用以下两种传统方式：

一种方式是单数据任务的自动化延迟归因方案：

如上所述，数据任务的执行过程分为依赖检查和Spark计算两个阶段，该方案是通过表示单任务节点的各阶段的运行状态、分析各阶段耗时相较于历史统计均值的变化，自动分析数据延迟原因。若延迟原因是上游数据未就绪，则需要人工追溯到产出该上游数据的任务，再分析延迟原因。

另一种方式是全链路数据任务延迟原因分析方案：

该方案是通过分析每个任务的依赖数据和产出数据，推断出全链路数据任务的血缘拓扑，并且支持查询任意一个任务实例的入度链路和出度链路，在链路中会标识各任务实例的运行状态(未运行、运行中、已完成、失败等)。该方案中，排查数据延迟原因的过程如下：查询延迟的任务实例入度链路，通过状态标识，定位到阻塞实例，依次排查堵塞实例的依赖检查、资源等待、任务运行是否正常。

该方案提供了基于数据血缘拓扑的全链路，相较于方案一，不再需要人工推断上游任务，提升了人工识别阻塞任务的速度。但是在延迟原因分析上，还是由人工进行干预分析，未实现基于全链路的自动化延迟归因。

可见，现有技术中缺乏对全链路数据的时效性监控。且仅针对延迟个案具体分析延迟原因，这很难在一个较长时间范围内，统计各节点数据的产出时效变化，从而导致数据提供方很难发现问题。

而本公开实施例中，在采集实例信息之前就可预先将任务的各元数据汇总，可支持元数据的手动更新，方便用户得到任务的上游依赖数据。且本公开中，在采集内部任务的各实例以及其相关实例的实例信息时，就可采集到各实例的血缘信息，且可基于时效信息采集“实例延迟诊断结果”实现对全链路数据的时效性监控。后续基于各实例的全链路诊断结果就可以得到延迟的原因，无需人工多次追溯上游数据，且可统计各数据在一段时间范围内的时效、延迟次数、实际达成率等统计值，以便数据提供方了解现状并优化；且通过自动归因可以有力降低人工分析成本，提升延迟归因的时效性和准确性，同时可以获取一定时间范围内各类延迟原因占比，针对性优化提升数据全链路的稳定性。

本公开还提供了一种数据任务的延迟原因确定装置，参见图10，该装置可以包括：

运行诊断信息获取模块1010，可以用于针对各个内部任务的各个内部实例，从该内部实例的实例信息中获得该内部实例对应的全链路运行诊断信息；

目标内部延迟实例获取模块1020，可以用于基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的目标内部延迟实例和上游延迟实例的运行诊断信息；

延迟原因确定模块1030，可以用于基于所述目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因。

本公开提供的数据任务的延迟原因确定装置，针对内部任务的各内部实例，获得其对应的全链路运行诊断信息，基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的内部延迟实例和上游延迟实例的运行诊断信息，根据目标实例信息和其各个上游全链路运行诊断信息，按照设定的延迟归因策略，确定目标内部实例的延迟原因。本公开中，基于全链路运行诊断信息定位数据任务延迟的原因，实现了数据任务延迟的自动化归因，大大节约人力成本。

在本公开的一种实施例中，基于图10，参见图11，所述运行诊断信息获取模块1010，具体可以包括：

实例初始化子模块1011，用于按预设第一定时时刻，初始化每个内部实例的实例信息；

全链路运行诊断信息获取子模块1012，用于针对每个内部实例，采集全链路数据血缘信息，并在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息；

全链路运行诊断信息添加子模块1013，用于将所述全链路运行诊断信息，添加至该内部实例的实例信息中。

在本公开其他实施例中，所述全链路运行诊断信息获取子模块1012，可以具体用于：

针对每个内部实例，基于预先注册的元数据信息，采集包含该内部实例及所有与其相关的各个相关实例的全链路数据血缘信息，并在第二定时时刻到达的情况下，基于预先注册的元数据信息和所述全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息。

在本公开的一种实施例中，所述全链路运行诊断信息获取子模块1012可以具体用于：

在第二定时时刻到达的情况下，获取并锁定一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；

判断所述当前实例是否就绪，若当前内部实例已就绪，则基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息，锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；若所述当前内部实例未就绪，则解锁该内部实例，锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例。

基于图11，参见图12，在本公开的一种实施例中，所述全链路运行诊断信息获取子模块1012，可以包括：

延迟诊断结果确定子模块1221，用于在第二定时时刻到达的情况下，针对该内部实例及其每个相关实例，基于该内部实例的指定基准时间对应的实际产出时效，确定该实例是否发生延迟，得到该内部实例及其每个相关实例的实例延迟诊断结果；

在本公开其他实施例中，所述延迟诊断结果确定子模块1221，具体可以用于：

在第二定时时刻到达的情况下，针对该内部实例及每个相关实例，基于所述指定基准时间及预设的数据更新周期，确定与更新周期对应的目标数据分区；

基于目标数据分区中的数据产出时刻，计算目标数据分区的实际产出时效，基于实际产出时效和期望产出时效，确定该实例是否发生延迟，得到实例延迟诊断结果。

运行诊断信息确定子模块1222，用于将该内部实例及其每个相关实例的实例延迟诊断结果，确定为该内部实例对应的全链路运行诊断信息。

作为本公开的一种实施例，所述延迟原因确定模块1030，具体可以用于：

基于预设的内部任务的范围，从各个目标上游实例中获得目标外部上游实例；

基于各个目标外部上游实例的上游全链路运行诊断信息，判断是否有目标外部上游实例发生延迟；

若有目标外部上游实例发生延迟，则确定目标内部延迟实例的延迟原因为外部数据延迟；

若没有目标外部上游实例发生延迟，则基于目标内部延迟实例的资源耗时信息，确定是否为内部资源耗时延迟。

在本公开一种实施例中，所述延迟原因确定模块1030，还可以具体用于：

若目标内部延迟实例，未确定为外部数据延迟且未确定为内部资源耗时延迟，则确定目标内部延迟实例的延期原因为其他原因。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图13示出了可以用来实施本公开的实施例的示例电子设备1300的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图13所示，设备1300包括计算单元1301，其可以根据存储在只读存储器(ROM)1302中的计算机程序或者从存储单元1308加载到随机访问存储器(RAM)1303中的计算机程序，来执行各种适当的动作和处理。在RAM 1303中，还可存储设备1300操作所需的各种程序和数据。计算单元1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

设备1300中的多个部件连接至I/O接口1305，包括：输入单元1306，例如键盘、鼠标等；输出单元1307，例如各种类型的显示器、扬声器等；存储单元1308，例如磁盘、光盘等；以及通信单元1309，例如网卡、调制解调器、无线通信收发机等。通信单元1309允许设备1300通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1301可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1301的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1301执行上文所描述的各个方法和处理，例如上述数据任务的延迟原因确定方法。例如，在一些实施例中，上述数据任务的延迟原因确定方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1302和/或通信单元1309而被载入和/或安装到设备1300上。当计算机程序加载到RAM 1303并由计算单元1301执行时，可以执行上文描述的方法数据任务的延迟原因确定方法的一个或多个步骤。备选地，在其他实施例中，计算单元1301可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行上述数据任务的延迟原因确定方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (16)

1.一种数据任务的延迟原因确定方法，包括：

针对各个内部任务的各个内部实例，从该内部实例的实例信息中获得该内部实例对应的全链路运行诊断信息；

基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得出发生延迟的内部实例和上游延迟实例的运行诊断信息；

基于目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因；

所述各个内部任务的各个内部实例的实例信息，采用如下步骤采集：

针对每个内部实例，采集全链路数据血缘信息，并在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息；

所述采集全链路数据血缘信息的步骤，包括：

针对每个内部实例，基于预先注册的元数据信息，采集包含该内部实例及所有与其相关的各个相关实例的全链路数据血缘信息；所述元数据包括：当前内部任务对下游任务承诺产出时效的核心数据、对当前内部任务承诺产出时效的上游外部数据，以及其他中间节点数据，实例之间的血缘信息是指：实例与其上游、下游实例的依赖关系；

所述基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息的步骤，包括：

针对每个内部实例，基于预先注册的元数据信息和所述全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息。

2.根据权利要求1所述的方法，其中，

在所述针对每个内部实例，采集全链路数据血缘信息，并在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息之前，所述方法还包括：

按预设第一定时时刻，初始化每个内部实例的实例信息；

在所述针对每个内部实例，采集全链路数据血缘信息，并在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息之后，所述方法还包括：

将所述全链路运行诊断信息，添加至该内部实例的实例信息中。

3.根据权利要求2所述的方法，其中，

所述在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息的步骤，包括：

在第二定时时刻到达的情况下，获取并锁定一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；

判断所述当前内部实例是否就绪，若当前内部实例已就绪，则基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息，锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；若所述当前内部实例未就绪，则解锁该内部实例，锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例。

4.根据权利要求2所述的方法，其中，

所述获得包含实例延迟诊断结果的全链路运行诊断信息的步骤，包括：

针对该内部实例及其每个相关实例，基于该内部实例的指定基准时间对应的实际产出时效，确定该实例是否发生延迟，得到该内部实例及其每个相关实例的实例延迟诊断结果；

将该内部实例及其每个相关实例的实例延迟诊断结果，确定为该内部实例对应的全链路运行诊断信息。

5.根据权利要求4所述方法，其中，

所述针对该内部实例及其每个相关实例，基于该内部实例的指定基准时间的实际产出时效，确定该实例是否发生延迟，得到实例延迟诊断结果的步骤，包括：

针对该内部实例及每个相关实例，基于所述指定基准时间及预设的数据更新周期，确定与更新周期对应的目标数据分区；

基于目标数据分区中的数据产出时刻，计算目标数据分区的实际产出时效，基于实际产出时效和期望产出时效，确定该实例是否发生延迟，得到实例延迟诊断结果。

6.根据权利要求1所述的方法，其中，

所述基于目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因的步骤，包括：

基于预设的内部任务的范围，从各个目标上游实例中获得目标外部上游实例；

基于各个目标外部上游实例的上游全链路运行诊断信息，判断是否有目标外部上游实例发生延迟；

若有目标外部上游实例发生延迟，则确定目标内部延迟实例的延迟原因为外部数据延迟；

若没有目标外部上游实例发生延迟，则基于目标内部延迟实例的资源耗时信息，确定是否为内部资源耗时延迟。

7.根据权利要求6所述的方法，所述方法还包括：

若目标内部延迟实例，未确定为外部数据延迟且未确定为内部资源耗时延迟，则确定目标内部延迟实例的延期原因为其他原因。

8.一种数据任务的延迟原因确定装置，包括：

运行诊断信息获取模块，用于针对各个内部任务的各个内部实例，从该内部实例的实例信息中获得该内部实例对应的全链路运行诊断信息；

目标内部延迟实例获取模块，用于基于各个全链路运行诊断信息包含的内部实例及其上游实例的运行诊断信息、和上下游关系，获得发生延迟的内部延迟实例和上游延迟实例的运行诊断信息；

延迟原因确定模块，用于基于目标实例信息、各个上游全链路运行诊断信息按照设定的延迟归因策略，确定目标内部延迟实例的延迟原因；

其中，运行诊断信息获取模块，包括：

全链路运行诊断信息获取子模块，用于针对每个内部实例，采集全链路数据血缘信息，并在第二定时时刻到达的情况下，基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息；

所述全链路运行诊断信息获取子模块，具体用于：

针对每个内部实例，基于预先注册的元数据信息，采集包含该内部实例及所有与其相关的各个相关实例的全链路数据血缘信息，并在第二定时时刻到达的情况下，基于预先注册的元数据信息和所述全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息；所述元数据包括：当前内部任务对下游任务承诺产出时效的核心数据、对当前内部任务承诺产出时效的上游外部数据，以及其他中间节点数据，实例之间的血缘信息是指：实例与其上游、下游实例的依赖关系。

9.根据权利要求8所述的装置，其中，运行诊断信息获取模块，还包括：

实例初始化子模块，用于按预设第一定时时刻，初始化每个内部实例的实例信息；

全链路运行诊断信息添加子模块，用于将所述全链路运行诊断信息，添加至该内部实例的实例信息中。

10.根据权利要求9所述的装置，其中，

所述全链路运行诊断信息获取子模块，具体用于：

在第二定时时刻到达的情况下，获取并锁定一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；

判断所述当前内部实例是否就绪，若当前内部实例已就绪，则基于全链路数据血缘信息，获得包含实例延迟诊断结果的全链路运行诊断信息，锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例；若所述当前内部实例未就绪，则解锁该内部实例，锁定下一个未获得全链路运行诊断信息且处于未锁定状态的内部实例作为当前内部实例。

11.根据权利要求9所述的装置，其中，

所述全链路运行诊断信息获取子模块，包括：

延迟诊断结果确定子模块，用于针对该内部实例及其每个相关实例，基于该内部实例的指定基准时间对应的实际产出时效，确定该实例是否发生延迟，得到该内部实例及其每个相关实例的实例延迟诊断结果；

运行诊断信息确定子模块，用于将该内部实例及其每个相关实例的实例延迟诊断结果，确定为该内部实例对应的全链路运行诊断信息。

12.根据权利要求11所述装置，其中，

所述延迟诊断结果确定子模块，具体用于：

针对该内部实例及每个相关实例，基于所述指定基准时间及预设的数据更新周期，确定与更新周期对应的目标数据分区；

基于目标数据分区中的数据产出时刻，计算目标数据分区的实际产出时效，基于实际产出时效和期望产出时效，确定该实例是否发生延迟，得到实例延迟诊断结果。

13.根据权利要求8所述的装置，其中，

所述延迟原因确定模块，具体用于：

基于预设的内部任务的范围，从各个目标上游实例中获得目标外部上游实例；

基于各个目标外部上游实例的上游全链路运行诊断信息，判断是否有目标外部上游实例发生延迟；

若有目标外部上游实例发生延迟，则确定目标内部延迟实例的延迟原因为外部数据延迟；

若没有目标外部上游实例发生延迟，则基于目标内部延迟实例的资源耗时信息，确定是否为内部资源耗时延迟。

14.根据权利要求13所述的装置，所述延迟原因确定模块，还具体用于：

若目标内部延迟实例，未确定为外部数据延迟且未确定为内部资源耗时延迟，则确定目标内部延迟实例的延期原因为其他原因。

15.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-7中任一项所述的方法。

16.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-7中任一项所述的方法。