用于确保计算工作流的服务质量的系统和方法与流程

本发明要求2016年11月18日递交的第62/423,894号临时专利申请案在先申请优先权，该在先申请的内容以引入的方式并入本文本中。本申请还要求2017年5月30日递交的第15/607,721号专利申请案的在先申请优先权，该在先申请的内容也以引入的方式并入本文本中。

本文所述实施例大体上涉及工作流管理领域，更具体地，涉及确保计算工作流的服务质量。

背景技术：

在企业数据分析系统中，客户通常具有对各种控制系统的操作有影响的业务工作流，这些业务工作流可重复、复杂且相互依赖。通过构建大型节点集群的方式为客户提供服务，以同时运行多个任务。不同客户可能有不同要求和数据处理需求，所以可以根据正式协商的服务水平协议(servicelevelagreement，sla)向特定客户提供特定服务水平。sla通常会规定服务的特定方面，例如可用性、可服务性、性能和操作。也可以就违反sla的情况规定处罚。

在一些工作流中，顶级节点具有必须满足的严格期限，不同节点通常具有不同期限。另外，节点可以取决于共同的先辈节点，且给定节点的延迟可能会影响其余节点，从而可能导致整个系统sla不达标。然而，这个问题只能通过改善节点的服务来部分控制，因为如果出现了延迟，一些控制系统没有服务质量(qualityofservice，qos)控制过程来给任务提速。

因此，需要一种用于确保计算工作流的qos的改进系统和方法。

技术实现要素：

根据一方面，提供了一种用于确保计算工作流的服务质量的方法。所述方法包括：在计划单元处，向与所述计算工作流中每个节点相关联的一个或多个子任务中的每一个分配第一服务质量标识，其中，所述第一服务质量标识指示分配给每个节点的服务质量等级；向每个所述一个或多个子任务分配计划资源需求，其中，所述计划资源需求指示完成每个所述一个或多个子任务所需的系统资源总量；为分配有所述第一服务质量标识和所述计划资源需求的每个所述一个或多个子任务生成资源分配计划，其中，所述资源分配计划指示所述系统资源在至少一个资源管理器中随时间的分发情况；以及向所述至少一个资源管理器输出所述资源分配计划和所述第一服务质量标识，以对通过所述至少一个资源管理器外部的至少一个工作流编排器针对每个节点所提交的一个或多个作业实施所述服务质量等级，其中，每个所述一个或多个作业包括所述一个或多个子任务。

在一些示例实施例中，所述方法可以包括：从所述至少一个工作流编排器以及从所述至少一个资源管理器提取指示所述一个或多个子任务以及所述一个或多个作业的当前进度的执行信息；根据所述执行信息确定每个所述一个或多个子任务的实际资源需求；比较所述实际资源需求和所述计划资源需求；以及如果所述实际资源需求不同于所述计划资源需求，则动态调整至少一个所述一个或多个子任务的所述资源分配计划。

在一些示例实施例中，所述方法可以包括：在所述计划单元处，从所述至少一个工作流编排器接收输入数据，其中，所述输入数据包括所述计算工作流中节点的数量、节点之间的依赖关系和每个节点的元数据，所述元数据包括节点标识、每个节点的一个或多个期限、每个节点执行的一个或多个命令和每个节点的资源需求估计，基于所述输入数据来识别所述一个或多个子任务。

在一些示例实施例中，所述方法可以包括：在所述计划单元处，对所述一个或多个命令执行语法分析，以识别所述一个或多个命令中对所述至少一个资源管理器的操作有影响的命令；以及按序向每个所述识别出的命令分配编号，其中，所述第一服务质量标识包括所述节点标识和所述分配的编号。

在一些示例实施例中，所述方法可以包括：在所述计划单元处，基于每个节点的过去执行历史预测所述一个或多个子任务；以及按序向每个所述被预测的一个或多个子任务分配编号，其中，所述第一服务质量标识包括所述节点标识和所述分配的编号。

在一些示例实施例中，分配所述计划资源需求可以包括：在所述计划单元处，在所述一个或多个子任务之间均匀划分所述资源需求估计。

在一些示例实施例中，分配所述计划资源需求可以包括：在所述计划单元处，基于每个节点的过去执行历史预测每个所述一个或多个子任务的所述计划资源需求。

在一些示例实施例中，分配所述计划资源需求可以包括：在所述计划单元处，在预定时间段内执行每个所述一个或多个子任务；在所述预定时间段期满时终止每个所述一个或多个子任务；在终止每个所述一个或多个子任务时，获取每个所述一个或多个子任务的当前资源使用样本；以及根据所述当前资源使用样本确定所述计划资源需求。

在一些示例实施例中，所述方法可以包括：在所述计划单元处，识别所述一个或多个子任务中的非受控子任务，其中，每个非受控子任务与未知工作流相关联；以及分配所述计划资源需求可以包括：在所述计划单元处，将完成每个非受控子任务所需的系统资源总量设为零以及将所述非受控子任务设置为具有非零时长。

在一些示例实施例中，生成所述资源分配计划可以包括：在所述计划单元处，选择向每个所述一个或多个子任务分配资源分配的顺序，选择每个所述一个或多个子任务随时间的资源分配，以及选择每个所述一个或多个子任务的开始时间。

在一些示例实施例中，所述方法可以包括：在所述计划单元处，识别所述一个或多个子任务中违反所述一个或多个期限的子任务，将所述识别出的子任务添加到子任务拒绝列表，以及输出所述子任务拒绝列表。

在一些示例实施例中，所述方法可以包括：在作业提交器处，向每个所述一个或多个作业分配第二服务质量标识，其中，所述第二服务质量标识指示每个节点的所请求的服务质量等级；以及在所述至少一个资源管理器处，接收所述第一服务质量标识、所述第二服务质量标识和所述资源分配计划，以及根据如下内容分配所述系统资源：所述一个或多个作业中所述第二服务质量标识对应于所述第一服务质量标识的作业的资源分配计划。

在一些示例实施例中，分配所述第二服务质量标识可以包括：观察所述一个或多个作业的顺序，根据所述顺序向每个所述一个或多个作业分配编号，其中，所述第二服务质量标识包括所述分配的编号和节点标识。

根据另一方面，提供了一种用于确保计算工作流的服务质量的系统。所述系统包括：至少一个处理单元；以及非瞬时性存储器，其通信地耦合到所述至少一个处理单元并且包括计算机可读程序指令，其中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于：向与所述计算工作流中每个节点相关联的一个或多个子任务中的每一个分配第一服务质量标识，其中，所述第一服务质量标识指示分配给每个节点的服务质量等级；向每个所述一个或多个子任务分配计划资源需求，其中，所述计划资源需求指示完成每个所述一个或多个子任务所需的系统资源总量；为分配有所述第一服务质量标识和所述计划资源需求的每个所述一个或多个子任务生成资源分配计划，其中，所述资源分配计划指示所述系统资源在至少一个资源管理器中随时间的分发情况；以及向所述至少一个资源管理器输出所述资源分配计划和所述第一服务质量标识，以对通过所述至少一个资源管理器外部的至少一个工作流编排器针对每个节点所提交的一个或多个作业实施所述服务质量等级，其中，每个所述一个或多个作业包括所述一个或多个子任务。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于：从所述至少一个工作流编排器以及从所述至少一个资源管理器提取指示所述一个或多个子任务以及所述一个或多个作业的当前进度的执行信息；根据所述执行信息确定每个所述一个或多个子任务的实际资源需求；比较所述实际资源需求和所述计划资源需求；以及如果所述实际资源需求不同于所述计划资源需求，则动态调整至少一个所述一个或多个子任务的所述资源分配计划。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于：从所述至少一个工作流编排器接收每个节点的节点标识和每个节点执行的一个或多个命令；对所述一个或多个命令执行语法分析，以识别所述一个或多个命令中对所述至少一个资源管理器的操作有影响的命令；以及按序向每个所述识别出的命令分配编号，其中，所述第一服务质量标识包括所述节点标识和所述分配的编号。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于：从所述至少一个工作流编排器接收每个节点的节点标识和过去执行历史；基于所述过去执行历史预测所述一个或多个子任务；以及按序向每个所述被预测的一个或多个子任务分配编号，其中，所述第一服务质量标识包括所述节点标识和所述分配的编号。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于：识别所述一个或多个子任务中的非受控子任务，其中，每个非受控子任务与未知工作流相关联；以及分配所述计划资源需求，包括：将完成每个非受控子任务所需的系统资源总量设为零以及将所述非受控子任务设置为具有非零时长。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于生成所述资源分配计划，包括：选择向每个所述一个或多个子任务分配资源分配的顺序，选择每个所述一个或多个子任务随时间的资源分配，以及选择每个所述一个或多个子任务的开始时间。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于：向每个所述一个或多个作业分配第二服务质量标识，其中，所述第二服务质量标识指示每个节点的所请求的服务质量等级；以及根据如下内容分配所述系统资源：所述一个或多个作业中所述第二服务质量标识对应于所述第一服务质量标识的作业的资源分配计划。

在一些示例实施例中，所述计算机可读程序指令可由所述至少一个处理单元执行以用于分配所述第二服务质量标识，包括：观察所述一个或多个作业的顺序，根据所述顺序向每个所述一个或多个作业分配编号，其中，所述第二服务质量标识包括所述分配的编号和节点标识。

根据另一方面，提供了一种计算机可读介质，其上存储有可由处理器执行的程序代码以用于：向与计算工作流中每个节点相关联的一个或多个子任务中的每一个分配第一服务质量标识，其中，所述第一服务质量标识指示与每个节点相关联的服务质量等级；向每个所述一个或多个子任务分配计划资源需求，其中，所述计划资源需求指示完成每个所述一个或多个子任务所需的系统资源总量；为分配有所述第一服务质量标识和所述计划资源需求的每个所述一个或多个子任务生成资源分配计划，其中，所述资源分配计划指示所述系统资源在至少一个资源管理器中随时间的分发情况；以及向所述至少一个资源管理器输出所述资源分配计划和所述第一服务质量标识，以对通过所述至少一个资源管理器外部的至少一个工作流编排器针对每个节点所提交的一个或多个作业实施所述服务质量等级，其中，每个所述一个或多个作业包括所述一个或多个子任务。

在阅读本发明之后，本领域技术人员将会看到关于本改进的许多其它特征和组合。

附图说明

在图中：

图1a是根据一实施例的一种用于确保计算工作流的服务质量的示例系统的框图；

图1b是根据一实施例的计算工作流的示意图；

图1c是根据一实施例的应用于移动手持终端厂商环境的图1a中所述系统的示意图；

图2是图1a中所述系统的详细框图；

图3是设在图2的sla计划单元中的qos标识生成模块的框图；

图4示出了由图3的qos标识生成模块实现的示例过程；

图5示出了由设在图2的作业提交器中的qos标识生成模块实现的示例过程；

图6是图2的资源需求分配模块的框图；

图7是图2的计划框架模块的框图；

图8是图2的执行监测模块的框图；

图9是一种用于实现图2的sla计划单元的示例计算设备的框图；

图10示出了根据一实施例的一种用于确保计算工作流的服务质量的示例方法的流程图；

图11示出了图10中识别每个工作流节点的底层子任务并为每个子任务分配qos标识这两步骤的流程图；

图12示出了图10中确定每个子任务的总资源需求这一步骤的流程图；

图13示出了图10中为每个节点生成资源分配计划这一步骤的流程图；

图14示出了图10中在工作流编排和控制系统层面监测工作负载的实际进度这一步骤的流程图；

图15示出了图10中根据实际资源需求按要求更新现有资源分配计划这一步骤的流程图；

图16示出了根据一实施例的在图1a的控制系统处实现的用于生成qos标识并实施qos的示例过程的流程图。

需要注意的是，在所有附图中，相同的特征由相同的附图标号标识。

具体实施方式

参考图1a，现在将描述根据一实施例的用于确保计算工作流的服务质量(qualityofservice，qos)的示例系统100。系统100包括服务水平协议(servicelevelagreement，sla)计划单元102，该服务水平协议(servicelevelagreement，sla)计划单元102作为业务层104与底层系统106之间的中间层而提供的。业务层104包括工作流编排器108，工作流编排器108组织和编排网关集群110的多个相连计算机(通常称为节点，未示出)上的活动。工作流编排器108的示例包括但不限于oozie、control-m和azkaban。

底层系统106可以包括具有qos特征的系统(本文称为控制系统)和无法控制的且宜将资源设为零的系统(本文称为非受控系统)，如下文进一步论述的。控制系统的示例包括但不限于基于另一种资源协调者(yetanotherresourcenegotiator，yarn)的数据处理应用。非受控系统的示例包括但不限于传统数据库、数据传输服务和文件系统操作。底层系统106包括作业提交器112和资源管理器114。如下文将进一步论述的，作业提交器112将作业提交给资源管理器114，提交的作业由工作流编排器108执行的动作生成。作业提交器112的示例包括但不限于hive、pig、oracle、teradata、文件传输协议(filetransferprotocol，ftp)，安全外壳(secureshell，ssh)，hbase和hadoop分布式文件系统(hadoopdistributedfilesystem，hdfs)。

资源管理器114接收由作业提交器112提交的作业，并将提交的作业分发到可用的控制系统资源上。如本文所使用的，术语qos是指正在执行作业的资源分配或资源优先的等级。更具体地，资源管理器114对实际工作负载(例如业务层动作生成的底层控制系统作业，如下文进一步论述的)实施由sla计划单元102做出的系统资源分配决定，从而使任务运行得更快或更慢。本文提及的系统资源包括但不限于中央处理器(centralprocessingunit，cpu)、随机存取存储器(randomaccessmemory，ram)和网络带宽。应理解，资源管理器114可以是启用qos实施方案的任何底层系统。因此，资源管理器114可以包括但不限于调度器(例如yarn、mesos、平台负载共享设施(loadsharingfacility，lsf)、gridengine、kubernetes等)，以及启用实施qos功能的数据仓库系统(例如关系数据库管理系统(relationaldatabasemanagementsystem，rdbms)等)。

现参考图1b以及图1a，工作流编排器108将(例如业务用户指定的)业务逻辑封装到业务层工作流116(例如工作流图)中，管理可重复的工作负载，并确保连续处理。如本文所使用的，术语“业务层工作流”指由业务用户(例如工作流编排器108的用户)定义的一组相互依赖的业务层动作(本文也称为动作)118。期限通常在工作流层定义，这反过来会对某些作业施加严格的sla(包括但不限于完成期限)。具体地，业务用户定义业务层动作及其相互依赖关系，从而创建如116的业务层工作流。每个业务层动作118是业务层工作流116中的单个动作，由业务用户定义，可能会取决于一个或多个其它业务层动作118的完成，并且可以在其中一个网关集群节点上运行。业务层动作的示例为hive查询。

工作流编排器108的动作(例如业务层动作118)导致待由网关集群110处理的作业的提交。网关集群110将提交的作业分发到各个底层系统，例如底层系统106。在一些实施例中，网关集群110受工作流编排器108控制。在其它实施例中，网关集群110不受工作流编排器108控制。

具体地，单个业务层动作118可以实现控制系统工作流120，例如一组相互依赖的控制系统作业(在本文中也称为作业)122。然后，将每个控制系统作业122提交给底层系统106，以执行控制系统工作流120的单个步骤。在mapreduce框架中，控制系统作业122的示例为由hive提交给yarn的map/reduce作业。底层系统106从业务层104接收待处理的控制系统作业122，并相应地生成自己的工作负载(即，控制系统任务124的子流，在本文称为底层子任务)，其中，工作负载被分发到可用控制系统资源以便执行。具体地，将每个控制系统作业122划分为一个或多个底层子任务124，底层子任务124的性质和结构取决于由相应业务层作业动作使用的来执行其工作的应用。每个子任务124表示由控制系统资源管理器114当作控制系统作业122的一部分来执行的基本工作单元，控制系统作业122在给定控制系统资源上作为单个进程运行。例如，在mapreduce框架中，子任务可能是在一个数据块上运行的单个map任务或reduce任务。换言之，可以视子任务124为在集群上运行一段时间的单个计算容器，使得并行运行的一组子任务124的集体输出实现给定控制系统作业122的目标。

现参考图1c，现在将结合移动手持终端厂商环境来描述系统100的示例实施例。在所示实施例中，多个移动手持终端用户126与多个移动手持终端厂商服务器128交互，例如在移动手持终端厂商的在线商店中进行购买，在线搜索移动手持终端厂商的产品等。移动手持终端用户126与移动手持终端厂商服务器128之间的交互转而产生使用数据，使用数据以包括但不限于日志文件等的任何合适格式存储在数据库130等合适存储器中。移动手持终端厂商可能希望将使用数据用于商业目的，以便更好地了解客户、定制产品、选择未来投资方向、测量产品接纳程度或性能等。为此，可以使用设在业务层104处的工作流编排器(图1a中的标号108)中定义和执行的一组工作流来分析使用数据。在所示实施例中，第一工作流132a和第二工作流132b在业务层104处定义和执行。

第一工作流132a是两步工作流，包括使用任何合适方式(例如ssh)从源(例如从数据库130)传送使用数据的步骤134以及(例如在hdfs中)加密并存储传送数据的步骤136。定期(例如每小时)运行第一工作流132a以确保导入数据集的新鲜度。工作流132a的输出可以由业务层104内的所有业务单元(未示出)共享，其中，每个业务单元对该数据有不同的权限级别，且对业务单元希望对数据进行的分析有不同的要求。第二工作流132b也定期(例如每日)运行，包括步骤138：解密由第一工作流132a存储的数据，以及将解密的数据加载到供分析引擎(例如hive)使用的适当格式，其中，分析引擎将计算所需结果。随后的步骤140是：扫描加载和解密的数据(例如hive表)并对扫描的数据执行聚合操作。然后，在步骤142处，对聚合的表格进行分析操作，在步骤144处将得到的数据存储在查询数据库(例如mysql)中以备将来使用。然后，在步骤146处，按定期间隔(例如每天)生成报告，以供业务单元领导等使用。在所示实施例中，每天在严格期限(例如上午八点)之前执行生成报告的步骤146。工作流132a和132b的执行导致作业被提交给底层系统106。例如，在步骤146处生成的报告由驻留在底层系统106中的业务单元领导148使用，在步骤136处存储的数据可以由业务单元领导148(或数据分析员等任何其它实体)即席查询，以执行由工作流132b执行的日常任务未涵盖的更细粒度的分析。

应理解，在业务层104处定义的工作流132a、132b的类型对于会有数据提供到其中的业务单元是特定的，每个业务单元有其自己版本的、会被进行分析操作的工作流132a、132b。每个工作流132a、132b也可以具有不同期限或在不同时间段运行。而且，在所示实施例中，所有工作流与第一工作流132a都有依赖关系(如箭头150所示)。此外，将其工作流(例如作业)提交给底层系统106的每个业务单元可以具有不同优先级或在底层计算基础设施占据不同份额。因此，宜确保所有作业按不同业务单元的要求完成。

再参考图1a以及图1c，如将在下文进一步论述的，sla计划单元102是与业务层104和底层系统106相连接的实体，以确保计算工作流内的作业按照用户提出的规范和/或要求完成(例如满足高层工作流的期限和sla)。为此，sla计划单元102决定系统资源的调整方式。具体地，为了确保业务层层面的关键工作流满足关键工作流的期限和sla，sla计划单元102确定完成给定控制系统作业的总资源需求以及将资源随时间分配给不同任务的方式，如在下文进一步论述的。在一实施例中，sla计划单元102可以选择通过向给定作业提供该作业可以利用的最大资源的方式来尽可能快地运行该作业。在另一实施例中，sla计划单元102可以选择在仍能同时满足sla的情况下，向给定的工作提供尽可能少的资源。然后，sla计划单元102向资源管理器114传输资源分配决定，以便对实际提交的工作负载进行实施。具体地，无论作业何时到达底层系统106，sla计划单元102都会指示底层系统106按sla计划单元102确定的方式分配资源。

应理解，虽然本文将sla计划单元102图示和描述为与单个工作流编排器108相连接，但sla计划单元102可以同时连接多个工作流编排器。还应理解，虽然本文将sla计划单元102图示和描述为与单个底层系统106相连接，但sla计划单元102可以同时连接多个底层系统。

图2示出了sla计划单元102的示例实施例。sla计划单元102包括qos标识生成模块202、资源需求分配模块204、计划框架模块206和执行监测模块208。作业提交器112包括作业提交客户端210，作业提交客户端210又包括qos标识生成模块212。

如下文将进一步论述的，设在sla计划单元102中的qos标识生成模块202(本文称为“slaqos标识生成模块”)为每个工作流(例如网关集群)节点发现底层子任务，其中，底层子任务与该节点相关联。sla计划单元102还发现底层子任务之间的依赖关系。然后，slaqos标识生成模块202为给定节点的每个子任务生成唯一的qos标识。设在作业提交客户端210中的qos标识生成模块212运行补充过程，该补充过程生成的qos标识与slaqos标识生成模块202生成的标识相同。如本文所使用的，术语“qos标识”指由一个可控系统的用户用来引用已经分配的qos等级的凭证。

然后，资源需求分配模块204为给定节点的每个子任务确定并分配资源需求，并且相应地，计划框架模块206为具有资源需求和qos标识的每个子任务生成资源分配计划。如本文所使用的，术语“资源需求”是指在底层系统(图1a中的标号106)中完成作业所需的系统资源总量以及资源总量在资源和时间维度可以划分的条数。术语“资源分配计划”是指所需系统资源随时间分发的方式。

执行监测模块208在工作流编排和底层系统层面监测工作负载的实际进度，并向计划框架模块206报告进度信息。计划框架模块206通过使用进度信息动态地按要求调整先前生成的资源分配计划，以确保满足顶级期限和sla。如将在下文结合图8论述的，该调整可以包括重新规划所有子任务或重新规划单个子任务以局部保持进度。在一实施例中，调整以下项中的至少一个：向一个或多个子任务分配资源分配的顺序、一个或多个子任务的形状(即随时间的资源分配)以及一个或多个子任务的放置(即开始时间)。例如，计划框架模块206可以向给定控制系统作业提供更多的cpu电源电压(或vcore)，以便使作业运行得更快。如果完成了依赖给定控制系统作业的作业，则计划框架模块206还可以更早地启动该给定控制系统作业。

现参考图3和图4，slaqos标识生成模块202包括子任务发现模块302，子任务发现模块302可以包括一个或多个子模块304a、304b、304c……。slaqos标识生成模块202还包括标识生成模块306。slaqos标识生成模块202从工作流编排器108接收输入数据，该输入数据经处理生成具有qos标识的工作流图。输入数据可以由工作流编排器108推送或由sla计划单元(图2中的标号102)拉取。输入数据指示工作流节点的数量、工作流节点之间的依赖关系以及每个工作流节点的元数据。元数据包括但不限于每个节点的标识(w)、节点的期限或最早开始时间以及节点将在网关集群(图1a中的标号110)上执行的命令。在一些实施例中，元数据包括节点的资源需求估计。然后，输入数据由子任务发现模块302处理，以识别与每个工作流节点相关联的底层子任务。

子任务发现模块302使用各种技术来识别给定工作流节点的底层子任务，底层子任务分别由相应的子模块304a、304b、304c……实现。在一实施例中，语法分析模块304a用于对节点执行的命令进行语法分析，以识别影响底层系统(图1a中的标号106)的操作的命令。然后，语法分析模块304a向每个命令按顺序分配编号(n)。这在图4中示出，图4示出了由语法分析模块304a执行的子任务发现过程400a的示例。在子任务发现过程400a中，标识(w)为20589341的工作流节点402执行一组命令404。向解析器406(例如hive中的查询计划器)发送命令404，解析器406输出一组查询q1、q2……。然后，将命令404封装到合适的命令(例如来自hive的explain命令)4081、4082、4083，以发现相应的底层子任务4101、4102、4103。然后，将底层子任务按1到j+1排序。

在另一实施例中，为了识别给定工作流节点的底层子任务，使用子任务预测模块304b。子任务预测模块304b使用机器学习技术来检查给定工作流节点的历史运行。基于之前的运行，子任务预测模块304b预测该节点将执行的子任务，并向每个子任务分配编号(n)。这在图4中示出，图4示出了由子任务预测模块304b执行的子任务发现过程400b的示例。在过程400b中，子任务预测模块304b检查工作流节点历史412，工作流节点历史412包括由标识(w)为20589341的工作流节点402执行的一组过去作业414。然后，使用预测器416来预测将由工作流节点402执行的底层子任务4181、4182、4183。由过程400b(即使用子任务预测模块304b)发现的底层子任务4181、4182、4183与由子任务发现过程400a(即使用语法分析模块304a)发现的底层子任务4101、4102、4103相同。

然而应理解，可以使用除语法分析和预测之外的各种技术来发现每个工作流节点的底层子任务(如模块304c所示)。例如，用户可以就底层子任务会是什么提供自己的猜测，slaqos标识生成模块202可以接收该信息作为输入。而且，不管slaqos标识生成模块202使用何种技术，都希望slaqos标识生成模块202为每个工作流编排器(或业务层)动作准确地预测将会提交给底层系统(图1a中的标号106)的控制系统作业的数量和顺序。采用这种方式可以确保slaqos标识生成模块202生成的qos标识与设在作业提交客户端(图2中的标号210)中的qos标识生成模块(图2中的标号212)生成的qos标识相匹配，且提交的作业将能够使用预留资源。

从图4中可以看出，对于任何给定工作流节点，底层子任务包括与依赖型qos计划作业相关联的受控子任务(4101、4102或4181、4182)。底层子任务还包括与无法控制的工作流节点(也称为不透明或模糊工作流)相关联的非受控子任务(4103或4183)。如下文将要进一步论述的，sla计划单元(图2中的标号102)仅设置非受控工作的时长，并不向非受控工作分配资源。采用这种方式，即使资源可用于依赖非受控子任务的工作，依赖型工作也需要等待时长期满才能开始。

一旦发现了给定工作流节点的底层子任务，标识生成模块306为包括非受控子任务的每个子任务生成并分配唯一的qos标识。在一实施例中，使用(w，n)对作为qos标识，qos标识包括每个节点的标识(w)和分配给该节点的每个底层子任务的编号(n)。这在图4中示出，图4示出了针对两个子任务发现过程400a和400b，将qos标识420生成一对：包括节点标识20589341和子任务编号(1，……j+1)。然后，标识生成模块306向资源需求分配模块204输出工作流节点图，工作流节点图包括为每个工作流节点生成的qos标识。具体地，通过生成由子任务发现模块302识别的底层子任务之间的依赖关系，标识生成模块306在工作流编排器(图2中的标号108)提供的工作流图上进行扩展。

如上所述和图5中所示，设在作业提交客户端(图2中的标号210)中的qos标识生成模块(图2中的标号212)实施过程500，以复制由slaqos标识生成模块(图2中的标号202)实现的qos标识生成过程。相应地，针对与给定工作流节点502(具有标识(w)20589341)相关联的提交的作业，qos标识生成模块212生成qos标识。在示例过程500中，向hive查询分析器506发送节点502的命令504，hive查询分析器506输出查询q1和q2，这些查询继而又被分别执行，从而导致针对这两个查询，提交两组作业5081(编号1到i)和5082(编号i+1至j)。然后，通过观察提交的作业的顺序、确定每个提交的作业的编号(n，在图5中n＝1，……，j)以及使用(w，n)对作为qos标识来生成qos标识510。将理解，设在作业提交客户端210中的qos标识生成模块212仅为受控作业提供qos标识，不考虑非受控作业。还将理解，qos标识生成模块212生成qos标识510，qos标识510与由slaqos标识生成模块202为受控作业(1，……，j)生成的qos标识(图4中的标号420)相同。一旦生成，qos标识510被附加到提交给资源管理器(图2中的标号114)的工作负载，以便指示期望的(或请求的)qos等级并请求未来的资源分配。具体地，向资源管理器114发送qos标识510以便提交的作业使用资源分配。

现参考图6，资源需求分配模块204包括资源需求确定模块602，资源需求确定模块602可以包括一个或多个子模块604a、604b、604c、604d……。具体地，资源需求分配模块204使用各种技术来确定每个子任务的资源需求，子任务分别由子模块604a、604b、604c、604d……中的相应一个实现。资源需求分配模块204还包括预定定义语言(rdl++)描述生成模块606。资源需求分配模块204从slaqos标识生成模块(图2中的标号202)接收工作流节点图，其中针对每个工作流节点，元数据包括为该节点生成的qos标识。如上所述，在一些实施例中，元数据包括由用户使用合适的输入装置提供的节点的资源需求总估计。在这种情况下，资源需求确定模块602使用人工估计模块604a在节点的底层子任务之间均匀划分资源需求总估计。

在未提供资源需求估计的实施例中，资源需求确定模块602使用资源需求预测模块604b来获得节点的过去执行历史，并相应地预测每个子任务的资源需求。在其它实施例中，资源需求确定模块602使用子任务预先执行模块604c在预定时间段内预先执行每个子任务。在预定时间段期满后，子任务预先执行模块604c调用“kill”命令来终止子任务。在终止子任务后，子任务预先执行模块604c获得子任务的当前资源使用的样本，并使用资源使用样本来确定子任务的整体资源需求。对于被slaqos标识生成模块202标记为非受控的子任务，资源需求确定模块602将资源需求的资源使用维度设为零并且仅分配时长。应理解，为了确定和分配每个子任务的资源需求，可以使用除人工估计资源需求、预测资源需求以及预先执行子任务之外的技术(如模块604d所示)。

然后，rdl++描述生成模块606输出整个工作流的rdl++描述。rdl++描述作为工作流图提供，其中，工作流图规定每个子任务的总资源需求(即，完成子任务所需的系统资源总量，通常以兆字节的内存和cpu份额表示)以及每个子任务的时长。rdl++描述还规定非受控子任务只有时长，只有在该时长期满后，才可以计划依赖型任务。通过这种方式并且如上所述，可能一些工作流节点需要零资源但又具有时长，该时长期满前依赖型作业无法运行。

现参考图7，计划框架模块206包括资源分配计划生成模块702，资源分配计划生成模块702包括顺序选择模块704、形状选择模块706和放置选择模块708。计划框架模块206还包括期限错过检测模块710和执行信息接收模块712。计划框架模块206从资源需求分配模块(图2中的标号204)接收工作流节点图(例如rdl++描述)以及每个工作流节点的元数据。如上所述，元数据包括由slaqos标识生成模块(图2中的标号202)为每个工作流节点生成的qos标识、由资源需求分配模块204分配给该节点的资源需求以及(例如由用户使用合适的输入装置提供的)底层系统的容量。在一些实施例中，元数据包括(例如由用户使用合适的输入装置提供的)每个工作流节点的期限或最小开始时间。

然后，计划框架模块206使用资源分配计划生成模块702为rdl++图中的每个工作流节点生成节点的每个子任务的资源分配计划。资源分配计划规定子任务所需资源随时间分发的方式，从而指示相应工作流节点的qos等级。具体地，资源分配计划生成模块702通过以下方式确定每个子任务所需资源随时间的分发情况：选择向每个子任务分配资源分配的顺序，每个子任务随时间的资源分配和/或每个子任务的开始时间。为此，顺序选择模块704选择向每个子任务分配资源分配的顺序。形状选择模块706为每个子任务选择形状(即随时间的资源分配)。放置选择模块708为每个子任务选择放置(即开始时间)。

在一实施例中，顺序选择模块704、形状选择模块706和放置选择模块708中的每一个以启发式方式选择相应的顺序、形状和放置。在另一实施例中，顺序选择模块704、形状选择模块706和放置选择模块708中的每一个选择相应的顺序、形状和放置以便优化目标函数。在又一实施例中，顺序选择模块704、形状选择模块706和放置选择模块708中的每一个随机选择相应的顺序、形状和放置。在又一实施例中，在较不关键作业(例如属于期限相对不急的工作流一部分的作业)之前，将期限较早的工作流中的关键路径上的作业排序、塑形并放置。还应理解，顺序选择模块704、形状选择模块706和放置选择模块708可以按不同顺序操作，例如形状选择在顺序选择之前。此外，不同模块可以按交错或迭代的方式操作。

如上所述，在一些实施例中，提供每个工作流节点的期限或最小开始时间，作为计划框架模块206的输入。在这种情况下，对于每个工作流节点，期限错过检测模块710确定是否有任何子任务违反了该子任务的期限或最小开始时间。然后，期限错过检测模块710返回未满足期限的子任务列表。期限错过检测模块710还向资源管理器(图2中的标号114)输出资源分配计划和与每个子任务相关联的服务质量标识。资源管理器114等待qos标识与工作流节点相关联的qos标识相同的待提交作业(按照资源分配计划)，并实施工作流节点的资源分配计划中指定的qos等级。通过这种方式，可能确保在指定期限之前完成作业，并且sla要求满足各个用户需求。

应理解，sla计划单元102可以管理单个工作流编排器108或底层系统实例内的多个资源分配计划(例如用于多租户支持)。还应理解，除了向底层系统106提供每个子任务的资源分配计划之外，sla计划单元102还可以向工作流编排器108提供资源分配计划。在这种情况下，sla计划单元102可以向工作流编排器108推送资源分配计划。或者，工作流编排器108可以拉取资源分配计划。对于每个工作流节点，工作流编排器108然后可以使用资源分配计划来跟踪每个子任务的计划开始时间，或等待直到子任务的计划开始时间才提交工作流。

现参考图8以及图7，执行监测模块208用于在工作流编排和底层系统层面监测实际工作负载进度。为此，执行监测模块208包括执行信息获取模块802，其从工作流编排器(图1a中的标号108)和资源管理器(图1a中的标号114)获得执行状态信息。在一实施例中，执行信息获取模块802从工作流编排器108和资源管理器114提取(例如拉取)执行信息。在另一实施例中，工作流编排器108和资源管理器114向执行信息获取模块802发送(例如推送)执行信息。从工作流编排器108获得的执行状态信息包括关于顶级工作流节点执行的信息，包括但不限于开始时间、结束时间、正常终止和异常终止。从资源管理器114获得的执行状态信息包括关于底层系统作业的信息，包括但不限于开始时间、结束时间、完成百分比和实际资源需求。

一旦执行监测模块208确定实际工作负载进度，执行信息获取模块802向计划框架模块206发送执行信息。然后，在计划框架模块206中的执行信息接收模块712处接收执行信息，并将其发送到资源分配计划生成模块702，以便可以相应地调整一个或多个现有的资源分配计划。在资源需求分配模块(图2中的标号204)错误地确定原始资源需求的情况下，可能需要进行调整。例如，由于子任务需求预测错误，可能会出现确定的原始资源需求有误。不准确的用户输入(例如提供了不正确的资源需求估计)也会导致资源需求的确定有误。

当确定需要进行调整时，资源分配计划生成模块702基于实际资源需求来调整一个或多个先前计划的作业的资源分配计划。调整可能包括重新规划所有子任务或重新规划单个子任务以局部保持进度。例如，调整可以包括提升下游作业分配。在该方式中，通过使用执行监测模块208，即使在原始资源需求规划有误的情况下，也能满足顶级sla。

在一实施例中，一旦确定需要调整资源分配计划，资源分配计划生成模块702评估现有资源分配计划中是否有足够的容量来对资源分配计划进行调整。如果容量不足，则资源分配计划生成模块702输出指示不能进行调整的信息。该信息可以使用合适的输出装置输出给用户。例如，如果资源分配计划生成模块702确定一些子任务需要的资源比最初计划更多，则可能无法调整资源分配计划。在另一实施例中，考虑不同工作流的优先级并且调整资源分配计划，以便即使整个容量已用完，也可以完成容量更高的任务。具体地，即使资源分配计划中没有多余容量，在本实施例中，资源分配计划生成模块702也会将资源从一个子任务分配给容量更高的另一子任务。在又一实施例中，资源分配计划生成模块702调整现有资源分配计划，使得尽管未达到给定sla，但可以满足更多的sla。

图9是一种实现sla计划单元(图1a中的标号102)的计算设备900的示例实施例。计算设备900包括处理单元902和其中存储有计算机可执行指令906的存储器904。处理单元902可以包括能用于执行一系列步骤的任何合适设备，从而计算设备900或其它可编程装置执行指令906时，本文所述方法中的指定功能/动作/步骤得以执行。例如，处理单元902可以包括任何类型的通用微处理器或微控制器、数字信号处理(digitalsignalprocessing，dsp)处理器、中央处理器(centralprocessingunit，cpu)、集成电路、现场可编程门阵列(fieldprogrammablegatearray，fpga)、可重构处理器、其它适合编程或可编程逻辑电路或其任何组合。

存储器904可以包括任何合适的已知或其它机器可读存储介质。例如，存储器904可以包括但不限于电子、磁性、光学、电磁、红外或半导体系统、装置或设备或前述的任何适当组合的非瞬时性计算机可读存储介质。存储器904可以包括位于设备内部或外部的任何类型的计算机存储器的适当组合，例如随机存取存储器(random-accessmemory，ram)、只读存储器(read-onlymemory，rom)、光盘只读存储器(compactdiscread-onlymemory，cdrom)、电光存储器、磁光存储器、可擦除可编程只读存储器(erasableprogrammableread-onlymemory，eprom)、电可擦除可编程只读存储器(electrically-erasableprogrammableread-onlymemory，eeprom)、铁电ram(ferroelectricram，fram)等。存储器904可以包括适合于可检索地存储处理单元902可执行的机器可读指令906的任何存储装置(例如设备)。

现参考图10，现在将描述一种确保计算工作流的服务质量的示例方法1000。在向底层系统(图1a中的标号106)提交作业之前，方法1000由sla计划单元(图1a中的标号102)实施。方法1000包括：在步骤1002处，针对每个工作流节点，识别底层子任务和底层子任务间的依赖关系。然后，在步骤1004处，向每个子任务分配唯一的服务质量(qualityofservice，qos)标识。在步骤1006处，进一步确定每个子任务的总资源需求。在步骤1008处，输出整个工作流的预定定义语言(rdl++)描述。在步骤1010处，为rdl++描述中的每个节点生成资源分配计划。下一步骤1012为：在工作流编排和底层系统层面监测工作负载的实际进度。在步骤1014处，基于实际资源需求按要求更新一个或多个现有资源分配。然后，向底层系统资源管理器提交资源分配计划和相应的qos标识以便实施(步骤1016)。具体地，每当具有与其相关联的qosid的作业到达底层系统时，底层系统资源管理器根据相应资源分配计划(例如按相应资源分配计划的规定)进行资源分配。

现参考图11，在一实施例中，识别每个工作流节点的底层子任务的步骤1002包括：对由节点(w)执行的命令进行语法分析，以识别对底层系统的操作有影响的子任务(步骤1102a)在另一实施例中，识别每个工作流节点的底层子任务的步骤1002包括：使用机器学习技术基于先前运行来预测节点(w)将执行的子任务(步骤1102b)。如上所述，可以使用除了语法分析或预测之外的多种技术来发现底层子任务(如步骤1102c所示)。例如，尽管在图11中未示出，但是步骤1002可以包括：接收用户就底层子任务会是什么提供的预测。然后，向每个子任务分配qos标识的步骤1004包括：向每个先前识别出的子任务(包括非受控子任务)按序分配编号(n)(步骤1104)。然后，将(w，n)对用作所述节点的qos标识(步骤1106)。

参考图12，在一实施例中，步骤1006包括：在步骤1202处，在每个节点的子任务之间均匀地划分人工总估计，例如通过用户输入接收的人工估计。在另一实施例中，在步骤1204处，使用机器学习以基于过去执行历史预测每个子任务的资源需求。在又一实施例中，在预定时间段内预先执行每个子任务(步骤1206)。然后在步骤1208处，终止子任务，并获得子任务的当前资源使用样本。然后，在步骤1210处，使用当前资源使用样本以确定子任务的总资源需求。然后，下一步骤1212为：评估在qos标识生成过程(图10的步骤1002和1004)中是否已经标记了任何非受控子任务。如果未标记，则方法1000转到下一步骤1008。否则，下一步骤12142为：将非受控子任务的资源需求的使用维度设为零，并且向非受控子任务仅仅分配时长。

现参考图13，生成资源分配计划的步骤1010包括：在步骤1302处，选择向每个子任务分配资源分配的顺序。一旦选择了顺序，下一步骤1304就是获取下一子任务。然后，在步骤1306处，设置当前子任务随时间的资源分配和时长(即形状)。然后，在步骤1308处，设置子任务开始时间(即，放置)，在步骤1310处，将子任务添加到资源分配计划。然后，下一步骤1312是评估当前子任务是否错过了期限。如果错过了期限，则在步骤1314处，将子任务添加到拒绝列表中。否则，下一步骤1316是确定是否存在待分配资源分配的子任务。如果存在，则该方法返回步骤1304并获取下一子任务。否则，在步骤1318处，输出资源分配计划和拒绝列表。

如上所述，为了优化目标函数，可以按启发式方式或按随机方式选择顺序、形状和放置。关键工作业也可以在较不关键作业之前进行排序、塑形和放置。还应理解，步骤1302、1306和1308可以按不同顺序或以交错或迭代的方式执行。

参考图14，在工作流编排和底层系统层面监测工作负载的实际进度的步骤1012包括：在步骤1402处，提取关于顶级工作流节点执行和底层系统作业的执行信息。然后，在步骤1404处，向计划框架发送提取的信息，以便调整一个或多个现有资源分配计划。如图15所示，基于实际资源需求更新一个或多个现有资源分配计划的步骤1014包括：在步骤1502处，接收执行信息，并基于所接收的执行信息评估实际资源需求是否不同于计划资源需求(步骤1504)。如果相同，则该方法转到下一步骤，即图10的步骤1016。否则，在一实施例中，下一步骤1506是评估现有资源分配计划中是否有足够容量来进行调整。如果有，则下一步骤1508是基于实际工作负载执行信息和实际资源需求调整现有资源分配计划。否则，输出指示不能进行调整的信息(例如向用户输出，步骤1510)。然后，该方法转到步骤1016。例如，即使资源分配计划中没有多余容量，一个子任务的资源也可以分配给容量更高的子任务。或者，可以调整现有的资源分配计划，使得尽管未达到给定sla，但满足了更多的sla。

现参考图16，在底层系统(图1a中的标号106)处实施qos标识生成过程1600，该过程和图10的步骤1004相同。过程1600包括：在步骤1602处，针对每个工作流节点，观察所提交底层系统作业的顺序。然后，在步骤1604处，生成唯一的qos标识并将其附加到每个提交的作业。然后，下一步骤1606是针对所提交作业，实施资源分配计划中指定的qos等级(即，根据该资源分配计划来分配资源)，其中，所提交作业的qos标识与已生成有资源分配计划的工作流节点相关联的qos标识相同。从而，可能确保在底层系统层面呈现的提交作业达到特定服务水平，继而满足业务工作流sla。

以上描述仅为示例性的，相关领域的技术人员将认识到，可以在不脱离所公开发明的范围的情况下改变所述实施例。例如，本文所述的流程图和附图中的方框和/或操作仅用于示例目的。在不脱离本发明的教导的前提下，这些方框和/或操作可以有许多变化。例如，可以按不同顺序执行方框，或者可以添加、删除或修改方框。

尽管在方框图中示出了通过不同的数据信号连接来彼此通信的分立组件组，但是本领域技术人员将理解，当前实施例通过硬件和软件组件的组合来提供，其中一些组件通过硬件或软件系统的给定功能或操作来实现，并且所示出的许多数据路径通过计算机应用或操作系统内的数据通信来实现。基于这种理解，本发明的技术方案可通过软件产品的形式体现。软件产品可以存储在非易失性或非瞬时性存储介质中，存储介质可以是只读存储器(read-onlymemory，rom)、磁盘、光盘、闪存驱动器或任何其它合适的存储介质或者设备。

本文描述每个计算机程序可以以高级程序、面向对象的编程或脚本语言或其组合来实现，以与计算机系统进行通信。或者，程序可以以汇编或机器语言来实现。该语言可以是编译或解释语言。软件产品包括能够使计算机设备(个人计算机、服务器或网络设备)执行本发明实施例中提供的方法的多个指令。计算机可执行指令可以以许多形式，包括程序模块，由一个或多个计算机或其它设备执行。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件以及数据结构等。通常，该程序模块的功能可根据各实施例需要进行组合或分配。因此提供所示结构是为了本实施例的教导效率。在不脱离权利要求书的主题的情况下，本发明可以体现为其它具体形式。

此外，相关领域的技术人员将理解，虽然本发明公开和示出的系统、方法和计算机可读介质可以包括具体数量的元件/组件，但是可以修改系统、方法和计算机可读介质以包括更多或更少的这种元件/组件。本发明也涵盖和包含所有合适的技术变化。在阅读本发明后，本发明范围涵盖的修改对于本领域技术人员而言将是显而易见的，并且所附权利要求旨在涵盖这样的修改。