CN110019144A - 一种大数据平台数据运维的方法和*** - Google Patents

Abstract

本发明公开了一种大数据平台数据运维的方法和***。一种用于数据运维的***包括：执行代理，用于执行处理数据的任务的实例；调度器，其用于将任务的实例分配到所述执行代理；数据库，其存储所述实例的信息和与该实例相关的任务调度信息；以及数据源，其存储所述实例运行时要处理的数据。

Description

一种大数据平台数据运维的方法和***

技术领域

本发明涉及计算机技术，特别地涉及能够进行高效运维的一种大数据平台数据运维的方法和***。

背景技术

随着企业数据量的不断增长以及企业对企业数据的重视程度不断升高，存在持续地对企业数据进行大量且有效的挖掘的需求。此时，对业务数据处理的需求不断增多，开发相应的数据作业的需求也同样不断增长。另外，作业之间存在有复杂的依赖关系。当集群发生故障时，需要对批量的作业进行修复。然而，由于存在许多作业，因此当针对一个个作业进行手工修复时工作效率会很低。在某个作业失败或者其代码已被修改时，需要对该作业进行数据修复。

此外，在大数据平台中，必然会有大量的数据作业需要执行。当作业代码出现bug而导致运行失败时，或者当集群出现故障而导致大量作业失败或终止时，此时就需要对失败的数据作业进行维护。因此需要一种高效且方便的数据作业运维的方法和***。

传统的数据作业运维方式是直接在服务器后台进行操作，或者在简单的可视化界面上进行点击操作来进行维护。如果直接在服务器后台进行维护，需要运维人员具有服务器的操作权限和经验并且需要专门的人员来做这件事。另外，这种运维的操作复杂、低效、并且很难进行快速响应。如果通过常规的点击操作来进行维护的话，其操作灵活性不够高，不适用于多种作业修补场景，而且对批量作业而言不能很好的支持其智能修复。现有技术的数据作业运维方式的一个例子是中国专利申请公布号CN106156956A所教导的银行数据加工作业调度***及其方法；该技术只是单纯地批量处理和加工大量数据，无法解决在大数据平台下数据作业维护的问题。

发明内容

本发明的一个方面公开了一种用于数据运维的***，其可以包括：执行代理，用于执行处理数据的任务的实例；调度器，其用于将任务的实例分配到所述执行代理；数据库，其存储所述实例的信息和与该实例相关的任务调度信息；以及数据源，其存储所述实例运行时要处理的数据。

所述调度器能够执行以下功能的至少之一：补数据功能，用于指定任意的日期段，并生成每日的任务的实例；置成功功能，用于将失败的任务的实例的状态改为成功；以及重跑功能，用于当某个任务的实例失败时，对该实例进行重跑。

所述补数据功能能够在指定日期范围内，根据日期先后顺序串行地运行任务的实例。

所述补数据功能能够在指定日期范围内，不根据日期顺序、并行地运行任务的实例。

所述重跑功能能够针对单个失败的任务的实例重新运行该任务的实例。所述重跑功能能够对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例。

所述重跑功能能够执行以下功能：(1)对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例；以及(2)自动识别与任务相关的链路的外部父节点是否失败，并且如果该外部父节点失败，则不执行功能(1)。

所述重跑功能能够对一任务的实例及其下游的任务的实例进行重新运行，并且在所述重新运行的过程中，跳过已执行成功的任务而仅重新运行失败的任务的实例。

本发明的一个方面公开了一种用于在大数据平台上进行数据运维的方法，其中所述大数据平台包括用于执行处理数据的任务的实例的执行代理和用于存储任务的实例运行时要处理的数据的数据源，所述方法包括：存储任务的实例的信息和与该实例相关的任务调度信息；以及将所述任务的实例分配到所述执行代理。

所述将所述任务的实例分配到所述执行代理的步骤还包括以下步骤的至少之一：补数据步骤，用于指定任意的日期段，并生成每日的任务的实例；置成功步骤，用于将失败的任务的实例的状态改为成功；以及重跑步骤，用于当某个任务的实例失败时，对该实例进行重跑。

所述补数据步骤在指定日期范围内，根据日期先后顺序串行地运行任务的实例。

所述补数据步骤在指定日期范围内，不根据日期顺序、并行地运行任务的实例。

所述重跑步骤针对单个失败的任务的实例重新运行该任务的实例。

所述重跑步骤对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例。

所述重跑步骤包括以下步骤：(1)对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例；以及(2)自动识别与任务相关的链路的外部父节点是否失败，并且如果该外部父节点失败，则不执行步骤(1)。

所述重跑步骤对一任务的实例及其下游的任务的实例进行重新运行，并且在所述重新运行的过程中，跳过已执行成功的任务而仅重新运行失败的任务的实例。

本发明的一方面公开了一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令被计算机执行时能够执行所述大数据平台数据运维的方法。

本发明的多种作业运维方法能高效、方便的对单个、多个或大量作业进行智能且有效的运维。

附图说明

图1示出了根据本发明实施例的数据调度运维架构图。

图2A示出了根据本发明实施例的自依赖补数据架构图。

图2B示出了根据本发明实施例的并行执行补数据架构图。

图3示出了根据本发明实施例的作业置成功架构图。

图4A示出了根据本发明实施例的单任务重跑架构图。

图4B示出了根据本发明实施例的重跑下游架构图。

图4C示出了根据本发明实施例的重跑下游架构中自动识别外部父节点是否失败的示意图。

图4D示出了根据本发明实施例的修复性重跑架构图。

具体实施方式

现在将参照若干示例性实施例来论述本发明的内容。应当理解，论述了这些实施例仅是为了使得本领域普通技术人员能够更好地理解且因此实现本发明的内容，而不是暗示对本发明的范围的任何限制。

如本文中所使用的，术语“包括”及其变体要被解读为意味着“包括但不限于”的开放式术语。术语“基于”要被解读为“至少部分地基于”。术语“一个实施例”和“一种实施例”要被解读为“至少一个实施例”。术语“另一个实施例”要被解读为“至少一个其他实施例”。

本发明的不同实施例能够自由选择时间段以对作业进行数据修补；能够根据时间维度进行自动依赖执行或独立并行执行；能够将对整体关系不影响的失败作业置成功，从而不影响下游作业的运行；能够对失败的作业进行重跑；能够批量重跑该作业下游的作业。本发明的实施例还能够实现作业运维在不同场景下所需要的不同功能。

在本公开中，“任务”和“作业”是可以相互替代的概念。

本发明一个实施例的***架构如图1所示，包括实例、数据库(MySQL数据库)、调度器、执行代理、数据源(例如Hadoop的HDFS存储***)。其中，数据库是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库，而MySQL数据库用于存储关于实例的信息的数据；数据源存储用于计算的数据(比如，用户的行为日志数据、交易数据等)，而数据以文件的形式存放在Hadoop分布式文件***(HDFS)中。例如，***架构的描述如下：

●实例通常由用户提交作业产生，每一次作业的提交会产生一个对应的实例；

●调度器用于根据任务之间的依赖关系构建DAG图(有向无环图)，并根据一定的算法将任务调度到执行代理，其中，调度是指将需要运行的作业信息传递至执行代理(其相当于一个执行器)，执行代理依据接收到的作业信息为该作业分配运行资源；

●数据库用于存储实例的信息和任务调度信息；

●执行代理用于执行实例的计算；

●数据源用于存储数据，是作业计算的数据来源。

其中，根据本发明的一个实施例，作业是平台的最小运行单元，目前支持Shell、Hive、Spark、MapReduce、Presto、Flink等12种作业类型。

在本公开中，实例(Instance)是根据作业而创建的一个可运行的对象。任务的每次运行都会产生一个新实例。实例的正常运行通常会经历待运行、运行、结束三个阶段。对于一个任务，两次运行产生的实例的ID不同。

在本公开中，调度是指分配实例以进行运行的方法。例如，调度包含日、周、月三种粒度的调度周期。不同的任务之间可能有依赖关系。根据本发明一个实施例，一种依赖关系为：如果任务A的调度需要任务B已完成，则成任务B是任务A的上游任务。在本公开中，调度时间即任务开始运行时间。当任务到达调度时间时，如果上游有未完成的任务，则此任务不会被调度。只有当所有上游任务都完成后，此任务才会被调度，这样才开始运行。在本公开中，调度器是指分配实例到执行代理的程序。

另外，在本公开中，不同的粒度的调度周期之间支持相互依赖。其中，

“不同的粒度的调度周期之间支持相互依赖”可以参照以下例子进行理解：假如A作业是每日运行的作业，B作业是每周一运行的作业，C作业是每月1号运行的作业；如果C作业依赖B作业，B作业依赖A作业，那么每天的调度顺序是先调度A作业，待A作业执行完毕后再调度B作业，待B作业执行完毕后再调度C作业；假如某一天既不是该周的周一也不是该月的1号，那么只运行A作业，B作业在A作业运行完毕后进行空跑，C作业在B作业调度完后进行空跑(空跑是指作业会被调度，但是不会运行脚本，因此也就不会进行计算；空跑也可以被理解为走个流程)；假如某一天既是该周的周一又是该月的1号，那么，运行流程是先运行A作业，再运行B作业，最后运行C作业。

另外，根据本发明的一个实施例，调度器分配算法是基于有向无环图(DAG)的分布式调度方法，同时支持依赖调度和定时调度。

其中，“依赖调度”指的是按各个任务的依赖关系来调度各个任务。例如，任务A依赖任务B，只有当任务B调度完毕且运行成功之后才会调度A(通常这种依赖情况是由于任务A会使用到任务B产生的数据，所以只有任务B成功运行后，任务A的运行才有意义)。

其中，“定时调度”指的是在指定时间调度某个任务。例如，一种配置方式为在每日2：00进行任务A的调度，那么在每天2：00时，就会调度任务A。

其中，“同时支持依赖调度和定时调度”指的是同一任务既配置了被调度时间又配置了任务的依赖关系。例如，任务A既配置了被调度时间(比如，每日2：00)又配置了依赖关系(比如，依赖任务B)。因此，只有当每日2：00后且任务B成功运行完毕，才会运行任务A(如果任务B在2：00之前运行完，那么任务A会在2：00准时运行；如果任务B在2：00后运行完，任务A会在任务B运行完毕时才运行；如果任务B运行失败，那么任务A也自动为失败状态，不被运行)。

本发明的实施例能够使用调度规则。调度规则例如可以是“任务A，每天8点运行”；此规则例如可以以“0 0/00 0/08 1 0 0”的形式作为任务调度信息而被存储起来。

在本公开中，执行代理是指将实例提交到存储计算集群以便使其运行的程序。根据本发明的一个实施例，执行代理接收到要运行的实例的任务信息后解析出该实例的任务类型，并将该实例提交到具体的环境中运行；其中，所接收到的任务都会有各自的任务信息(比如，任务类型(hive或

spark)、任务的名称、任务是否有被依赖的任务和/或所依赖的任务，任务的参数变量等)。例如，执行代理会将Hive类型的任务提交到Hive环境中运行，而将Spark类型的任务提交到Spark环境中运行。

本发明实施例的运维方式通过生成的实例来执行，可以调用已生成的实例或者调用新生成的实例来进行运维。用户每提交一次作业，都会产生一个实例，这些实例都会存储在数据库(例如MySQL库)中，并会保存一定的时间。

本发明的实施例能实现如下功能：

1.补数据功能

补数据功能可以指定任意的日期段，并会生成每日的作业实例，其中，日期段为在可视化日期选择界面上任意指定的日期范围。这些实例可以通过两种方式来运行：自依赖补数据方法(如图2A所示)和并行执行补数据方法(如图2B所示)。自依赖补数据方法会根据作业日期的先后顺序，自动生成串行的依赖关系，其中后一日的实例只有在前一日的实例执行完毕之后才会执行。而并行执行补数据方法则没有这种依赖关系，每日的作业实例都是相互独立的，并行执行。

从图2A中可以看出，实例1至实例n具有不同的日期标签。自依赖补数据方法按照实例生成时间的先后顺序创建依赖关系。即，先执行实例1，实例1执行完毕后执行实例2，直至实例n-1执行完毕后执行实例n。

从图2B中可以看出，即使实例1至实例n具有不同的日期标签，并行执行补数据方法也同时执行各个实例，而不在实例之间创建任何依赖关系，

2.置成功功能

置成功功能可以将失败的作业实例设置为成功状态(如图3所示)。当作业失败但对整体作业流没有实际影响时，为了使得下游的作业能够顺利执行，可以将此作业实例设置为成功状态。此时，该作业下游的实例会由失败停止运行状态转变为运行或者等待运行状态。

3.重跑功能

重跑功能包括三种形式：单任务重跑功能(如图4A)、重跑下游功能(如图4B和图4C)、修复性重跑功能(如图4D)。

当某个作业失败时，可以对该作业进行重跑，也即，调度器会从mysql库中重新调度该失败作业的实例(已生成的单个实例)，并重新运行该失败作业的实例。这种方案为单任务重跑功能。

当某个作业失败而导致下游作业也失败时，可以通过重跑该作业(父节点)以及该作业的下游作业(子节点)来运行该作业及下游作业(即，首先重跑该作业，然后再重跑该作业的子节点作业)。调度器同样会调度这些作业已产生的实例。这种方案为重跑下游功能。

根据本发明的一个实施例，重跑下游功能还能自动识别任务的依赖关系的链路上的某个节点的外部父节点是否失败。例如如图4C所示，节点P是为圆圈内的链路中节点E的外部父节点。如果外部父节点失败，那么将不会执行重跑下游功能。这是因为该节点的上游的外部父节点已经失败而且该节点需要所有父节点的数据，所以再运行该节点就没有意义了。在图4C的例子中，如果在对节点A使用重跑下游功能的情况下，当节点P也同时失败，则不执行重跑下游功能。

当失败的下游作业还依赖其他上游作业(该失败的下游作业与其他上游作业存在依赖关系)，并且这些其他上游作业也失败时，那此时不能进行重跑下游。此时，可以采用修复性重跑功能。即，从最上游作业开始逐步运行整个工作流程。如果某个下游作业一旦成功执行则跳过该下游作业；如果该下游作业失败则重新运行。调度器同样会调度由这些作业产生的多个实例，并且按照实例的依赖关系执行工作流程。

本发明各实施例的方法和***可以实现为纯粹的软件(例如用Java语言来编写的软件程序)，也可以根据需要实现为纯粹的硬件(例如专用ASIC芯片或FPGA芯片)，还可以实现为结合了软件和硬件的***(例如存储有固定代码的固件***)。

本发明的另一个方面是一种计算机可读介质，其上存储有计算机可读指令，所述指令被执行时可实施本发明各实施例的方法。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所公开的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。要求保护的主题的范围仅由所附的权利要求进行限定。

Claims (17)

1.一种用于数据运维的***，包括：

执行代理，用于执行处理数据的任务的实例；

调度器，其用于将任务的实例分配到所述执行代理；

数据库，其存储所述实例的信息和与该实例相关的任务调度信息；以及

数据源，其存储所述实例运行时要处理的数据。

2.根据权利要求1所述的***，其中，所述调度器能够执行以下功能的至少之一：

补数据功能，用于指定任意的日期段，并生成每日的任务的实例；

置成功功能，用于将失败的任务的实例的状态改为成功；以及

重跑功能，用于当某个任务的实例失败时，对该实例进行重跑。

3.根据权利要求2所述的***，其中，所述补数据功能能够在指定日期范围内，根据日期先后顺序串行地运行任务的实例。

4.根据权利要求2所述的***，其中，所述补数据功能能够在指定日期范围内，不根据日期顺序、并行地运行任务的实例。

5.根据权利要求2所述的***，其中，所述重跑功能能够针对单个失败的任务的实例重新运行该任务的实例。

6.根据权利要求2所述的***，其中，所述重跑功能能够对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例。

7.根据权利要求2所述的***，其中，所述重跑功能能够执行以下功能：

(1)对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例；以及

(2)自动识别与任务相关的链路的外部父节点是否失败，并且如果该外部父节点失败，则不执行功能(1)。

8.根据权利要求2所述的***，其中，所述重跑功能能够对一任务的实例及其下游的任务的实例进行重新运行，并且在所述重新运行的过程中，跳过已执行成功的任务而仅重新运行失败的任务的实例。

9.一种用于在大数据平台上进行数据运维的方法，其中所述大数据平台包括用于执行处理数据的任务的实例的执行代理和用于存储任务的实例运行时要处理的数据的数据源，所述方法包括：

存储任务的实例的信息和与该实例相关的任务调度信息；和

将所述任务的实例分配到所述执行代理。

10.根据权利要求9所述的方法，其中，所述将所述任务的实例分配到所述执行代理的步骤还包括以下步骤的至少之一：

补数据步骤，用于指定任意的日期段，并生成每日的任务的实例；

置成功步骤，用于将失败的任务的实例的状态改为成功；以及

重跑步骤，用于当某个任务的实例失败时，对该实例进行重跑。

11.根据权利要求10所述的方法，其中，所述补数据步骤在指定日期范围内，根据日期先后顺序串行地运行任务的实例。

12.根据权利要求10所述的方法，其中，所述补数据步骤在指定日期范围内，不根据日期顺序、并行地运行任务的实例。

13.根据权利要求10所述的方法，其中，所述重跑步骤针对单个失败的任务的实例重新运行该任务的实例。

14.根据权利要求10所述的方法，其中，所述重跑步骤对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例。

15.根据权利要求10所述的方法，其中，所述重跑步骤包括以下步骤：

(1)对失败的任务的实例及该实例的下游任务的实例重新运行该任务的实例以及该下游任务的实例；以及

(2)自动识别与任务相关的链路的外部父节点是否失败，并且如果该外部父节点失败，则不执行步骤(1)。

16.根据权利要求10所述的方法，其中，所述重跑步骤对一任务的实例及其下游的任务的实例进行重新运行，并且在所述重新运行的过程中，跳过已执行成功的任务而仅重新运行失败的任务的实例。

17.一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令被计算机执行时能够执行如权利要求9-16中任意之一所述的方法。