CN106648859A - 一种任务调度方法和装置 - Google Patents

Abstract

本发明公开了一种任务调度方法和装置。其中方法包括：接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；根据生成的任务拓扑图完成任务调度。该技术方案可以避免一个任务因依赖另一任务而在不适当的条件下被启动，降低了任务运行的错误率。

Description

一种任务调度方法和装置

技术领域

本发明涉及计算机技术领域，具体涉及一种任务调度方法和装置。

背景技术

现有的任务调度往往是根据机器资源来完成的，亦或是根据需求将任务设置在固定的时间段内来运行。但这样就没有考虑到任务和任务之间的关系，如果一个任务依赖于另一个任务的结果数据才能运行，那么前述的任务调度显然是无法满足需求的。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的任务调度方法和装置。

依据本发明的一个方面，提供了一种任务调度方法，包括：

接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；

根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；

根据生成的任务拓扑图完成任务调度。

可选地，所述根据生成的任务拓扑图完成任务调度包括：

当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据所述任务拓扑图判断该任务是否依赖于其他任务运行；

如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；

如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

可选地，所述任务配置信息包括如下中的一种或多种：

任务的基本参数；

任务运行的时间条件；

任务运行的集群；

任务运行的物理资源条件；

任务运行的数据资源条件；

任务与其他任务的依赖关系。

可选地，所述根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：

从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

可选地，所述根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：

从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；所述任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

可选地，该方法还包括：

根据负载均衡原则，从任务运行的集群中选择至少一台机器运行该任务。

可选地，所述接收任务配置信息包括：

通过前端页面接收提交的任务配置信息；

该方法还包括：

响应于前端页面发送的展示指令，将多个任务和/或包含多个任务间依赖关系的任务拓扑图返回给前端页面进行展示。

可选地，该方法还包括：

接收前端页面发送的任务间依赖关系的新增/修改/删除指令，相应地生成或修改任务拓扑图。

可选地，该方法还包括：

接收任务配置修改指令，对相应任务的任务配置文件进行修改；

根据所述任务配置修改指令判断是否需要对该任务相关的任务拓扑图进行修改，若是，则根据修改后的任务配置文件对该任务相关的任务拓扑图进行修改。

依据本发明的另一方面，提供了一种任务调度装置，包括：

任务配置单元，适于接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；

任务拓扑图管理单元，适于根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；

任务调度单元，适于根据生成的任务拓扑图完成任务调度。

可选地，所述任务调度单元，适于当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据所述任务拓扑图判断该任务是否依赖于其他任务运行；如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

可选地，所述任务配置信息包括如下中的一种或多种：

任务的基本参数；

任务运行的时间条件；

任务运行的集群；

任务运行的物理资源条件；

任务运行的数据资源条件；

任务与其他任务的依赖关系。

可选地，所述任务拓扑图管理单元，适于从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

可选地，所述任务拓扑图管理单元，适于从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；所述任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

可选地，所述任务调度单元，适于根据负载均衡原则，从任务运行的集群中选择至少一台机器运行该任务。

可选地，所述任务配置单元，适于通过前端页面接收提交的任务配置信息；

该装置还包括：展示单元，适于响应于前端页面发送的展示指令，将多个任务和/或包含多个任务间依赖关系的任务拓扑图返回给前端页面进行展示。

可选地，所述任务拓扑图管理单元，还适于接收前端页面发送的任务间依赖关系的新增/修改/删除指令，相应地生成或修改任务拓扑图。

可选地，所述任务配置单元，还适于接收任务配置修改指令，对相应任务的任务配置文件进行修改；

所述任务拓扑图管理单元，适于根据所述任务配置修改指令判断是否需要对该任务相关的任务拓扑图进行修改，若是，则根据修改后的任务配置文件对该任务相关的任务拓扑图进行修改。

由上述可知，本发明的技术方案，通过任务的配置信息生成任务配置文件，再根据多个任务配置文件生成包含任务间依赖关系的任务拓扑图，通过任务拓扑图来实现任务的调度。该技术方案可以避免一个任务因依赖另一任务而在不适当的条件下被启动，降低了任务运行的错误率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了日志数据平台的工作流程示意图；

图2示出了根据本发明一个实施例的一种任务调度方法的流程示意图；

图3示出了根据本发明一个实施例的一种任务调度装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明的技术方案可以应用于日志数据平台，图1示出了日志数据平台的工作流程示意图。如图1所示，该日志数据平台将日志数据通过ETL(Extract-Transform-Load，抽取-转换-加载)处理，将结果数据保存到数据仓库，同时支持对日志数据的统计计算，生成报表保存到报表数据库；以及提供前端页面，便于用户的访问，了解任务的运行状况以及将报表数据进行可视化展示等。整个平台还提供权限管理功能和任务调度功能，对日志数据的处理、统计和展示进行调控。本发明将着重介绍其中的任务调度方面的内容。

图2示出了根据本发明一个实施例的一种任务调度方法的流程示意图，如图2所示，该方法包括：

步骤S210，接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件。

步骤S220，根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图。

步骤S230，根据生成的任务拓扑图完成任务调度。

可见，图2所示的方法，通过任务的配置信息生成任务配置文件，再根据多个任务配置文件生成包含任务间依赖关系的任务拓扑图，通过任务拓扑图来实现任务的调度。该技术方案可以避免一个任务因依赖另一任务而在不适当的条件下被启动，降低了任务运行的错误率。

在本发明的一个实施例中，上述方法中，根据生成的任务拓扑图完成任务调度包括：当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据任务拓扑图判断该任务是否依赖于其他任务运行；如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

现有的任务调度往往是预估其依赖的任务的运行时间，例如任务B可能在下午两点运行完毕，那么任务A的运行时间可能被设置为下午两点十分。但是考虑到任务的运行与运行任务的集群的空闲度有关，当集群较忙时，可能任务B会在下午两点半才运行完毕，这样在下午两点十分运行的任务A就会运行异常；而当集群较闲时，可能任务B在下午一点半就已运行完毕，而直到下午两点十分任务A才会运行，这四十分钟的时间集群的资源就被浪费了。而在本实施例中，当任务运行的其他条件满足后，在其依赖的任务运行完毕后该任务就可以运行。

在本发明的一个实施例中，上述方法中，任务配置信息包括如下中的一种或多种：任务的基本参数；任务运行的时间条件；任务运行的集群；任务运行的物理资源条件；任务运行的数据资源条件；任务与其他任务的依赖关系。

例如，指定任务在哪个集群上运行，要求集群上的机器满足什么配置；周期性任务可以设置为每日的固定时间段内执行，而临时任务也可以增加限制性条件，如仅在指定的一周内的每日的固定时间段内执行。将任务提交到集群时，可以根据负载均衡原则，从任务运行的集群中选择至少一台机器运行该任务。

在本发明的一个实施例中，上述方法中，根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

在本发明的一个实施例中，上述方法中，根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

上述两个实施例说明：如果报表生成任务中包含任务与其他任务的依赖关系，则可以直接根据任务与其他任务的依赖关系生成任务拓扑图；也可以根据任务运行的数据资源条件生成任务拓扑图，举例而言，任务A所需的数据是任务B得到的结果，那么任务B的输出地址与任务A的输入地址就是匹配的，这样就得到了任务A依赖于任务B。

用户可以通过前端页面查看到有查看权限的任务拓扑图，并对其进行修改；还可以根据有查看权限的多个任务，生成新的任务拓扑图。。在本发明的一个实施例中，上述方法中，接收任务配置信息包括：通过前端页面接收提交的任务配置信息；该方法还包括：响应于前端页面发送的展示指令，将多个任务和/或包含多个任务间依赖关系的任务拓扑图返回给前端页面进行展示。在本发明的一个实施例中，上述方法还包括：接收前端页面发送的任务间依赖关系的新增/修改/删除指令，相应地生成或修改任务拓扑图。前端页面可以可视化地呈现任务拓扑图，例如，用户在修改拓扑图时，只需要将任务作为节点拖入或拖出图，在两任务间以箭头标识依赖关系。

在本发明的一个实施例中，还可以通过对报表生成任务进行修改，来使得相应的任务拓扑图发送更改。即接收任务配置修改指令，对相应任务的任务配置文件进行修改；根据任务配置修改指令判断是否需要对该任务相关的任务拓扑图进行修改，若是，则根据修改后的任务配置文件对该任务相关的任务拓扑图进行修改。

前文提及，用户可以查看到有查看权限的任务拓扑图。另外，任务调度的具体任务可以是报表生成任务或者日志数据解析任务，下面的实施例将结合权限管理来介绍日志数据解析、入库和报表生成的具体实现。

在本发明的一个实施例中，上述方法包括：对至少一个指定业务的日志数据进行解析处理，得到业务的格式化的日志数据并保存到数据仓库中对应的数据集市中；为数据仓库中的各数据集市按用户分组配置权限；提供前端页面，根据前端页面发送的用户登录信息，确定该用户的用户分组信息；当接收到前端页面发送的数据集市查看指令时，根据该用户的用户分组信息，通过前端页面向该用户展示其有查看权限的数据集市信息。

数据仓库(Data Warehouse)特别适合将分散的数据进行规范化存储，并且数据仓库中可以根据业务的具体内容，设置相应的事实表和维度表，通常情况下，日志数据会被保存到相应的事实表中。当业务较多时，数据仓库中会设置多个数据集市(Data Mart)，每个数据集市可以对应一类业务。例如，产品A的部门成员只拥有对产品A的数据集市的查看权限，而不会拥有对产品B的数据集市的查看权限。如果用户A通过前端页面提交数据集市查看指令，可以查看到其拥有查看权限的数据集市信息，如数据集市名称。该技术方案实现了对业务的日志数据的统一管理入库以及权限分配，规范、有秩序地实现了对日志数据的管控，特别适合业务线多、日志数据量大、组织结构复杂的企业。

下述实施例将在权限管理的基础上，介绍日志数据的ETL处理。

在本发明的一个实施例中，图2所示的方法还包括：配置业务和域名的对应关系，将接收到的日志数据按域名进行分类；对至少一个指定业务的日志数据进行解析处理包括：根据该业务对应的域名，对该域名分类下的日志数据进行解析处理。

在实际应用中，以互联网公司为例，其往往会为经营的各业务分配不同的域名开进行业务的开展，因此产生的日志数据也都来自于不同的域名，将接收到的日志数据按域名进行分类可以快捷准确地实现将日志数据进行分类。由于分布式集群的广泛应用，各业务往往会在不同的分布式集群上进行开展，例如，同一业务的功能模块可能在全国的若干个不同集群上部署，同样地，同一集群上可能运行有多个业务线的任务，那么日志数据按来源等方式进行分类远远不如按域名分类快速简便。在本例中各域名下还可以有多个子域名，对应业务中的子业务，这样域名与业务的对应关系比较繁多，可以将其保存为元数据，作为数据字典来进行管理和使用。当然，也可以为元数据的查看、修改等按用户分组分配不同的权限，例如管理员可以拥有修改权限，普通用户仅拥有查看部分内容的权限等。

在本发明的一个实施例中，上述方法还包括：对输入的一条样例日志进行解析处理，输出格式化的解析结果；接收用户的解析结果确认指令后，记录解析样例日志所采用的日志解析规则；对至少一个指定业务的日志数据进行解析处理包括：根据所记录的日志解析规则，对用户指定的业务的源日志数据进行解析处理。

例如对于样例日志：<id＝123><sex＝male><age＝18>，可以得到日志解析规则为：用户ID是以“id＝”开始的一串数字；性别是以“sex＝”开始的一串字符；年龄是以“age＝”开始的数字。那么应用该日志解析规则，就可以对<id＝1233><sex＝male><age＝8>、<id＝12332><sex＝male><age＝28>这样的源日志数据进行解析了。

具体地，可以预设多个日志内容识别引擎，用于分别识别不同格式的日志内容并解析成一个或多个字段；将样例日志依次输入到多个日志内容识别引擎中；将各日志内容识别引擎的输出各字段进行汇总得到格式化的解析结果。

由于各业务所使用的系统或服务器可能不同，产生的日志数据的格式也是多种多样的。下面给出了几种日志的示例：

1、http://mbs.hao.360.cn/index.php？id＝1353332&sex＝male&age＝28&....

2、{"id":"13532232332","sex":"male","age":"28"}

3、<id＝13532232332><sex＝male><age＝28>

4、id->13532232332；sex->male；age->28

可见这四种日志的格式是完全不同的。在上述实施例中可以利用预设的多个日志识别引擎来识别不同格式的日志内容。例如，JSON是一种较为常用的数据格式，其内容包含的结构通常是特定的，例如以大括号、冒号，引号等符号将日志内容分隔为多个字段(如上面的示例2)，而针对JSON格式的日志识别引擎就可以将日志内容按这些分隔符进行解析处理，得到一个或多个字段的一条或多条数据。具体地，日志内容识别引擎可以包括如下中的一种或多种：IP地址识别引擎；时间戳识别引擎；用户ID识别引擎；渠道识别引擎；JSON格式内容识别引擎。IP地址的格式是可以预估的(例如：xxx.xxx.xxx.xxx)，用户ID往往将NAME、USER_ID或ID等作为key值，渠道会由开发人员设置相应的key值(例如channel)，时间戳的格式通常为“YYYY-MM-DD HH:mm:SS”。特别地，IP地址识别引擎还可以在识别出IP地址后，进一步解析IP地址，IP地址解析结果包括如下一个或多个字段：国家、省、市、运营商。当然，也可以根据需求，将其拓展到更详细的地址，IP地址解析结果还可以包括区、街道等拓展字段，但这些在通常情况下对于后续的处理用处较低，会浪费一定的资源，可以根据需求进行设置。

可以看出，日志识别引擎也是可配置的，例如不同业务对渠道所使用的key可能是不同的。因此在本发明的一个实施例中，提供日志内容识别引擎编辑接口，通过该接口接收增加/删除/修改日志内容识别引擎的指令，根据指令执行相应的日志内容识别模块增加/删除/修改操作。

在实际中日志的格式非常繁多。幸而这些日志格式大多都包含规范、可识别的结构，可以被不同的日志识别引擎所识别。但是对一个业务产生的日志数据而言，通常并不会用到所有的日志识别引擎，而业务产生的日志数据数量繁多，如果每次都调用所有的日志识别引擎来进行识别，不仅浪费资源，效率还很底下。因此在本发明的一个实施例中，上述方法中，仅将有输出结果的各日志内容识别引擎的识别解析规则汇总记录。这样下次在对该业务的日志数据进行解析处理时，就没有必要浪费实际不会使用到日志内容识别引擎了。

然而，并不是所有日志数据都是以这样规范的格式生成的，预设的日志识别引擎可以处理大部分的日志数据，但也会存在解析结果不符合日志原意的情况。因此在本发明的一个实施例中，当样例日志中存在各日志内容识别引擎均无法识别的内容时，通过自定义识别接口输出该内容；通过自定义识别接口接收人工识别后输入的识别结果和相应的识别解析规则；将该人工识别后输入的识别解析规则记录为解析样例日志所采用的日志解析规则的一部分。例如，常用的分隔符包括冒号、分号、大小括号等，如果一类业务的日志数据中包含了不常用的分隔符，就需要用户在自定义识别接口中进行识别结果和相应的识别解析规则输入。

在本发明的一个实施例中，上述方法还包括：通过前端页面接收输入的对解析结果中的各字段进行操作的指令，并执行相应的操作；对解析结果中的各字段进行操作的指令包括如下中的一种或多种：调整各字段的排序顺序的指令；修改指定字段的名称的指令；删除指定字段的指令。

例如，解析结果中的一个字段的数据对后续统计计算没有任何帮助，可以删除该字段；解析结果中的字段名称为“USERNAME”，后续处理时希望将其改为“用户名”等等，这些都可以在解析结果编辑界面进行操作。

上一实施例中可以对整个字段进行操作，而在本发明的一个实施例中，上述方法中，一个日志内容识别引擎的识别解析规则包括：对识别并解析出的一个或多个字段中的指定字段的参数值设置限定阈值；对于参数值超出限定阈值的日志数据进行丢弃处理。这样可以在日志解析时就丢弃掉部分不需要的数据，减少了后期进行日志数据丢弃的操作。

上述实施例中介绍了对日志数据进行解析处理的操作，而解析得到的业务的格式化的日志数据被保存到数据仓库中对应的数据集市中，具体地，需要根据字段属性确定该字段对应的数据仓库中的列；将待存储数据按字段存储到数据仓库中相应的列中。

前文述及，数据仓库中可以包括事实表和维度表，这些数据表通常是预先建好的，用于存储接收到的数据。因此，接收到的数据会被按属性确定其对应的是数据表中的哪个列。而各个表包含的列通常是不同的，因此在本实施例中只需要确定其对应的是数据仓库中的哪个列即可。

具体地，根据字段属性确定该字段对应的数据仓库中的列包括：读取数据仓库的元数据，得到数据仓库中各列的属性；根据字段属性和数据仓库中各列的属性，建立待存储数据中各字段的数据和各列的映射关系。元数据包括：数据仓库各列的业务属性和/或数据属性，其中，业务属性包括如下中的至少一种：业务名称、业务域名、业务描述信息；数据属性包括如下中的至少一种：列名、数据格式、数据类型。例如，“用户名”这个字段对应的是哪个列，诸如此类的对应关系可以保存在数据仓库的元数据中。

在本发明的一个实施例中，上述方法还包括：通过前端页面接收输入的对指定列的数据进行处理的指令，指令包括如下中的至少一种：数据解密，数据格式转换、数据编码转换；根据接收到的指令，对指定列的数据进行相应的处理。

例如，对该列的数据进行反序列化处理，使其变得可读；日志中的时间为冒号格式的数据，将其转换为时间戳，等等。

前述实施例中可以在日志识别引擎中对数据进行筛除，在本发明的一个实施例中还提供了对数据仓库中的数据进行筛除的方法：通过前端页面接收输入的对指定列的列值设置限定阈值的指令；根据该指令，将列值超出限定阈值的整条数据进行删除处理。例如，将访问次数低于3的整条数据进行删除。

相类似地，还可以通过前端界面接收输入的他对数据仓库中的各列进行操作的指令，并执行相应的操作；对数据仓库中的各列进行操作的指令包括如下中的一种或多种：调整各列的排序顺序的指令；修改指定列的列名的指令；删除指定列的指令。

需要注意的是，在该实施例中直接对数据仓库中的数据进行调整，而在前述实施例中虽然也可以调整各字段的排序顺序、修改指定字段的名称或删除指定字段，但这些数据还未存入数据仓库，处于数据缓存中。

在本发明的一个实施例中，上述方法中，数据集市包括至少一个数据表；为数据仓库中的各数据集市按用户分组配置权限还包括：为数据集市的各数据表按用户分组配置查看权限，以及为数据表的各列按用户分组配置查看权限；根据该用户的用户分组信息，通过前端页面向该用户展示其有查看权限的数据集市信息包括：根据该用户的用户分组信息，向该用户展示其有查看权限的数据表，和/或向该用户展示其有查看权限的数据表中的列。例如，运营人员可以查看业务流水的数据表，而技术人员不能查看。

下述实施例将介绍包含报表生成，即对格式化的日志数据进行统计计算的具体实现。

在本发明的一个实施例中，上述方法还包括：接收并保存用户通过前端页面提交的报表生成任务；根据报表生成任务中指定的数据集市中的日志数据，生成报表并保存至报表数据库；其中，生成的报表的各列的权限与其对应的数据集市中的数据表中列的权限相同；根据报表的各列的权限确定该报表的权限。

在本实施例中可以根据数据仓库中的日志数据，进行统计计算，生成统计报表等。由于是根据数据仓库中的数据生成的报表，其权限也跟随了原数据的权限。最后，如果一个报表包含四列，那么只有对这四列中任一列有权限的用户分组的用户才能查看该报表，并且其只能查看到其有查看权限的那一列。例如，用户A所在的用户分组可以查看报表的前三列，那么他看到的报表就只有三列而不是四列。

在本发明的一个实施例中，上述方法中，根据报表生成任务中指定的数据集市中的日志数据，生成报表并保存至报表数据库包括：根据报表生成任务，确定完成报表生成任务的数据处理模型，以及从相应的数据集市中读取指定日志数据；利用确定的数据处理模型对待日志数据进行数据处理，生成报表并保存至报表数据库。

现有的报表开发往往需要技术人员手动编写代码，对数据进行统计计算，费时费力，而且在需求的报表数量较多时，不能快速满足用户的需求。本实施例提供了一种报表的自动生成方法，用户只需要指定生成报表所需的日志数据，选择指定的数据处理模型，就可以得到相应的报表，简单省时。其中，报表生成任务包括：输入地址；根据报表生成任务中指定的数据集市中的日志数据，生成报表并保存至报表数据库包括：从输入地址读取日志数据，生成报表并保存至报表数据库。当然，报表数据库也可以由输出地址来指定。

除了指定输入地址，还可以由用户在报表生成任务中限定更多条件，例如使用数据集市中某个数据表的部分数据。因此在本发明的一个实施例中，报表生成任务包括：用户输入的标准查询语句或用户输入的查询参数；该方法还包括：以用户输入的标准查询语句查询相应的数据集市，得到用户指定的数据集市中的日志数据；或者，根据用户输入的查询参数生成标准查询语句，以生成的标准查询语句查询相应的数据集市，得到指定的数据集市中的日志数据。例如对于企业数据中心的技术人员而言，编写标准查询语句得心应手，但对于普通的业务人员可能并不会编写这样的查询语句。因此在本实施例中提供了将用户输入的查询条件进行拼装的功能。为了方便识别用户输入的内容，用户在查询时除了指定相应的数据集市外，还可以指定用于识别输入内容的字符库，避免输入的内容不被正确识别。

由于数据集市中的数据量十分庞大，如果用户不在查询条件中设置相应的限制，例如时间条件，所请求的数据量可能会引起数据集市的崩溃。因此在本发明的一个实施例中，上述方法还包括：设置语句过滤规则，对用户输入的标准查询语句或生成的标准查询语句进行过滤。上述查询的方法不仅可以用于具体日志数据的查询，也可以用于数据集市信息的查询。

生成报表所需的数据处理模型可以是用户指定的，也可以用户从提供的数据处理模型中选择的，在本发明的一个实施例中，根据报表生成任务，确定完成报表生成任务的数据处理模型包括：从数据处理模型库中选择指定的数据处理模型，其中，数据处理模型库中包含如下的至少一种数据处理模型：新增统计模型；活跃统计模型；留存统计模型。这些模型可以从日志中分别统计出某一日的日志中，在历史上未出现过的用户(新增用户)数量、指定时间段内活跃用户的数量、某一日新增用户的留存情况。当然，具体的数据模型可以根据业务需求进行添加或配置，在此不做限制。用户在使用这些数据处理模型时，一般不再需要编写代码，只需要提供参数信息即可使用，例如使用哪些列进行统计计算等。也就是说，报表生成任务还包括：指定的数据处理模型的参数信息；利用确定的数据处理模型对日志数据进行数据处理包括：应用参数信息对指定的数据处理模型进行配置后，利用配置后的数据处理模型对日志进行数据处理。

当然，这种“傻瓜式”的模型不能够满足用户的所有需求。因此在本发明的一个实施例中，上述方法中指定的数据处理模型为streaming模型；报表生成任务还包括：至少一段自定义的代码片段；参数信息包括：每段代码片段与streaming模型中一块逻辑分块的对应关系。

例如，用户希望利用Map-Reduce框架执行对日志数据的统计计算。那么在本实施例中，用户只需要分别开发Map程序代码段和Reduce程序代码段(也就是执行计算的核心逻辑)，而不需再编写完整代码。在提交报表任务时，只需要将Map程序代码段和Reduce程序代码段分别填入前端页面中与Map段和Reduce段相应的代码输入框，就可以在后台实现整体代码的拼装，这样程序易于管理和修改，也减少了代码编写错误的可能。

在上述模型都不能满足用户需求的情况下，用户也可以选择自定义的模型，因此上述方法中，报表生成任务包括：自定义的数据处理模型的地址；确定完成报表生成任务的数据处理模型包括：从该地址读取自定义的数据处理模型。或者，在代码量较小的情况下也可以通过前端页面之间上传。自定义的数据处理模型也可以保存到数据处理模型库中，上传者也可以为其分配权限。

除了上面根据数据集市中的日志数据生成报表的方法，用户也可以将其他方式开发的报表上传到报表数据库，进行统一的权限控制和管理。因此在本发明的一个实施例中，上述方法还包括：接收用户通过前端页面上传的报表，和/或根据用户通过前端页面提交的报表存储路径，从该路径获取指定的报表，保存到报表数据库。

在本发明的一个实施例中，上述方法还包括：根据用户的用户分组信息，向其展示可编辑权限的数据集市和/或报表；接收用户提交的权限编辑指令，对数据集市和/或报表的权限进行相应的编辑。

在本实施例中提供了权限的管理控制方法，拥有较高权限的管理者(例如数据中心的管理员)可以对其拥有编辑权限的数据的权限进行编辑。例如，业务负责人可以控制其每个小组的成员只可以看到该小组相关的报表。

在本发明的一个实施例中，上述方法还包括：根据该用户的用户分组信息，通过前端页面向该用户展示其有查看权限的报表名称；报表生成任务包括：用户指定的报表；根据报表生成任务中指定的数据集市中的日志数据，生成报表并保存至报表数据库包括：使用用户指定的报表的配置信息，根据报表生成任务中指定的数据集市中的日志数据生成报表。

在本实施例中提供了根据已有报表生成新报表的方法，可以称为“报表克隆”，即利用一个已开发完成的报表的配置信息，生成新的报表，这样新报表的形式等都与已开发的原报表相类似。

下述实施例还将介绍将报表数据进行可视化展示的具体实现。

在本发明的一个实施例中，上述方法还包括：当接收到用户输入的报表查看指令时，通过前端页面向该用户展示该报表中用户具有查看权限的列的数据。

由于报表中的数据量通常是很大的(可能包含业务开展以来的所有数据，例如几年的数据)，在前述实施例中只展示列名而不展示列中的具体数据。而在用户输入查看指令后，再将具体的数据(包含限制条件，例如，时间条件)进行展示。

在本发明的一个实施例中，上述方法还包括：将报表数据库中新增报表的查看次数初始化为零；当接收到用户输入的报表查看指令时，将相应报表的查看次数增加一；为各报表设置清理周期，在到达清理周期的时间点时，根据判断该报表的查看次数是否低于清理阈值，若低于，则删除相应的报表生成任务。

在报表生成任务设立后，由于日志数据在不断生成，因此报表数据也在不断的更新，这无疑耗费了大量的资源，因此对于查看量较少甚至为0的报表，将相应的报表生成任务进行删除可以节约资源。

在本发明的一个实施例中，上述方法还包括：根据用户的用户分组信息，向其展示其有使用权限的统计图模型，以使前端页面根据用户选定的统计图模型和已展示报表的数据，生成相应的统计图。

报表通常是表格的方式，这并不利于观看，而统计图的方式就更为直观，例如饼状图、柱状图等。因此在本实施例中提供了根据报表数据生成统计图的方法。而具体地，统计图模型包括如下中的任一种：根据前端页面中缓存的已展示报表的数据生成统计图的模型；重新从数据源获取该报表中用户具有查看权限的列的数据，生成统计图的模型；对已展示报表的数据源进行编辑的统计图模型。

上述模型中，根据前端页面中缓存的已展示报表的数据生成统计图的模型不需要与服务器进行交互，这样用户即使在前端页面上对数据进行排序、分类等等操作，都不会再浪费时间和资源对报表数据库进行访问；而对于数据实时性较为敏感的报表，就可以使用重新从数据源获取该报表中用户具有查看权限的列的数据，生成统计图的模型。另外，由于许多情况下用户希望对报表进行修改，例如修改列名，而访问报表数据库是十分复杂的，因此还提供了对已展示报表的数据源进行编辑的统计图模型。

由于报表生成任务可以面向企业内的所有用户，为保证稳定性，可以采用如下方法：提供用于接收报表生成任务的报表生成任务提交接口；为任务调度服务器的至少一项运行状态参数设置相应的报警阈值，监控任务调度服务器的当前运行状态参数；当监控到的任一项运行状态参数达到相应的报警阈值时，执行与该报警阈值对应的预定报警操作，以及将报表生成任务提交接口置为不可用。这样在任务调度服务器高负荷运行时，可以停用报表生成任务提交接口，不再接收新的报表生成任务，而在任务调度服务器不再高负荷运行时，重新恢复报表任务提交接口的可用性。即，当监控到的运行状态参数下降到报警阈值之下时，重新将报表生成任务提交接口置为可用；通过报表生成任务提交接口接收提交的报表生成任务，生成并保存相应的任务配置文件。

前述实施例中提及，任务需要提交到相应的集群中运行。在本发明的一个实施例中，还提供了如下方法：判断任务运行的集群是否满足任务提交条件，若满足，将相应的任务配置文件提交到相应的集群上。其中，任务提交条件包括如下中的至少一种：任务运行的集群可以访问；任务运行的集群的可用资源未超过预定阈值；任务运行的集群未处于维护状态。

也就是说，先判断任务运行的集群是否网络通畅、是否正在进行维护、是否还能运行该任务。否则任务无法正常提交到该集群，即使提交到了该集群，也不能够正确的运行。

用户还可以通过前端页面查看任务的运行状况。在本发明的一个实施例中，该方法还包括：响应于前端页面提交的任务选择指令，获取各集群中相应任务的任务运行状态信息，将相应任务的任务运行状态信息返回给前端页面进行展示。这样用户可以随时查看其有查看权限的任务的运行状态信息，如：任务运行阶段信息；任务运行进度信息；任务剩余时间信息；任务运行日志信息。任务的错误日志可以被及时读取，对任务进行修正；或者，任务分为多个阶段，例如需要进行多个阶段的统计计算，可以查看任务正在进行那个阶段。根据任务的总工作量和集群资源，还可以推断任务的运行进度和任务剩余时间。

任务往往不能够总是在集群上正常运行，现有技术中需要人工排除任务的错误信息，费时费力，在本发明的一个实施例中，上述方法还包括：接收各集群提交的任务失败日志；对任务失败日志进行分析，得到任务的失败信息。这样就把人工查看任务失败日志，排查失败原因的时间节省出来。具体地，对任务失败日志进行分析，得到任务的失败信息包括：预设包含至少一个失败模型的失败样例库；失败模型包括：任务失败日志匹配规则和任务的失败信息；将任务失败日志与失败样例库中的失败模型进行匹配，根据匹配到的失败模型得到任务的失败信息。

例如，输入路径中没有数据，这样任务无法运行，那么日志中就会有相应的记录。如果为这样的失败设置相应的失败模型，那么将任务失败日志与失败样例库中的失败模型进行匹配，就可以快速确定任务的失败信息，例如包括：任务的失败原因，任务的错误代码、任务的错误类型。任务的错误类型可以包括可重试型和不可重试型。以输入路径中没有数据为例，即使重试该任务，该输入路径中依然没有数据，那么任务还是不会正常运行。而如果仅是无法连接到相应的数据库，那么重试后很可能就会成功，这样的错误类型就是可重试型错误。因此任务的失败信息还可以包括：任务失败的解决方案；该方法还包括：依据任务失败的解决方案，将该任务重新提交到相应的集群上，或者，进行预定方式的报警处理。对于可重试型错误，将其将该任务重新提交到相应的集群上进行重试；对于不可重试型错误，进行预定方式的报警处理，例如向维护人员发送邮件或短信。

下述实施例介绍了对整个平台进行的监控管理。

在本发明的一个实施例中，上述方法还包括：对用户执行的任一项操作进行记录，按操作时间和用户信息对应保存到监控数据库中。

可以看出，用户执行的操作虽然有着严格的权限管理，但依然是十分敏感的操作。在本实施例中对用户执行的任一项操作进行记录，可以方便日后的排除，以及在发生秘密泄露事故时快速确定可疑人员。

在本发明的一个实施例中，上述方法还包括：按操作类型设置操作报警策略和对应执行的报警操作；当用户执行的任一项操作的匹配该操作类型的操作报警策略时，执行对应的报警操作。

例如，某用户虽然拥有对大批报表的查看权限，但在较短的时间段内，其大量地访问了这些报表，这种行为很可能是泄露企业秘密的行为，因此需要执行对应的报警操作，这样就可以尽量减少秘密泄露的损失，及时进行挽救。

图3示出了根据本发明一个实施例的一种任务调度装置的结构示意图，如图3所示，任务调度装置300包括：

任务配置单元310，适于接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件。

任务拓扑图管理单元320，适于根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图。

任务调度单元330，适于根据生成的任务拓扑图完成任务调度。

可见，图3所示的装置，通过任务的配置信息生成任务配置文件，再根据多个任务配置文件生成包含任务间依赖关系的任务拓扑图，通过任务拓扑图来实现任务的调度。该技术方案可以避免一个任务因依赖另一任务而在不适当的条件下被启动，降低了任务运行的错误率。

在本发明的一个实施例中，上述装置中，任务调度单元330，适于当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据任务拓扑图判断该任务是否依赖于其他任务运行；如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

在本发明的一个实施例中，上述装置中，任务配置信息包括如下中的一种或多种：任务的基本参数；任务运行的时间条件；任务运行的集群；任务运行的物理资源条件；任务运行的数据资源条件；任务与其他任务的依赖关系。

在本发明的一个实施例中，上述装置中，任务拓扑图管理单元320，适于从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

在本发明的一个实施例中，上述装置中，任务拓扑图管理单元320，适于从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

在本发明的一个实施例中，上述装置中，任务调度单元330，适于根据负载均衡原则，从任务运行的集群中选择至少一台机器运行该任务。

在本发明的一个实施例中，上述装置中，任务配置单元310，适于通过前端页面接收提交的任务配置信息；该装置还包括：展示单元，适于响应于前端页面发送的展示指令，将多个任务和/或包含多个任务间依赖关系的任务拓扑图返回给前端页面进行展示。

在本发明的一个实施例中，上述装置中，任务拓扑图管理单元320，还适于接收前端页面发送的任务间依赖关系的新增/修改/删除指令，相应地生成或修改任务拓扑图。

在本发明的一个实施例中，上述装置中，任务配置单元310，还适于接收任务配置修改指令，对相应任务的任务配置文件进行修改；任务拓扑图管理单元320，适于根据任务配置修改指令判断是否需要对该任务相关的任务拓扑图进行修改，若是，则根据修改后的任务配置文件对该任务相关的任务拓扑图进行修改。

需要说明的是，上述各装置实施例的具体实施方式与前述对应方法实施例的具体方式相同，在此不再赘述。

综上所述，本发明的技术方案，通过任务的配置信息生成任务配置文件，再根据多个任务配置文件生成包含任务间依赖关系的任务拓扑图，通过任务拓扑图来实现任务的调度。该技术方案可以避免一个任务因依赖另一任务而在不适当的条件下被启动，降低了任务运行的错误率。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的任务调度装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明的实施例公开了A1、一种任务调度方法，其中，该方法包括：

接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；

根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；

根据生成的任务拓扑图完成任务调度。

A2、如A1所述的方法，其中，所述根据生成的任务拓扑图完成任务调度包括：

当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据所述任务拓扑图判断该任务是否依赖于其他任务运行；

如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；

如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

A3、如A1所述的方法，其中，所述任务配置信息包括如下中的一种或多种：

任务的基本参数；

任务运行的时间条件；

任务运行的集群；

任务运行的物理资源条件；

任务运行的数据资源条件；

任务与其他任务的依赖关系。

A4、如A3所述的方法，其中，所述根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：

从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

A5、如A3所述的方法，其中，所述根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：

从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；所述任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

A6、如A3所述的方法，其中，该方法还包括：

根据负载均衡原则，从任务运行的集群中选择至少一台机器运行该任务。

A7、如A1所述的方法，其中，所述接收任务配置信息包括：

通过前端页面接收提交的任务配置信息；

该方法还包括：

响应于前端页面发送的展示指令，将多个任务和/或包含多个任务间依赖关系的任务拓扑图返回给前端页面进行展示。

A8、如A7所述的方法，其中，该方法还包括：

接收前端页面发送的任务间依赖关系的新增/修改/删除指令，相应地生成或修改任务拓扑图。

A9、如A1所述的方法，其中，该方法还包括：

接收任务配置修改指令，对相应任务的任务配置文件进行修改；

根据所述任务配置修改指令判断是否需要对该任务相关的任务拓扑图进行修改，若是，则根据修改后的任务配置文件对该任务相关的任务拓扑图进行修改。

本发明的实施例公开了B10、一种任务调度装置，其中，该装置包括：

任务配置单元，适于接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；

任务拓扑图管理单元，适于根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；

任务调度单元，适于根据生成的任务拓扑图完成任务调度。

B11、如B10所述的装置，其中，

所述任务调度单元，适于当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据所述任务拓扑图判断该任务是否依赖于其他任务运行；如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

B12、如B10所述的装置，其中，所述任务配置信息包括如下中的一种或多种：

任务的基本参数；

任务运行的时间条件；

任务运行的集群；

任务运行的物理资源条件；

任务运行的数据资源条件；

任务与其他任务的依赖关系。

B13、如B12所述的装置，其中，

所述任务拓扑图管理单元，适于从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

B14、如B12所述的装置，其中，

所述任务拓扑图管理单元，适于从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；所述任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

B15、如B14所述的装置，其中，

所述任务调度单元，适于根据负载均衡原则，从任务运行的集群中选择至少一台机器运行该任务。

B16、如B10所述的装置，其中，所述任务配置单元，适于通过前端页面接收提交的任务配置信息；

该装置还包括：展示单元，适于响应于前端页面发送的展示指令，将多个任务和/或包含多个任务间依赖关系的任务拓扑图返回给前端页面进行展示。

B17、如B16所述的装置，其中，

所述任务拓扑图管理单元，还适于接收前端页面发送的任务间依赖关系的新增/修改/删除指令，相应地生成或修改任务拓扑图。

B18、如B10所述的装置，其中，

所述任务配置单元，还适于接收任务配置修改指令，对相应任务的任务配置文件进行修改；

所述任务拓扑图管理单元，适于根据所述任务配置修改指令判断是否需要对该任务相关的任务拓扑图进行修改，若是，则根据修改后的任务配置文件对该任务相关的任务拓扑图进行修改。

Claims (10)

1.一种任务调度方法，其中，该方法包括：

接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；

根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；

根据生成的任务拓扑图完成任务调度。

2.如权利要求1所述的方法，其中，所述根据生成的任务拓扑图完成任务调度包括：

当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据所述任务拓扑图判断该任务是否依赖于其他任务运行；

如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；

如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

3.如权利要求1所述的方法，其中，所述任务配置信息包括如下中的一种或多种：

任务的基本参数；

任务运行的时间条件；

任务运行的集群；

任务运行的物理资源条件；

任务运行的数据资源条件；

任务与其他任务的依赖关系。

4.如权利要求3所述的方法，其中，所述根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：

从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

5.如权利要求3所述的方法，其中，所述根据已保存的多个任务配置文件，生成包含任务间依赖关系的任务拓扑图包括：

从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；所述任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。

6.一种任务调度装置，其中，该装置包括：

任务配置单元，适于接收任务配置信息，根据任务配置信息生成并保存相应的任务配置文件；

任务拓扑图管理单元，适于根据已保存的多个任务配置文件，生成并保存包含任务间依赖关系的任务拓扑图；

任务调度单元，适于根据生成的任务拓扑图完成任务调度。

7.如权利要求6所述的装置，其中，

所述任务调度单元，适于当任务拓扑图中的任一个任务满足该任务的除任务间依赖关系外的其他运行条件时，根据所述任务拓扑图判断该任务是否依赖于其他任务运行；如果不依赖其他任务运行，读取该任务的任务配置文件，直接运行该任务；如果依赖其他任务运行，则在其依赖的其他任务全部运行结束后，再读取该任务的任务配置文件，运行该任务。

8.如权利要求6所述的装置，其中，所述任务配置信息包括如下中的一种或多种：

任务的基本参数；

任务运行的时间条件；

任务运行的集群；

任务运行的物理资源条件；

任务运行的数据资源条件；

任务与其他任务的依赖关系。

9.如权利要求6所述的装置，其中，

所述任务拓扑图管理单元，适于从各任务配置文件中读取该任务与其他任务的依赖关系，生成任务拓扑图。

10.如权利要求6所述的装置，其中，

所述任务拓扑图管理单元，适于从各任务配置文件中读取该任务运行的数据资源条件，生成任务拓扑图；所述任务运行的数据资源条件包括：任务运行所需数据的输入地址，和/或任务运行结果的输出地址。