CN113378007B - 数据回溯方法及装置、计算机可读存储介质、电子设备 - Google Patents

Abstract

本公开属于数据处理技术领域，涉及一种数据回溯方法及装置、计算机可读存储介质、电子设备。该方法包括：通过数据血缘关系确定作业的隐式依赖关系，并根据隐式依赖关系配置作业的显式依赖关系；根据显式依赖关系生成作业的任务血缘图，并在任务血缘图中确定作业下游的多个下游作业；根据任务血缘图在多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行待回溯作业生成回溯数据。本公开一方面，将隐式依赖关系转换为显式依赖关系，并生成任务血缘图，提高了数据质量，降低了开发人员之间的信息共享成本；另一方面，根据任务血缘图并发式数据回溯，在提升数据质量的同时，减少了数据回溯的执行时间，节省了大量的人力资源。

Description

数据回溯方法及装置、计算机可读存储介质、电子设备

技术领域

本公开涉及数据处理技术领域，尤其涉及一种数据回溯方法与数据回溯装置、计算机可读存储介质及电子设备。

背景技术

Azkaban是当下非常流行的大数据开源任务流调度系统，已经在全世界范围内获得了广泛的应用。但是在多人、多团队协作使用时，不同团队或个人维护的工程可能存在工作流级别或者作业级别的隐式依赖，造成数据质量的稳定性下降，以及维护困难等问题。

除此之外，随着公司业务的快速发展，对数据的需求也越来越多，数据开发人员往往1～2周就需要上线一个数据业务。但是，在开发人员对链路上的历史数据进行回溯时，工作流级别或者作业级别的依赖非常复杂，大规模回溯数据会消耗大量人力资源，同时还无法保障数据的质量。

鉴于此，本领域亟需开发一种新的数据回溯方法及装置。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种数据回溯方法、数据回溯装置、计算机可读存储介质及电子设备，进而至少在一定程度上克服由于相关技术的限制而导致的数据回溯难度大和数据质量差等问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种数据回溯方法，所述方法包括：通过数据血缘关系确定作业的隐式依赖关系，并根据所述隐式依赖关系配置所述作业的显式依赖关系；根据所述显式依赖关系生成所述作业的任务血缘图，并在所述任务血缘图中确定所述作业下游的多个下游作业；根据所述任务血缘图在所述多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行所述待回溯作业生成回溯数据。

在本公开的一种示例性实施例中，所述根据所述隐式依赖关系配置所述作业的显式依赖关系，包括：确定所述作业的作业名称，并根据所述隐式依赖关系确定依赖所述作业的工作流和工程；确定所述工作流的当前工作流名称和所述工程的当前工程名称，以生成所述作业的显式依赖关系。

在本公开的一种示例性实施例中，所述根据所述显式依赖关系生成所述作业的任务血缘图，包括：根据所述当前工程名称和所述当前工作流名称确定当前调度信息，并确定所述作业的上游调度信息；根据所述当前调度信息和所述上游调度信息对所述显式依赖关系进行校验，以根据所述显式依赖关系生成所述作业的任务血缘图。

在本公开的一种示例性实施例中，所述根据所述当前调度信息和所述上游调度信息对所述显式依赖关系进行校验，包括：获取所述当前调度信息的目标执行时间和所述上游调度信息的首次执行时间和调度周期；对所述目标执行时间、所述首次执行时间和调度周期进行计算，得到所述作业或工作流的计划执行时间；根据所述目标执行时间、所述首次执行时间、所述调度周期和所述计划时间对所述显式依赖关系进行校验。

在本公开的一种示例性实施例中，所述通过数据血缘关系确定作业的隐式依赖关系，包括：若根据任务的目标文件确定所述任务为结构化查询语言任务，解析所述结构化查询语言任务，以获取源数据表；在所述源数据表中查询数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。

在本公开的一种示例性实施例中，所述通过数据血缘关系确定作业的隐式依赖关系，包括：若根据任务的目标文件确定所述任务不是结构化查询语言任务，获取历史血缘配置信息；在所述历史血缘配置信息中确定数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。

在本公开的一种示例性实施例中，在所述根据所述显式依赖关系生成所述作业的任务血缘图之后，所述方法还包括：当所述显式依赖关系发生变化时，对所述任务血缘图进行新增操作；当所述显式依赖关系发生变化时，对所述任务血缘图进行修改操作；当所述显式依赖关系发生变化时，对所述任务血缘图进行删除操作。

根据本公开的一个方面，提供一种数据回溯装置，所述装置包括：关系配置模块，被配置为通过数据血缘关系确定作业的隐式依赖关系，并根据所述隐式依赖关系配置所述作业的显式依赖关系；血缘图生成模块，被配置为根据所述显式依赖关系生成所述作业的任务血缘图，并在所述任务血缘图中确定所述作业下游的多个下游作业；数据回溯模块，被配置为根据所述任务血缘图在所述多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行所述待回溯作业生成回溯数据。

在本公开的一种示例性实施例中，基于以上技术方案，所述关系配置模块，包括：名称确定单元，被配置为确定所述作业的作业名称，并根据所述隐式依赖关系确定依赖所述作业的工作流和工程；关系生成单元，被配置为确定所述工作流的当前工作流名称和所述工程的当前工程名称，以生成所述作业的显式依赖关系。

在本公开的一种示例性实施例中，基于以上技术方案，所述血缘生成模块，包括：调度确定单元，被配置为根据所述当前工程名称和所述当前工作流名称确定当前调度信息，并确定所述作业的上游调度信息；关系校验单元，被配置为根据所述当前调度信息和所述上游调度信息对所述显式依赖关系进行校验，以根据所述显式依赖关系生成所述作业的任务血缘图。

在本公开的一种示例性实施例中，基于以上技术方案，所述关系校验单元，包括：时间获取子单元，被配置为获取所述当前调度信息的目标执行时间和所述上游调度信息的首次执行时间和调度周期；数据计算子单元，被配置为对所述目标执行时间、所述首次执行时间和调度周期进行计算，得到所述作业或工作流的计划执行时间；数据校验子单元，被配置为根据所述目标执行时间、所述首次执行时间、所述调度周期和所述计划执行时间对所述显式依赖关系进行校验。

在本公开的一种示例性实施例中，基于以上技术方案，所述关系配置模块，包括：任务解析单元，被配置为若根据任务的目标文件确定所述任务为结构化查询语言任务，解析所述结构化查询语言任务，以获取源数据表；关系查询单元，被配置为在所述源数据表中查询数据血缘关系，并通过数据血缘关系确定作业和所述作业的隐式依赖关系。

在本公开的一种示例性实施例中，基于以上技术方案，所述关系配置模块，包括：信息获取单元，被配置为若根据任务的目标文件确定所述任务非结构化查询语言任务，获取历史血缘配置信息；信息确定单元，被配置为在所述历史血缘配置信息中确定数据血缘关系，并通过数据血缘关系确定作业和所述作业的隐式依赖关系。

在本公开的一种示例性实施例中，基于以上技术方案，所述装置还包括：新增操作单元，被配置为当所述显式依赖关系发生变化时，对所述任务血缘图进行新增操作；修改操作单元，被配置为当所述显式依赖关系发生变化时，对所述任务血缘图进行修改操作；删除操作单元，被配置为当所述显式依赖关系发生变化时，对所述任务血缘图进行删除操作。

根据本公开的一个方面，提供一种电子设备，包括：处理器和存储器；其中，存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现上述任意示例性实施例的数据回溯方法。

根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意示例性实施例中的数据回溯方法。

由上述技术方案可知，本公开示例性实施例中的数据回溯方法、数据回溯装置、计算机存储介质及电子设备至少具备以下优点和积极效果：

在本公开的示例性实施例提供的方法及装置中，本公开通过显式依赖关系可以生成作业的任务血缘图，以对确定出的待回溯作业进行数据回溯。一方面，将隐式依赖关系转换为显式依赖关系，并生成任务血缘图，提高了数据质量，降低了开发人员之间的信息共享成本；另一方面，根据任务血缘图并发式数据回溯，在提升数据质量的同时，减少了数据回溯的执行时间，节省了大量的人力资源。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中一种数据回溯方法的流程示意图；

图2示意性示出本公开示例性实施例中一种确定作业的隐式依赖关系的方法的流程示意图；

图3示意性示出本公开示例性实施例中另一种确定作业的隐式依赖关系的方法的流程示意图；

图4示意性示出本公开示例性实施例中配置显式依赖关系的方法的流程示意图；

图5示意性示出本公开示例性实施例中生成任务血缘图的方法的流程示意图；

图6示意性示出本公开示例性实施例中对显式依赖关系进行校验的方法的流程示意图；

图7示意性示出本公开示例性实施例中更新任务血缘图的方法的流程示意图；

图8示意性示出本公开示例性实施例中Azkaban系统中的有向无环图；

图9示意性示出本公开示例性实施例中应用场景下配置显式依赖关系的方法的流程示意图；

图10示意性示出本公开示例性实施例中任务血缘图的示意图；

图11示意性示出本公开示例性实施例中进行并发数据回溯的任务血缘图；

图12示意性示出本公开示例性实施例中一种数据回溯装置的结构示意图；

图13示意性示出本公开示例性实施例中一种用于实现数据回溯方法的电子设备；

图14示意性示出本公开示例性实施例中一种用于实现数据回溯方法的计算机可读存储介质。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。

针对相关技术中存在的问题，本公开提出了一种数据回溯方法。图1示出了数据回溯方法的流程示意图，如图1所示，数据回溯方法至少包括以下步骤：

步骤S110.通过数据血缘关系确定作业的隐式依赖关系，并根据隐式依赖关系配置作业的显式依赖关系。

步骤S120.根据显式依赖关系生成作业的任务血缘图，并在任务血缘图中确定作业下游的多个下游作业。

步骤S130.根据任务血缘图在多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行待回溯作业生成回溯数据。

在本公开的示例性实施例中，本公开通过显式依赖关系可以生成作业的任务血缘图，以对确定出的待回溯作业进行数据回溯。一方面，将隐式依赖关系转换为显式依赖关系，并生成任务血缘图，提高了数据质量，降低了开发人员之间的信息共享成本；另一方面，根据任务血缘图并发式数据回溯，在提升数据质量的同时，减少了数据回溯的执行时间，节省了大量的人力资源。

下面对数据回溯方法的各个步骤进行详细说明。

在步骤S110中，通过数据血缘关系确定作业的隐式依赖关系，并根据隐式依赖关系配置作业的显式依赖关系。

在本公开的示例性实施例中，作业可以是Azkaban中的job，常用的作业有MapReduce、HiveSQL和SparkSQL。其中，SQL即Structured Query Language，表示结构化查询语言。数据血缘关系可以分成表级别的血缘关系和字段级别的血缘关系。其中，表级别的血缘关系可以表示表和表之间的关系，字段级别的血缘关系可以表示字段与字段之间的关系。

在可选的实施例中，图2示出了一种确定作业的隐式依赖关系的方法的流程示意图，如图2所示，该方法至少包括以下步骤：在步骤S210中，若根据任务的目标文件确定任务为结构化查询语言任务，解析结构化查询语言任务，以获取源数据表。其中，该任务可以是开发人员在前端页面设置调度时，创建的任务。当前端将该任务的一些信息传递给后端时，后端会接收到.job格式的目标文件。该目标文件中保存的是键值对(key-value对)。

由于SQL任务有一个固定的键(key)是type，用来表示文件的类型，如果该键是type＝SQL的形式，表明该任务是结构化查询语言任务，否则不是结构化查询语言任务。

当确定任务为结构化查询语言任务时，可以去查询是否配置数据血缘关系。当配置有数据血缘关系时，可以通过写在.job文件中两个特定的key作为数据血缘关系；当没有配置数据血缘关系时，解析结构化查询语言任务，形成对应的语法树，判断该任务是由上游的哪个表产生的数据，得到源数据表。

在步骤S220中，在源数据表中查询数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。在得到源数据表之后，可以在对应管理数据血缘关系的服务中查询上游表中对应的数据以及数据是根据哪张表产生的，亦即数据血缘关系。

由于job是Azkaban批量工作流任务调节器的执行单元，因此，在查询到的数据血缘关系之后就可以获取上游的job以及job中的隐式依赖关系。隐式依赖关系可以是不同job或者不同工作流(flow)之间严格的数据依赖。

在本示例性实施例中，给出了一种优化获取结构化查询语言任务的隐式依赖关系的方法，提高了隐式依赖关系获取的准确度，保障了隐式依赖显性化的准确性。

在可选的实施例中，图3示出了另一种确定作业的隐式依赖关系的方法的流程示意图，如图3所示，该方法至少包括以下步骤：在步骤S310中，若根据任务的目标文件确定该任务不是结构化查询语言任务，获取历史血缘配置信息。其中，该任务可以是开发人员在前端页面设置调度时创建的任务。当前端将该任务的一些信息传递给后端时，后端会接收到.job格式的目标文件。该目标文件中保存的是键值对(key-value对)。当用来表示文件的类型的key不是type＝SQL的形式，表明该任务不是结构化查询语言任务。

当任务不是结构化查询语言任务时，通过提供数据血缘关系维护能力的底层服务获取历史血缘配置信息。该底层服务只要运行过一次，则可以判断数据是根据哪张表产生的，亦即历史血缘配置信息会保存在底层的数据库中。

在步骤S320中，在历史血缘配置信息中确定数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。只要在数据库中查询到任务的任务标识，则可以在历史血缘配置信息中得到数据是从A表流向B表的数据血缘关系。

在查询到数据血缘关系之后就可以寻找到当前job的上游job以及当前job与该上游job之间的隐式依赖关系。隐式依赖关系可以是不同job或者不同flow之间严格的数据依赖。

值得说明的是，即使该任务为结构化查询语言任务，也可以使用历史血缘配置信息确定作业和作业的隐式依赖关系。

在本示例性实施例中，给出了一种另一种确定隐式依赖关系的方法，该方法基于历史配置信息，准确度较高，普适性较强。

在得到作业的隐式依赖关系之后，可以配置对应的显式依赖关系。

在可选的实施例中，图4示出了配置显式依赖关系的方法的流程示意图，如图4所示，该方法至少包括以下步骤：在步骤S410中，确定作业的作业名称，并根据隐式依赖关系确定依赖作业的工作流和工程。该job的作业名称可以是字段为jobID的名称信息，该名称为字符串(string)类型。与job对应的，工作流(flow)在Azkaban中表示工作流，一个工作流会包含多个job；进一步的，project表示工程，一个工程中会包含多个flow。因此，在确定作业名称之后，可以根据隐式依赖关系确定包含该job的flow和project。

在步骤S420中，确定工作流的当前工作流名称和工程的当前工程名称，以生成作业的显式依赖关系。进一步的，其中，flowID表示flow的当前工作流名称，该名称为string类型；projectID表示project的当前工程名称，该名称为基本整型(int)类型。在确定flowID和projectID之后，可以向该job添加对应的projectID、flowID和jobID信息即可，本示例性实施例对具体添加方式不作特殊限定。通过projectID、flowID和jobID三元组即可唯一定位到依赖于job对应的显式依赖关系。

在本示例性实施例中，将隐式依赖关系显性化，可以极大地提高多人协作开发的能力，减少后续数据维护的人力成本。

在步骤S120中，根据显式依赖关系生成作业的任务血缘图，并在任务血缘图中确定作业下游的多个下游作业。

在本公开的示例性实施例中，图5示出了生成任务血缘图的方法的流程示意图，如图5所示，该方法至少包括以下步骤：在步骤S510中，根据当前工程名称和当前工作流名称确定当前调度信息，并确定作业的上游调度信息。schedule表示Azkaban里的调度，调度是以flow为单位进行的，并且一个flow有且只有一个schedule。由于schedule与flow一一对应，服务的内存会去维护一个索引，亦即projectID和flowID，根据该索引可以确定对应的schedule信息，亦即当前调度信息，并且也会存储在数据库里面。进一步的，需要根据jobID判断该job是否存在在上游schedule的执行节点列表中并且进行校验，因此获取上游调度信息。

在步骤S520中，根据当前调度信息和上游调度信息对显式依赖关系进行校验，已根据显式依赖关系生成作业的任务血缘图。在获取当前调度信息和上游调度信息之后，可以对显式依赖关系进行校验。

在可选的实施例中，图6示出了对显式依赖关系进行校验的方法的流程示意图，如图6所示，该方法至少包括以下步骤：在步骤S610中，获取当前调度信息的目标执行时间和上游调度信息的首次执行时间和调度周期，无论是当前调度信息还是上游调度信息，都对应存储着调度的基本信息，例如schedule的首次执行时间、调度周期以及对应的flow的依赖关系等。对应的，可以获取当前调度信息中的目标执行时间和上游调度信息的首次执行时间和调度周期。

在步骤S620中，对目标执行时间、首次执行时间和调度周期进行计算，得到作业或工作流的计划执行时间。具体的，根据首次执行时间+n*调度周期>目标执行时间的公式计算出一个最小的n。并且，将n带入之间的公式并减去一个调度周期得到对应的计划执行时间(depjobscheduletime)。

值得说明的是，由于对显式依赖关系的校验可以包括flow级别和job级别两种。因此，当对应的调度信息对应为flow级别时，得到的是工作流的计划执行时间；当对应的调度信息对应为job级别时，得到的是工作的计划执行时间。其中，flow级别的校验是在生成flow实例(ExecutableFlow)前进行的，而job级别的校验是在运行job实例(ExecutableJob)前进行的。

虽然flow级别的显式依赖关系校验与job级别的显式依赖关系校验方法一致，但是不同的是，job级别的依赖如果不通过的话，job会始终处于就绪状态，继而进行循环判断，直至最终校验通过；而flow级别的校验不通过的话，不会生成对应的flow实例，而是由schedule去循环判断该flow的依赖校验是否通过，如果通过才会生成flow实例。

在步骤S630中，根据目标执行时间、首次执行时间、调度周期和计划执行时间对显式依赖关系进行校验。由于根据A任务在运行B任务的时候都会对应得到execution_jobs的一张表，在生成的时候，可以得到A任务对应的projectID、flowID和jobID的三元组，再加上已计算出的B任务的计划执行时间(depjobscheduletime)可以组成B任务对应的四元组。根据该四元组去底层数据库中查询，若查询到正常执行生成的数据，则表明该显式依赖关系校验成功。

在本示例性实施例中，给出了一种对显式依赖关系进行校验的方法，可以防止Azkaban有过多flow实例处于就绪等待状态，无法运行的情况，避免给整个系统带来无效负载。

在对flow和job进行显式依赖关系校验之后，可以根据校验成功的显式依赖关系绘制job的任务血缘图。该任务血缘图记录每个节点的上下游的依赖关系，包含同一个flow中各个job的依赖，以及不同flow或不同flow的不同job之间的显式依赖关系。由于job是flow的子集，因此flow级别的依赖可以转换成job级别的依赖。

具体的，flow依赖一个上游job，认为该flow所有的start job都依赖于该上游job；一个下游job依赖该flow，认为该flow的end job都被该下游job依赖。

由于任务血缘图维护在Azkaban服务的内存中，每当新增、修改和删除schedule时，可以根据显式依赖关系对任务血缘图进行更新。

在可选的实施例中，图7示出了更新任务血缘图的方法的流程示意图，如图7所示，该方法至少包括以下步骤：在步骤S710中，当显式依赖关系发生变化时，对任务血缘图进行新增操作。当Azkaban重启时，会从数据库中加载所有flow信息，并将每个flow按照拓扑结构在内存中维护一个图结构，随后会继续从数据库中加载schedule信息。然后，按照先是依赖关系将单独的flow图结构绘制成一张大图。由于可能有割裂的flow，所以任务血缘图中可能有多个割裂的子图。

如果是新增的schedule，可以将schedule对应的flow图加入到任务血缘图中，并按照显式依赖关系，将该图与其他flow图之间进行关联。

在步骤S720中，当显式依赖关系发生变化时，对任务血缘图进行修改操作。如果是修改schedule的话，可以将schedule的显式依赖的关联关系以及对应的flow图从任务血缘图中移除掉。

在步骤S730中，当显式依赖关系发生变化时，对任务血缘图进行删除操作。对于要更新的flow图，可以在进行一次删除schedule的操作之后，进行新增schedule的操作。将两种操作进行合并，实现更新schedule的需求。除此之外，也可以根据实际情况删除flow图，本示例性实施例对此不作特殊限定。

在本示例性实施例中，给出了对已生成的任务血缘图进行更新的几种方式，可以保证任务血缘图根据实际情况进行改变，实用性极强。

在步骤S130中，根据任务血缘图在多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行待回溯作业生成回溯数据。在正常开发当中，由于迭代速度快或者数据量大的原因，有些业务可能要求批量统计或修改一些旧数据，因此需要进行数据回溯。

为提高数据回溯的速度，可以在任务血缘图中确定出当前作业的下游中的多个下游作业，并根据任务血缘图将其中并无依赖关系的多个下游作业确定为待回溯作业，并发的同时运行该待回溯作业生成对应的回溯数据。

下面结合一应用场景对本公开实施例中的数据回溯方法做出详细说明。

图8示出了Azkaban系统中的有向无环图，如图8所示，在该有向无环图(DirectedAcyclic Graph，简称DAG)中，jobA、JobB、JobC为该Flow中的Job，JobC依赖JobA、JobB。Azkaban在执行该Flow的实例时，会按照该DAG图确认执行顺序。在该图中，jobA和jobB会先于jobC运行，且当且仅当jobA、jobB均运行成功时，jobC才会运行。

图9示出了应用场景下配置显式依赖关系的方法的流程示意图，如图9所示，在步骤S910中，当前端将该任务的一些信息传递给后端时，后端会接收到.job格式的目标文件。

在步骤S920中，判断该任务是否为SQL任务。由于SQL任务有一个固定的键(key)是type，用来表示文件的类型，如果该键是type＝SQL的形式，表明该任务是结构化查询语言任务，否则不是结构化查询语言任务。

在步骤S930中，当确定任务为结构化查询语言任务时，可以去查询是否配置数据血缘关系。当配置时，可以通过写在.job文件中两个特定的key作为数据血缘关系；当没有配置时，解析结构化查询语言任务，形成对应的语法树，判断是由上游的哪个表产生的数据，得到源数据表。

在步骤S940中，当任务不是结构化查询语言任务时，通过提供数据血缘的维护能力的底层服务获取历史血缘配置信息。该底层服务只要运行过一次，则可以判断数据是根据哪张表产生的，亦即源数据信息。

在步骤S950中，在源数据表或者源数据信息中查询数据血缘关系。

在步骤S960中，在查询到的数据血缘关系之后就可以获取上游的job以及job中的隐式依赖关系。隐式依赖关系可以是不同job或者不同工作流(flow)之间严格的数据依赖。

在步骤S970中，在确定作业的作业名称jobID之后，确定对应的工作流的当前工作流名称flowID和工程的当前工程名称projectID，并向该job配置对应的jobID、flowID和projectID，以得到job的显式依赖关系。

图10示出了任务血缘图的示意图，如图10所示，job C的直接上游节点有：jobO、jobA、jobM，其中，jobO的直接上游为jobN；job C的直接下游节点有：jobI、jobH、jobG，其中，jobH的直接下游为jobJ，jobJ的直接下游为jobL、jobK。

值得说明的是，在两个节点之间的数字表示依赖关系的个数。如果二者直接存在job级别的显式依赖关系，表明有一层依赖关系；如果二者之间存在flow级别的显式依赖关系，表明有一层依赖关系；如果二者之间同时存在job级别和flow级别的显式依赖关系，表明有两层依赖关系。

图11示出了进行并发数据回溯的任务血缘图，如图11所示，jobB、jobC、jobD三个Job是jobA的直接下游，且彼此之间并无依赖关系。当jobA成功运行后，jobB、jobC、jobD实际上可以并行运行，而非之前的严格串行运行。

同时，可以从图中看出，jobE、jobF只需要等待jobB成功运行后，即可运行；jobH、jobI只需等待jobC成功运行后，即可运行；jobG比较特殊，需要等待jobF、jobC都成功运行后，才能运行；以此类推，jobL、jobK需要依赖jobJ节点成功运行后，才能正常运行。

在本公开的示例性实施例中，本公开通过显式依赖关系可以生成作业的任务血缘图，以对确定出的待回溯作业进行数据回溯。一方面，将隐式依赖关系转换为显式依赖关系，并生成任务血缘图，提高了数据质量，降低了开发人员之间的信息共享成本；另一方面，根据任务血缘图并发式数据回溯，在提升数据质量的同时，减少了数据回溯的执行时间，节省了大量的人力资源。

需要说明的是，虽然以上示例性实施例的实施方式以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或者必须执行全部的步骤才能实现期望的结果。附加地或者备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

此外，在本公开的示例性实施例中，还提供一种数据回溯装置。图12示出了数据回溯装置的结构示意图，如图12所示，数据回溯装置1200可以包括：关系配置模块1210、血缘图生成模块1220和数据回溯模块1230。其中：

关系配置模块1210，被配置为通过数据血缘关系确定作业的隐式依赖关系，并根据隐式依赖关系配置作业的显式依赖关系；血缘图生成模块1220，被配置为根据显式依赖关系生成作业的任务血缘图，并在任务血缘图中确定作业下游的多个下游作业；数据回溯模块1230，被配置为根据任务血缘图在多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行待回溯作业生成回溯数据。

在本公开的一种示例性实施例中，关系配置模块，包括：名称确定单元，被配置为确定作业的作业名称，并根据隐式依赖关系确定依赖作业的工作流和工程；关系生成单元，被配置为确定工作流的当前工作流名称和工程的当前工程名称，以生成作业的显式依赖关系。

在本公开的一种示例性实施例中，血缘生成模块，包括：调度确定单元，被配置为根据当前工程名称和当前工作流名称确定当前调度信息，并确定作业的上游调度信息；关系校验单元，被配置为根据当前调度信息和上游调度信息对显式依赖关系进行校验，以根据显式依赖关系生成作业的任务血缘图。

在本公开的一种示例性实施例中，关系校验单元，包括：时间获取子单元，被配置为获取当前调度信息的目标执行时间和上游调度信息的首次执行时间和调度周期；数据计算子单元，被配置为对目标执行时间、首次执行时间和调度周期进行计算，得到作业或工作流的计划执行时间；数据校验子单元，被配置为根据目标执行时间、首次执行时间、调度周期和计划执行时间对显式依赖关系进行校验。

在本公开的一种示例性实施例中，关系配置模块，包括：任务解析单元，被配置为若根据任务的目标文件确定任务为结构化查询语言任务，解析结构化查询语言任务，以获取源数据表；关系查询单元，被配置为在源数据表中查询数据血缘关系，并通过数据血缘关系确定作业和作业的隐式依赖关系。

在本公开的一种示例性实施例中，关系配置模块，包括：信息获取单元，被配置为若根据任务的目标文件确定任务非结构化查询语言任务，获取历史血缘配置信息；信息确定单元，被配置为在历史血缘配置信息中确定数据血缘关系，并通过数据血缘关系确定作业和作业的隐式依赖关系。

在本公开的一种示例性实施例中，装置还包括：新增操作单元，被配置为当显式依赖关系发生变化时，对任务血缘图进行新增操作；修改操作单元，被配置为当显式依赖关系发生变化时，对任务血缘图进行修改操作；删除操作单元，被配置为当显式依赖关系发生变化时，对任务血缘图进行删除操作。

本公开各实施例中提供的数据回溯装置的具体细节已经在对应的方法实施例中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了数据回溯装置1200的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

下面参照图13来描述根据本发明的这种实施例的电子设备1300。图13显示的电子设备1300仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图13所示，电子设备1300以通用计算设备的形式表现。电子设备1300的组件可以包括但不限于：上述至少一个处理单元1310、上述至少一个存储单元1320、连接不同系统组件(包括存储单元1320和处理单元1310)的总线1330、显示单元1340。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1310执行，使得所述处理单元1310执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

存储单元1320可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)1321和/或高速缓存存储单元1322，还可以进一步包括只读存储单元(ROM)1323。

存储单元1320还可以包括具有一组(至少一个)程序模块1325的程序/实用工具1324，这样的程序模块1325包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1330可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1300也可以与一个或多个外部设备1500(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1300交互的设备通信，和/或与使得该电子设备1300能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1350进行。并且，电子设备1300还可以通过网络适配器1360与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1340通过总线1330与电子设备1300的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

参考图14所示，描述了根据本发明的实施例的用于实现上述方法的程序产品1400，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性，本公开的真正范围和精神由权利要求指出。

Claims (10)

1.一种数据回溯方法，其特征在于，所述方法包括：

通过数据血缘关系确定作业的隐式依赖关系，并确定所述作业的作业名称，并根据所述隐式依赖关系确定依赖所述作业的工作流和工程；

确定所述工作流的当前工作流名称和所述工程的当前工程名称，以生成所述作业的显式依赖关系；

根据所述当前工程名称和所述当前工作流名称确定当前调度信息，并确定所述作业的上游调度信息；

获取所述当前调度信息的目标执行时间和所述上游调度信息的首次执行时间和调度周期；

对所述目标执行时间、所述首次执行时间和所述调度周期进行计算，得到所述作业或所述工作流的计划执行时间；

根据所述目标执行时间、所述首次执行时间、所述调度周期和所述计划执行时间对所述显式依赖关系进行校验，以根据所述显式依赖关系生成所述作业的任务血缘图，并在所述任务血缘图中确定所述作业下游的多个下游作业；

根据所述任务血缘图在所述多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行所述待回溯作业生成回溯数据。

2.根据权利要求1所述的数据回溯方法，其特征在于，所述通过数据血缘关系确定作业的隐式依赖关系，包括：

若根据任务的目标文件确定所述任务为结构化查询语言任务，解析所述结构化查询语言任务，以获取源数据表；

在所述源数据表中查询数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。

3.根据权利要求1所述的数据回溯方法，其特征在于，所述通过数据血缘关系确定作业的隐式依赖关系，包括：

若根据任务的目标文件确定所述任务不是结构化查询语言任务，获取历史血缘配置信息；

在所述历史血缘配置信息中确定数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。

4.根据权利要求1所述的数据回溯方法，其特征在于，在所述根据所述显式依赖关系生成所述作业的任务血缘图之后，所述方法还包括：

当所述显式依赖关系发生变化时，对所述任务血缘图进行新增操作；

当所述显式依赖关系发生变化时，对所述任务血缘图进行修改操作；

当所述显式依赖关系发生变化时，对所述任务血缘图进行删除操作。

5.一种数据回溯装置，其特征在于，所述装置包括：

关系配置模块，被配置为通过数据血缘关系确定作业的隐式依赖关系，并根据所述隐式依赖关系配置所述作业的显式依赖关系；

血缘图生成模块，被配置为根据所述显式依赖关系生成所述作业的任务血缘图，并在所述任务血缘图中确定所述作业下游的多个下游作业；

数据回溯模块，被配置为根据所述任务血缘图在所述多个下游作业中筛选出无依赖关系的待回溯作业，并并行运行所述待回溯作业生成回溯数据；

所述关系配置模块，包括：

名称确定单元，被配置为确定所述作业的作业名称，并根据所述隐式依赖关系确定依赖所述作业的工作流和工程；

关系生成单元，被配置为确定所述工作流的当前工作流名称和所述工程的当前工程名称，以生成所述作业的显式依赖关系；所述血缘图生成模块，包括：

调度确定单元，被配置为根据所述当前工程名称和所述当前工作流名称确定当前调度信息，并确定所述作业的上游调度信息；

关系校验单元，被配置为根据所述当前调度信息和所述上游调度信息对所述显式依赖关系进行校验，以根据所述显式依赖关系生成所述作业的任务血缘图；

所述关系校验单元，包括：

时间获取子单元，被配置为获取所述当前调度信息的目标执行时间和所述上游调度信息的首次执行时间和调度周期；

数据计算子单元，被配置为对所述目标执行时间、所述首次执行时间和所述调度周期进行计算，得到所述作业或所述工作流的计划执行时间；

数据校验子单元，被配置为根据所述目标执行时间、所述首次执行时间、所述调度周期和所述计划执行时间对所述显式依赖关系进行校验。

6.根据权利要求5所述的数据回溯装置，其特征在于，所述关系配置模块，包括：

任务解析单元，被配置为若根据任务的目标文件确定所述任务为结构化查询语言任务，解析所述结构化查询语言任务，以获取源数据表；

关系查询单元，被配置为在所述源数据表中查询数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。

7.根据权利要求5所述的数据回溯装置，其特征在于，所述关系配置模块，包括：

信息获取单元，被配置为若根据任务的目标文件确定所述任务不是结构化查询语言任务，获取历史血缘配置信息；

信息确定单元，被配置为在所述历史血缘配置信息中确定数据血缘关系，并通过数据血缘关系确定作业和作业之间的隐式依赖关系。

8.根据权利要求5所述的数据回溯装置，其特征在于，所述装置还包括：

新增操作单元，被配置为当所述显式依赖关系发生变化时，对所述任务血缘图进行新增操作；

修改操作单元，被配置为当所述显式依赖关系发生变化时，对所述任务血缘图进行修改操作；

删除操作单元，被配置为当所述显式依赖关系发生变化时，对所述任务血缘图进行删除操作。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-4中任意一项所述的数据回溯方法。

10.一种电子设备，其特征在于，包括：

处理器；

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器被配置为经由执行所述可执行指令来执行权利要求1-4中任意一项所述的数据回溯方法。

Images