用于分布式计算中的资源划分的系统和方法

用于分布式计算中的资源划分的系统和方法
1.相关申请交叉引用
2.本技术要求于2018年12月4日提交的申请号为16/209,287、发明名称为“用于分布式计算中的资源划分的系统和方法(system and method for resource partitioning in distributed computing)”的美国专利申请的优先权，其全部内容通过引用结合在本技术中。
技术领域
3.本发明涉及分布式计算系统，尤其涉及分布式计算系统中的计算集群的计算资源的分配管理系统和方法。


背景技术：

4.在诸如云计算系统之类的分布式计算中，一组形成工作流的作业通常通过一组计算资源运行，每组计算资源称为一个计算集群。
5.典型的企业数据处理环境中存在两层系统。业务工作流层管理着工作流依赖关系及其生命周期，可以根据正式协商的服务水平协议(service level agreement，sla)由提供给给定客户的特定服务水平来定义。sla通常可以对工作流实行严格的时间和截止日期要求。资源管理系统层(或“控制系统”)根据各种策略来调度各个作业。
6.业务工作流层处理高层依赖关系，不需要了解底层资源可用性以及将资源分配给关键作业的时间和方式。资源管理系统层可以只了解各个作业，但不了解高层作业依赖关系和截止日期。
7.业务sla可以通过sla计划器连接到底层资源管理系统。这样的sla计划器可以为作业创建资源分配计划，资源分配计划可以动态地提交给底层资源管理系统，以便由底层资源管理系统的调度器执行资源预留。
8.然而，一些调度器不支持资源预留执行机制，因此无法接收资源分配计划。因此，很难保证关键工作流有足够可用资源使重要工作流能够在截止日期之前完成。
9.相应地，需要一种改进的将资源分配给工作流的系统和方法。


技术实现要素：

10.根据一方面，提供了一种用于分布式计算系统中的方法。所述方法包括：接收数据，其中，所述数据表示所述分布式计算系统的计算集群中的计算资源的总数量；根据所述计算资源的总数量，生成多个资源池，其中，所述多个资源池中的每个资源池都与包括在所述总数量的资源的一个或多个分区中的计算资源的数量相关联；根据与每个资源池相关联的所述计算资源的数量，将权重分配给所述多个资源池中的每个资源池；将所述多个资源池和分配给每个资源池的所述权重发送给所述计算集群的调度器。
11.在一些方面，所述方法还包括：从所述分布式计算系统的作业提交器接收一个作业的作业标识符；根据所述作业的资源分配，为所述作业选择所述多个资源池中的一个资
源池，其中，所述资源分配表示所述计算集群中为执行所述作业而分配的计算资源的数量；将所述选择的资源池发送给所述作业提交器。
12.在一些方面，所述将所述选择的资源池发送给所述作业提交器包括：将所述选择的资源池发送给所述作业提交器以提交给所述调度器，所述调度器根据所述选择的资源池分配所述计算集群中的计算资源来执行所述作业。
13.在一些方面，所述选择的资源池与未分配给另一个作业的计算资源的数量相关联。
14.在一些方面，所述方法还包括：从所述分布式计算系统的所述作业提交器接收第二作业的第二作业标识符；根据所述第二作业的第二资源分配，为所述第二作业选择所述多个资源池中的第二资源池，其中，所述第二资源分配表示所述计算集群中为执行所述第二作业而分配的计算资源的数量；将所述选择的第二资源池发送给所述作业提交器。
15.在一些方面，所述方法还包括：在将所述选择的资源池发送给所述作业提交器之后，指示所述选择的资源池不可用于选择，并在接收到所述作业执行完成的通知之后，指示所述选择的资源池可用于选择。
16.在一些方面，所述多个资源池包括至少一个临时资源池和一个或多个计划内作业资源池，所述作业是一个计划内作业，所述选择的资源池是所述一个或多个计划内作业资源池中的一个。
17.在一些方面，所述方法还包括：从所述作业提交器接收计划外作业的作业标识符，并选择所述至少一个临时资源池中的一个。
18.在一些方面，一个资源池的权重根据与所述资源池相关联的计算资源的数量相对于所述计算集群中的计算资源的总数量的比例来确定。
19.在一些方面，所述多个资源池与所述计算集群中的所述计算资源的总数量相关联。
20.在一些方面，所述方法还包括：在所述作业正在执行时为所述作业选择所述多个资源池中的另一个资源池，并将所述选择的另一个资源池发送给所述作业提交器。
21.根据另一方面，提供了一种分布式计算系统。所述分布式计算系统包括：至少一个处理单元；非瞬时性存储器，以通信方式耦合到所述至少一个处理单元并包括可由所述至少一个处理单元执行的计算机可读程序指令，以用于：接收数据，其中，所述数据表示所述分布式计算系统的计算集群中的计算资源的总数量；根据所述计算资源的总数量，生成多个资源池，其中，所述多个资源池中的每个资源池都与包括在所述总数量的资源的一个或多个分区中的计算资源的数量相关联；根据与每个资源池相关联的所述计算资源的数量，将权重分配给所述多个资源池中的每个资源池；将所述多个资源池和分配给每个资源池的所述权重发送给所述计算集群的调度器。
22.在一些方面，所述计算机可读程序指令可由所述至少一个处理单元执行，以用于：从所述计算机集群的作业提交器接收一个作业的作业标识符；根据所述作业的资源分配，为所述作业选择所述多个资源池中的一个资源池，其中，所述资源分配表示所述计算集群中为执行所述作业而分配的计算资源的数量；将所述选择的资源池发送给所述作业提交器。
23.在一些方面，所述将所述选择的资源池发送给所述作业提交器包括：将所述选择
的资源池发送给所述作业提交器以提交给所述调度器，所述调度器根据所述选择的资源池分配所述计算集群中的计算资源来执行所述作业。
24.在一些方面，所述计算机可读程序指令可由所述至少一个处理单元执行，以用于：在将所述选择的资源池发送给所述作业提交器之后，指示所述选择的资源池不可用于选择，并在接收到所述作业执行完成的通知之后，指示所述选择的资源池可用于选择。
25.在一些方面，所述多个资源池包括至少一个临时资源池和一个或多个计划内作业资源池，所述作业是一个计划内作业，所述选择的资源池是所述一个或多个计划内作业资源池中的一个。
26.在一些方面，所述计算机可读程序指令可由所述至少一个处理单元执行，以用于：从所述作业提交器接收计划外作业的作业标识符，并选择所述至少一个临时资源池中的一个。
27.在一些方面，一个资源池的权重根据与所述资源池相关联的计算资源的数量相对于所述计算集群中的计算资源的总数量的比例来确定。
28.在一些方面，所述多个资源池与所述计算集群中的所述计算资源的总数量相关联。
29.在一些方面，所述计算机可读程序指令可由所述至少一个处理单元执行，以用于：在所述作业正在执行时为所述作业选择所述多个资源池中的另一个资源池，并将所述选择的另一个资源池发送给所述作业提交器。
30.结合附图和以下描述，其它特征将变得显而易见。
附图说明
31.在说明示例性实施例的附图中，
32.图1为一种示例性分布式计算系统的框图；
33.图2a为一种示例性资源服务器的框图；
34.图2b为一种示例性计算设备的框图；
35.图3为根据一个实施例的一种资源管理系统的框图；
36.图4示出了根据一个实施例的使用公平调度器的资源执行的概述；
37.图5为图3的资源管理系统的组件的框图；
38.图6为图5的sla计划单元中提供的资源池预创建模块的框图；
39.图7示出了根据一个实施例的通过资源池预创建的资源划分；
40.图8为图5的sla计划单元中提供的服务质量(quality of service，qos)标识符生成模块的框图；
41.图9示出了由图8的qos标识符生成模块实现的示例性流程；
42.图10示出了由图5的作业提交器中提供的qos标识符生成模块实现的一种示例性流程；
43.图11为图5的资源需求分配模块的框图；
44.图12为图5的计划框架模块的框图；
45.图13为图5的资源池分配模块的框图；
46.图14示出了根据一个实施例的资源分配计划的一个示例；
47.图15示出了根据一个实施例的图14的包括资源池分配的资源分配计划；
48.图16为图5的资源池标识符模块的框图；
49.图17示出了通过公平调度器执行图15所示的资源池定义的一个示例；
50.图18为图5的执行监控模块的框图；
51.图19为根据一个实施例的资源池预创建的流程图；
52.图20为根据一个实施例的一种在计算工作流中生成和更新资源分配计划的示例性方法的流程图；
53.图21为图20的标识每个工作流节点的底层子任务并将qos标识符分配给每个子任务的步骤的流程图；
54.图22为图20的确定每个子任务的总资源需求的步骤的流程图；
55.图23为图20的为每个节点生成资源分配计划的步骤的流程图；
56.图24为图20的监控工作流协调和控制系统级的工作负载的实际进度的步骤的流程图；
57.图25为图20的根据实际资源需求更新一个或多个现有资源分配计划的步骤的流程图；
58.图26为根据一个实施例的在图3的底层控制系统中实现的生成qos标识符的示例性流程的流程图；
59.图27为由图3的sla计划单元中的资源池分配模块实现的为qos标识符分配资源池的示例性流程的流程图；
60.图28为在图3的作业提交器中实现的检索qos标识符对应的资源池标识符的示例性流程的流程图；
61.图29示出了根据一个实施例的计划内作业和临时作业的资源分配；
62.图30示出了根据一个实施例的计划运行作业的集体缩小；
63.图31示出了根据一个实施例的计划运行作业的集体扩大；
64.图32示出了根据一个实施例的计划具有新资源池依赖关系的作业；
65.图33示出了根据一个实施例的冗余资源池的分配。
具体实施方式
66.图1为一种示例性分布式计算系统100的示意图。在分布式计算系统100中，一个或多个计算设备102可以直接或间接连接到一个或多个资源服务器103，以访问或以其它方式使用资源服务器103提供的一个或多个资源150。
67.分布式计算系统100包括硬件组件和软件组件。例如，如图所示，分布式计算系统100包括经由网络107连接的计算设备102和资源服务器103的组合。如图所示，资源服务器103包括一个或多个资源150，这些资源可以进行分配，以执行来自一个或多个计算设备102的计算工作流。资源服务器103提供内存(例如，随机存取存储器(random access memory，ram))、处理器或处理器核等处理单元、图形处理单元(graphics processing unit，gpu)、存储设备、通信接口等，这些在本文中分别统称为资源150。一组资源服务器103可以称为一个“计算集群”。资源可以逻辑上被划分成不同大小的多个资源池，下面详细说明。
68.资源管理系统109(如下进一步详述且如图3所示)可以实现为一个或多个计算设
备102等中的软件，并且可用于协调资源服务器103中的资源150的分配来执行计算设备102生成的工作流。在一些实施例中，除资源服务器103中的资源之外，资源150还包括计算设备102中的资源。在一些实施例中，资源服务器103生成工作流以通过计算资源150执行。在一些实施例中，资源管理系统109实现为单独的硬件设备。资源管理系统109也可以通过软件、硬件或其组合实现。
69.计算设备102可以包括个人计算机、笔记本电脑、服务器、工作站、超级计算机、智能手机、平板电脑、可穿戴计算设备等。如图所示，计算设备102和资源服务器103可以经由网络107互连，网络107可以为局域网、广域网、无线网络、互联网等中的一个或多个。
70.分布式计算系统100可以包括一个或多个资源服务器103中的一个或多个处理器101。一些资源服务器103可以包括多个处理器101。
71.在一些实施例中，分布式计算系统100是异构的。也就是说，分布式计算系统100的硬件组件和软件组件可以互不相同。例如，一些计算设备102可以具有不同的硬件结构和软件结构。同理，一些资源服务器103可以具有不同的硬件结构和软件结构。在其它实施例中，分布式计算系统100是同构的。也就是说，计算设备102可以具有类似的硬件结构和软件结构。同理，资源服务器103具有类似的硬件结构和软件结构。
72.在一些实施例中，分布式计算系统100可以是物理上或逻辑上的单个设备，例如单个计算设备102或包括一个或多个资源150的单个资源服务器103。在一些实施例中，分布式计算系统100可以包括以各种方式连接的多个计算设备102。
73.一些资源150可以在物理上或逻辑上与单个计算设备102或一组设备相关联，而其它资源150可以是共享资源，这些共享资源可以在计算设备102之间共用并由分布式计算系统100中的多个设备使用。也就是说，一些资源150只能被分配给来自一部分计算设备102的工作流，而其它资源150可以被分配给来自任何计算设备102的工作流。在一些实施例中，分布式计算系统100根据共享策略进行操作。共享策略是指规定如何使用特定资源的规则。例如，资源管理系统109可以实现共享策略，该共享策略规定使用特定资源服务器103中的资源150执行来自特定计算设备102的工作流。共享策略可以针对资源服务器103中的特定类型的资源150设置，并且还可以更广泛地应用于资源服务器103中的所有资源或应用于整个系统。计算设备102还可以表示用户、用户组或租户或项目。共享策略可以规定用户、用户组或租户或项目之间如何共用资源。
74.分布式计算系统100中的资源150是一个或多个属性或可以与一个或多个属性相关联。这些属性可以包括资源类型、资源状态(state/status)、资源位置、资源标识符/名称、资源值、资源容量、资源能力或任何其它资源信息(可以用作选择或标识适合由一个或多个工作负载使用的资源的标准)等。
75.分布式计算系统100在概念上可以看作是包括各种硬件、软件和其它组成资源的单个实体，这些硬件、软件和其它组成资源可以用于运行来自分布式计算系统100内部的组件以及来自分布式计算系统100外部的计算设备102的工作负载。
76.图2a为一种示例性资源服务器103的框图。如图所示，资源服务器103包括一个或多个处理器101、内存104、存储器106、i/o设备108和网络接口110及其组合。资源服务器103中的处理器101、内存104、存储器106、i/o设备108和网络接口110中的一个或多个用作资源150，以执行来自分布式计算系统100中的计算设备102的工作流。
77.处理器101是任何合适类型的处理器，例如实现arm或x86指令集的处理器。在一些实施例中，处理器101是中央处理单元(central processing unit，cpu)、图形处理单元(graphics processing unit，gpu)或张量处理单元(tensor processing unit，tpu)。在一些实施例中，处理器121包括加速器。内存104是处理器101可访问的任何合适类型的随机存取存储器。存储器106可以是内存、硬盘驱动器或其它永久性计算机存储设备的一个或多个模块。
78.i/o设备108包括诸如屏幕之类的用户接口设备等，包括能够将渲染图像显示为输出并接收触摸式输入的电容屏幕或其它触敏屏幕。在一些实施例中，i/o设备108另外或可选地包括扬声器、麦克风、诸如加速仪和全球卫星定位系统(global positioning system，gps)接收器之类的传感器、键盘等中的一个或多个。在一些实施例中，i/o设备108包括将计算设备102连接到其它计算设备的端口。在一个示例中，i/o设备108包括连接到外围设备或主机计算设备的通用串行总线(universal serial bus，usb)控制器。
79.网络接口110能够将计算设备102连接到一个或多个通信网络。在一些实施例中，网络接口110包括有线接口(例如有线以太网)和无线方式中的一个或多个，无线方式可以是wi
‑
fi或蜂窝(例如gprs、gsm、edge、cdma、lte等)。
80.资源服务器103在软件程序的控制下操作。计算机可读指令存储在存储器106中，并由处理器101在内存104中执行。
81.图2b为一种示例性计算设备102的框图。计算设备102可以包括一个或多个处理器121、内存124、存储器126、一个或多个输入/输出(input/output，i/o)设备128和网络接口130及其组合。
82.处理器121是任何合适类型的处理器，例如实现arm或x86指令集的处理器。在一些实施例中，处理器121是中央处理单元(central processing unit，cpu)、图形处理单元(graphics processing unit，gpu)或张量处理单元(tensor processing unit，tpu)。在一些实施例中，处理器121包括加速器。内存124是处理器121可访问的任何合适类型的随机存取存储器。存储器126可以是内存、硬盘驱动器或其它永久性计算机存储设备的一个或多个模块。
83.i/o设备128包括诸如屏幕之类的用户接口设备等，包括能够将渲染图像显示为输出并接收触摸式输入的电容屏幕或其它触敏屏幕。在一些实施例中，i/o设备128另外或可选地包括扬声器、麦克风、诸如加速器和全球卫星定位系统(global positioning system，gps)接收器之类的传感器、键盘等中的一个或多个。在一些实施例中，i/o设备128包括将计算设备102连接到其它计算设备的端口。在一个示例中，i/o设备128包括连接到外围设备或主机计算设备的通用串行总线(universal serial bus，usb)控制器。
84.网络接口130能够将计算设备102连接到一个或多个通信网络。在一些实施例中，网络接口130包括有线接口(例如有线以太网)和无线方式中的一个或多个，无线方式可以是wi
‑
fi或蜂窝(例如gprs、gsm、edge、cdma、lte等)。
85.计算设备102在软件程序的控制下操作。计算机可读指令存储在存储器126中，并由处理器121在内存124中执行。
86.图3为一种示例性资源管理系统109的框图。资源管理系统109包括业务层304、服务水平协议(service level agreement，sla)计划单元302、底层控制系统306和作业提交
器312。底层控制系统306以通信方式耦合到资源150。资源150可以包括计算集群中的资源，该计算集群包括一个或多个资源服务器103。在一些实施例中，资源150包括计算集群中的资源，该计算集群包括资源服务器103中的资源150和计算设备102中的资源。
87.资源管理系统109可以保证工作流中的服务质量(quality of service，qos)。本文所使用的qos是指正在执行的作业的资源分配或资源优先级的水平。
88.资源管理系统109可以由分布式计算系统100中的一个或多个计算设备102或资源服务器103中的一个或多个处理器101实现。在一些实施例中，资源管理系统109是一种可以运行在分布式计算系统之上的基础平台中间件。
89.资源管理系统109负责资源管理、工作流管理和调度。工作流可以是指将在分布式计算系统100上允许的任何进程、作业、服务或任何其它计算任务。例如，工作流可以包括批量作业(例如高性能计算型(high performance computing，hpc)批量作业)、串行和/或并行批量任务、实时分析、虚拟机、容器等。工作流的特征可以有很大的差异。例如，工作流可以是cpu密集型的、内存密集型的、批量作业(需要快速周转的短期任务)、服务作业(长期运行任务)或实时作业。
90.业务层304组织多个连接的客户端计算机(通常称为计算节点，未示出)，并协调连接的客户端计算机上的活动。为此，业务层304包括工作流协调器308和网关集群310。
91.工作流协调器308将业务逻辑(例如由用户指定)装入工作流图(包括工作流节点)中，管理可重复的工作负载，并确保连续处理。具体地，工作流协调器308的动作导致作业提交给网关集群310进行处理，所提交的作业又被划分成一个或多个底层子任务。工作流协调器308的示例包括但不限于tcc、oozie、control
‑
m和azkaban。
92.网关集群310将工作流任务分发到各种底层系统，例如底层系统306。在一些实施例中，网关集群310由工作流协调器308控制。在其它实施例中，网关集群310不由工作流协调器308控制。
93.底层系统306从业务层304接收待处理的工作流任务，并相应地生成其自己的工作负载(即任务的子流，本文通常称为作业)，该工作负载被分发到可用的计算节点以执行。底层系统306可以包括具备qos特征的系统(本文称为控制系统)和不受控制的系统(本文称为不受控系统)，这种不受控系统最好被建模为不需要资源，下文进一步论述。控制系统的示例包括但不限于apache spark框架上的本机独立spark集群管理器、基于hadoop资源管理框架(yet another resource negotiator，yarn)的数据处理应用程序。不受控系统的示例包括但不限于传统数据库、数据传输服务和文件系统操作。
94.如图所示，底层系统306包括作业提交器312和资源管理器314。
95.作业提交器312将作业和已分配资源池520的标识符提交给资源管理器314，所提交的作业由工作流协调器308执行的一个或多个动作产生。截止日期通常以工作流级定义，这样又对一些作业提出了严格的sla要求(即严格的完成截止日期)。
96.作业提交器312的示例包括但不限于hive、pig、oracle、teradata、文件传输协议(file transfer protocol，ftp)、安全外壳(secure shell，ssh)、hbase和hadoop分布式文件系统(hadoop distributed file system，hdfs)。
97.资源管理器314接收由作业提交器312提交的作业和已分配资源池520的标识符，并根据与已分配资源池520相关联的资源，将已提交作业分发到可用的计算节点上。因此，
资源管理器314执行由sla计划单元302对实际工作负载作出的系统资源分配决策，从而使任务运行得更快或更慢。本文提到的系统资源包括但不限于中央处理单元(central processing unit，cpu)利用率、随机存取存储器(random access memory，ram)利用率和网络带宽利用率。
98.应当理解的是，资源管理器314可以是任何能够实现qos实施方案的底层系统。因此，资源管理器314可以包括但不限于调度器(例如yarn、mesos、平台分布资源管理系统(load sharing facility，lsf)、gridengine、kubernetes等)和具备执行qos的功能的数据仓库系统(例如关系型数据库管理系统(relational database management system，rdbms)等)。
99.如下文进一步论述，sla计划单元302是任何与业务层304和底层系统306连接的实体，以确保计算工作流内的作业按照用户规定的规范和/或要求完成(即满足高层工作流的截止日期和sla)。为此，sla计划单元302确定系统资源的调整方式。具体地，为了确保业务层级处的关键工作流满足其截止日期和sla，sla计划单元302在任务提交之前选择资源以分配给不同任务，从而根据时间为各个任务形成资源分配计划。资源分配计划针对每个任务标识该任务在哪个时间段需要哪些资源。当从作业提交器312接收到一个任务(或作业)时，sla计划单元302参考资源分配计划，该计划用于标识该作业需要的资源，然后标识能够满足这些资源的资源池。作业提交器312在接收到为任务分配的资源池之后，将任务和分配好的资源池发送给资源管理器314，以对实际提交的工作负载执行。公平调度器是资源管理器314的一部分，进行上述执行动作，从而有效地确保资源按计划划分。这样，有可能实现一项任务在运行时得到计划好的资源量。还有可能通过sla计划单元302在提交任务时与业务层304进行通信，实现一项任务按计划运行。sla计划单元302还可以保留任务以在适当时提交。sla计划单元302还可以将任务提交到这些任务分配到的资源池，而不管是否是这些任务运行的合适时间。资源分配计划可以防止多个任务同时运行在同一资源池中。
100.图4示出了使用公平调度器(例如在根据公平共享策略调度的“fair”模式下操作的yarn和apache spark调度器)的资源实施的一个示例的概述。资源池520已经预定义好，每个资源池都有自己的权重。如图4所示，这样的资源池520可以是“根”的一部分或位于“根”的内部，“根”可以表示资源池520的最高目录。在操作期间，调度器会根据资源池的权重动态地将资源分配给作业。每个“作业”(例如，图4所示的“作业1”、“作业2”和“作业3”)可以与qos标识符相关联。如下文进一步详述，sla qos标识符生成模块402为给定工作流节点的每个子任务生成唯一的qos标识符。工作流节点可以表示待进行的作业单元，并且可以称为“节点”以标识该节点是业务层304的工作流图的一部分。在一些实施例中，工作流图的两个部分可以包括节点(顶点)和依赖关系(边)。图9示出了工作流节点702的一个示例，如下文详述。
101.如图4所示，将每个作业提交到一个资源池(或“队列”)，每个资源池都有一个权重(或“优先级”)。调度器根据权重公平地将资源分配给资源池520。在一个资源池内，资源通常根据fair或fifo策略进行划分。根据fair调度策略，各个作业根据时间平均得到相等的资源份额。fifo调度策略采用先进先出的方式，各个作业按到达顺序进行处理。
102.图4示出了将“作业1”分配给权重为“50”的资源池520“a”，将“作业2”和“作业3”分配给权重为“50”的资源池520“b”。资源池分配可以由资源池分配模块407(下文进一步论
述)根据每个作业的qos标识符来执行。如利用率与时间对照图所示，资源(“利用率”)以相等权重“50”均分在资源池(“队列”)520“a”和“b”之间。在提交“作业1”时且在提交“作业2”和“作业3”之前的时间处，“a”和“b”中的资源均可用。在提交“作业2”时，资源50/50均分在“作业1”和“作业2”之间，具体取决于资源池“a”和“b”的相对权重。当提交“作业3”且“作业2”仍在运行时，资源池“b”内的资源根据资源池内的公平调度均分在“作业2”和“作业3”之间。一旦“作业2”完成，资源池“b”中的全部资源就由“作业3”使用。
103.应当理解的是，尽管sla计划单元302在此被示出和描述为与单个工作流协调器308连接，但sla计划单元302可以同时与多个工作流协调器连接。还应当理解的是，尽管sla计划单元302在此被示出和描述为与单个底层系统306连接，但sla计划单元302可以同时与多个底层系统连接。
104.图5示出了sla计划单元302的一个示例性实施例。sla计划单元302包括资源池预创建模块401、sla qos标识符生成模块402、资源需求分配模块404、计划框架模块406、资源池分配模块407和执行监控模块408。作业提交器312包括作业提交客户端410，作业提交客户端410又包括qos标识符生成模块412和资源池标识符模块413。
105.如下文进一步详述，sla计划单元302中提供的资源池预创建模块401，对于用于划分集群中的给定的资源数量，运行资源划分算法以定义资源池520。定义好的资源池520是包括资源150的分区。在运行工作流之前，底层系统306的资源管理器314通过资源划分用定义好的资源池进行初始化。
106.如下文进一步详述，sla计划单元302中提供的sla qos标识符生成模块402发现每个工作流节点的底层系统(例如yarn)作业，这些作业在本文中称为子任务，这些子任务与节点相关联并由底层系统作业提交器312提交。sla计划单元302还发现底层子任务之间的依赖关系。然后，sla qos标识符生成模块402为给定节点的每个子任务生成唯一的qos标识符。
107.作业提交客户端410中提供的qos标识符生成模块412运行补充流程，该补充流程生成的qos标识符与sla qos标识符生成模块402为计划内工作流节点生成的qos标识符相同。本文所使用的术语“qos标识符”是指可控系统的用户用来参考已经分配到的qos水平的凭证。
108.作业提交客户端410中提供的资源池标识符模块413使用qos标识符来检索已分配资源池。在一些实施例中，还检索提交时间，从而定义将作业提交给调度器资源池的时间。提交时间可以定义为计划内作业开始时间。
109.资源需求分配模块404为给定节点的每个子任务确定并分配资源需求，计划框架模块406相应地为具有资源需求和qos标识符的每个子任务生成资源分配计划。本文所使用的术语“资源需求”是指在底层系统306中完成作业所需的系统资源的总数量以及总数量的资源可以在资源和时间维度划分得到的数量。术语“资源分配计划”是指所需系统资源根据分布的方式。
110.资源池分配模块407在从作业提交器312接收作业的qos标识符时，从定义好的资源池中为该qos标识符确定和分配资源池。
111.根据作业的资源分配，从定义好的资源池520中为该作业选择资源池520，这种资源分配表示计算集群中为执行作业而分配的计算资源的数量。然后，将所选择的资源池520
发送给作业提交器。
112.执行监控模块408在工作流协调和底层系统级处监控工作负载的实际进度，并将进度信息报告给计划框架模块406和资源池分配模块407。通过进度信息，计划框架模块406根据需要动态地调整先前生成的资源分配计划，以确保满足最高截止日期和sla。
113.现在参考图6，示出了图5的sla计划单元中提供的资源池预创建模块的框图。资源池预创建模块401包括资源发现模块502和资源池生成器模块504，资源池生成器模块504还可以包括标识符模块506和权重分配模块508。
114.资源发现模块502标识分布式计算系统100内或分布式计算系统100的计算集群内的资源150。资源池生成器模块504接收所标识的资源以定义资源池520。标识符模块506将资源池标识符分配给每个资源池，权重分配模块508根据与该资源池相关联的计算资源的数量将权重分配给每个资源池520。
115.为了定义资源池520，当完整资源被划分为多个资源池时，对分布式计算系统100内标识的资源进行划分。同时，资源池520定义所有可用资源150或者定义可用资源的子集或计算集群。执行不同的作业，以使用不同的资源池520。
116.因此，在调度之前，预创建资源池520以支持所有可能的资源分区等。定义好的资源池可以与计算集群中的计算资源的总数量相关联。
117.将定义好的资源池520发送给底层系统306的资源管理器314，以使用定义好的资源池进行初始化。
118.在一个示例中，在不失一般性的情况下，具有5个核的资源集群可以通过预创建5个相等权重的资源池(权重等于1)，支持并行运行的5个1核作业。或者，计算集群可以通过预创建权重为1、2和2的合适资源池，支持1个1核作业和2个2核作业。为支持任意组合的资源共享而需要预创建的资源池的总数量随着“除数和型函数(divisor summatory function)”增加，并且可扩展到非常多的资源(例如，10000个核，需要93668个不同的资源池)。为了利用预创建的资源池，进行如下所述的资源计划，然后将新作业动态地提交到与计划作业要使用的资源的数量对应的资源池。公平调度器本身进行上述执行动作，从而有效地确保资源按计划划分。
119.在一个示例中，可用资源可以是作业可以使用的一组核，例如包括32个核的集群。将32个核划分得到的部分或资源池520可以是2个资源池520，一个具有2个核，另一个具有30个核。在2核资源池中运行的作业比在30核资源池520中运行的作业具有更少的资源。在可选方案中，将32个核划分可以得到3个资源池520，每个资源池具有10个核。在另一个示例中，将6个核划分得到的资源池520可以是“1”和“5”，或“2”和“4”，或“3”、“1”和“2”，或“1”、“1”、“1”，“1”、“1”和“1”，或其它合适设置。
120.在一个示例中，权重分配模块508在将权重分配给每个资源池520时，将资源池的“权重”设置为资源池中的核的数量。为了区分相同权重的资源池，标识符模块506可以对这些资源池进行索引。在一个示例中，资源池520可以根据资源池权重和索引号来标识。在一个示例中，权重为“1”的3个资源池(例如，1核资源池)可以标识如下：1#1、1#2、1#3。也可以使用其它逻辑上等效的标识符。
121.此处使用的“权重”可以理解为在使用公平调度器时用于资源实施的公平调度权重。在操作期间，公平调度器会根据已分配资源池520的权重动态地将资源分配给作业。许
多调度器(包括yarn和apache spark调度器)都存在“fair”模式，在这种模式下，这些调度器根据公平调度策略进行调度。在资源池520内，资源通常根据fair或fifo策略进行划分。资源池520的权重可以根据与资源池关联的计算资源的数量相对于计算集群中的计算资源的总数量的比例来确定。
122.划分和预定义，例如6个1核资源池，可以标识为1#1、1#2、1#3、1#4、1#5和1#6。在使用中，作业可以同时在每个资源池520中运行，使得每个作业根据公平共享策略使用6个核中的一个。
123.在上面的示例中，可以使用6个1核资源池520。然而，在其它分区中，可能不需要所有6个1核资源池520。实际上发生的6个核的其它可能划分方式包括最多3个2核资源池520(2#1、2#2和2#3)，最多2个3核资源池520(3#1和3#2)，最多1个4核资源池520(4#1)，最多1个5核资源池520(5#1)和最多1个6核资源池520(6#1)。在1个6核资源池520的情况下，整个资源集群将由一个作业使用，因为该资源池跨越资源中的所有核。6核情况下的完整资源池定义包括定义所有资源池及其所有关联权重，以涵盖所有可能的资源划分方式。图7示出了一个示例。
124.图7示出了资源池预创建模块401通过资源池预创建进行的资源划分。在底层系统306中的调度器启动之前，创建资源池520以支持资源150的所有可能分区。在图7所示的示例中，资源150的集群具有5个核。预创建资源池520以能够使用包括5个核的所有分区。通过这些资源池520，将作业提交到资源池1#1、1#2、1#3、1#4和1#5可以支持并行运行的5个1核作业(1、1、1、1、1)，或将作业提交到资源池1#1、2#1和2#2可以支持1个1核作业和2个2核作业(1、2、2)，以此类推，最多支持7种可能组合。一组预创建资源池定义资源池520。
125.现在参考图8，sla qos标识符生成模块402包括子任务发现模块602，子任务发现模块602可以包括一个或多个子模块604a、604b、604c等。sla qos标识符生成模块402还包括标识符生成模块606。sla qos标识符生成模块402从工作流协调器308接收输入数据，该输入数据进行处理以生成具有qos标识符的工作流图。该输入数据可以由工作流协调器308推送或由sla计划单元302拉取。该输入数据指示要计划的工作流节点的数量、工作流节点之间的依赖关系以及每个工作流节点的元数据。元数据包括但不限于每个节点的标识符(w)、节点的截止日期或最早开始时间以及节点在网关集群310上执行的命令。在一些实施例中，元数据包括节点的资源需求估计。然后，输入数据由子任务发现模块602处理，以标识与每个工作流节点相关联的底层子任务。
126.子任务发现模块602使用各种技术标识给定工作流节点的底层子任务，这些技术分别由对应的子模块604a、604b、604c等实现。在一个实施例中，句法分析模块604a用于从句法上分析由节点执行的命令，以标识影响底层系统306操作的命令。然后，句法分析模块604a依次将编号(n)分配给每个命令。这在图9中示出，图9示出了句法分析模块604a执行的子任务发现流程700a的一个示例。在子任务发现流程700a中，标识符(w)为20589341的工作流节点702执行一组命令704。将命令704发送给解析器706(例如hive中的查询计划器)，解析器706输出一组查询q1、q2等，然后将这些查询封装到合适的命令(例如来自hive的explain命令)7081、7082、7083，以发现对应的底层子任务7101、7102、7103。然后，将底层子任务从1排序到j+1。
127.在另一个实施例中，为了标识给定工作流节点的底层子任务，使用子任务预测模
块604b。子任务预测模块604b使用机器学习、预测或其它合适的统计或分析技术来检查给定工作流节点的历史运行信息。根据历史运行信息，子任务预测模块604b预测节点要执行的子任务，并将编号(n)分配给每个子任务。这在图9中示出，图9示出了子任务预测模块604b执行的子任务发现流程700b的一个示例。在流程700b中，子任务预测模块604b检查工作流节点历史信息712，工作流节点历史信息712包括标识符(w)为20589341的工作流节点702执行的一组过去作业714。然后，预测器716用于预测工作流节点702要执行的底层子任务7181、7182、7183。通过流程700b(即通过子任务预测模块604b)发现的基底层子任务7181、7182、7183与通过子任务发现流程700a(即通过句法分析模块604a)发现的底层子任务7101、7102、7103相同。然而，应当理解的是，除句法分析和预测之外，还有各种技术可以用于发现每个工作流节点的底层子任务(如模块604c所示)。例如，用户可以提供关于底层子任务的猜测，而且sla qos标识符生成模块402可以接收该信息作为输入。其它实施例同理。
128.如图9所示，对于任何给定的工作流节点，底层子任务包括受控子任务(7101、7102或7181、7182)，这些子任务与依赖的qos计划内作业相关联。底层子任务还包括不受控子任务(7103或7183)，这些子任务与不受控的工作流节点(也称为不透明或模糊工作流)相关联。不受控子任务可以在业务层304处创建，但在底层系统306中未分配资源。然而，由于受控子任务可能依赖于不受控子任务，因此不受控子任务是包括在sla计划单元302生成的资源分配计划中。如下文进一步所述，sla计划单元302仅按不受控作业的持续时间对其进行建模，并不分配资源给不受控作业。以这种方式，即使资源可用于依赖于不受控子任务的作业，依赖作业也需要等待持续时间结束才能开始。
129.一旦发现给定工作流节点的底层子任务，标识符生成模块606就为每个子任务生成和分配唯一的qos标识符，子任务包括不受控子任务。在一个实施例中，对(w，n)用作qos标识符，包括每个节点的标识符(w)和分配给该节点的每个底层子任务的编号(n)。这在图9中示出，图9示出了在子任务发现流程700a和700b中，qos标识符720生成为包括节点标识符20589341和子任务编号(1
……
j+1)的一个对。然后，标识符生成模块606输出一个工作流节点图，包括为每个工作流节点生成的qos标识符。具体地，通过生成由子任务发现模块602标识的底层子任务之间的依赖关系，标识符生成模块606扩展工作流协调器308提供的工作流图。
130.如上所述且如图10所示，作业提交客户端410中提供的qos标识符生成模块412实现流程800，以重复由sla qos标识符生成模块402实现的qos标识符生成流程。qos标识符生成模块412相应地为已提交作业生成qos标识符，这些已提交作业与给定工作流节点802(标识符(w)为20589341)相关联。在示例性流程800中，将节点802的命令804发送到hive查询分析器806，hive查询分析器806输出查询q1和q2，查询q1和q2又分别被执行，得到为两个查询提交的两组作业8081(编号从1到i)、8082(编号从i+1至j)。然后，通过以下方式生成qos标识符810：观察已提交作业的顺序(例如计数)，确定每个已提交作业的数量(n，在图10中，n＝1
……
j)，并使用对(w，n)作为qos标识符。容易理解的是，作业提交客户端410中提供的qos标识符生成模块412只为受控作业提供qos标识符，而不考虑不受控作业。还将理解的是，qos标识符生成模块412生成qos标识符810，qos标识符810与sla qos标识符生成模块402为受控作业(1
……
j)生成的qos标识符720相同。一旦生成了qos标识符810，资源池标识符模块413使用qos标识符810来获取分配给特定qos标识符810的资源池520，并且将qos标识符
810和资源池520的标识符附加到提交给资源管理器314的工作负载中，下文进一步详述。
131.现在参考图11，资源需求分配模块404包括资源需求确定模块902，资源需求确定模块902可以包括一个或多个子模块904a、904b、904c、904d等。具体地，资源需求分配模块404使用各种技术为每个子任务确定资源需求，这些技术分别由子模块904a、904b、904c、904d等中的对应一个实现。资源需求分配模块204还包括预留定义语言(reservation definition language，rdl)描述生成模块906。资源需求分配模块404从sla qos标识符生成模块402接收工作流节点图，每个工作流节点的元数据包括为该节点生成的qos标识符。在一些实施例中，元数据包括用户使用适当的输入模块为节点提供的整体资源需求估计。在这种情况下，资源需求确定模块902使用人工估计模块904a在节点的底层子任务之间均匀分配整体资源需求估计。
132.在没有提供资源需求估计的实施例中，资源需求确定模块902使用资源需求预测模块904b来获取节点的过去执行历史信息，并相应地预测每个子任务的资源需求。在其它实施例中，资源需求确定模块902使用子任务抢占执行模块904c在预定时间段内抢占执行每个子任务。在预定时间段结束时，子任务抢占执行模块904c调用“kill”命令以终止子任务。在终止子任务时，子任务抢占执行模块904c获取子任务的当前资源利用率的样本，并使用资源利用率样本对该子任务的整体资源需求进行建模。对于被sla qos标识符生成模块402标记为不受控制的子任务，资源需求确定模块902将资源需求的资源利用率维度设置为0，并且只分配持续时间。应当理解的是，为了给每个子任务确定和分配资源需求，除资源需求人工估计、资源需求预测和子任务抢占执行之外，还可以使用其它技术(如模块904d所示)。
133.然后，rdl描述生成模块906输出要计划的整个工作流的rdl描述。rdl描述以工作流图的形式提供，该工作流图规定了每个子任务的总资源需求(即完成子任务所需的系统资源的总数量，通常表示为兆字节的内存和cpu份额)以及每个子任务的持续时间。rdl描述进一步规定，不受控子任务只有持续时间，而且该持续时间必须在依赖任务能够计划好之前结束。以这种方式，如上所述，一些工作流节点可能不需要底层计算集群中的资源，但有一个持续时间，该持续时间需要在依赖作业能够运行之前结束。
134.现在参考图12，计划框架模块406包括资源分配计划生成模块1002，资源分配计划生成模块1002包括顺序选择模块1004、形状选择模块1006和位置选择模块1008。计划框架模块406还包括错过截止日期检测模块1010和执行信息接收模块1012。计划框架模块406从资源需求分配模块404接收工作流节点图(例如rdl描述)和每个工作流节点的元数据。元数据包括sla qos标识符生成模块402为每个工作流节点生成的qos标识符、资源需求分配模块404为该节点分配的资源需求以及底层系统的容量(例如用户使用适当的输入模块提供)。在一些实施例中，元数据包括每个工作流节点的截止日期或最小开始时间(例如用户使用适当的输入模块提供)。
135.然后，计划框架模块406使用资源分配计划生成模块1002针对rdl图中的每个工作流节点，为该节点的每个子任务生成资源分配计划。资源分配计划规定了子任务所需的资源根据时间的分布方式，从而指示工作流节点对应的qos水平。顺序选择模块1004选择为每个子任务指定资源分配的顺序。形状选择模块1006为每个子任务选择一个形状(即根据时间的资源分配)。位置选择模块1008为每个子任务选择一个位置(即开始时间)。在一个实施
例中，顺序选择模块1004、形状选择模块1006和位置选择模块1008全部都启发式地选择顺序、形状和位置。在另一个实施例中，顺序选择模块1004、形状选择模块1006和位置选择模块1008全部都以优化目标函数为目的选择顺序、形状和位置。在又一个实施例中，顺序选择模块1004、形状选择模块1006和位置选择模块1008全部都随机地选择顺序、形状和位置。在又一个实施例中，位于工作流的关键路径上、截至日期早的作业在不太关键的作业(例如属于工作流的一部分、截止日期不太紧张的作业)之前，进行顺序、形状和位置选择。还应理解的是，顺序选择模块1004、形状选择模块1006和位置选择模块1008可以按不同的顺序操作，例如形状选择发生在顺序选择之前。此外，不同模块可以通过交织或迭代的方式操作。
136.如上所述，在一些实施例中，每个工作流节点的截止日期或最小开始时间作为计划框架模块406的输入。在这种情况下，对于每个工作流节点，错过截止日期检测模块1010判断是否有任何子任务违反了其截止日期或最小开始时间。然后，错过截止日期检测模块1010返回未满足截止日期的一列子任务。
137.错过截止日期检测模块1010还将与每个子任务相关联的资源分配计划和服务质量标识符输出到资源池分配模块407。
138.应当理解的是，sla计划单元302可以管理单个工作流协调器308或底层系统实例(例如为了实现多租户支持)内的多个资源分配计划。还应当理解的是，sla计划单元302还可以将资源分配计划提供给工作流协调器308。在这种情况下，sla计划单元302可以将资源分配计划推送给工作流协调器308。资源分配计划也可以由工作流协调器308拉取。对于每个工作流节点，工作流协调器308这时可以使用资源分配计划来跟踪每个子任务的计划内开始时间，或者等待计划内开始时间到来才提交工作流。
139.图13为资源池分配模块407的框图。资源池分配模块407等待qos标识符与关联到计划内工作流节点的qos标识符相同的作业被提交(根据资源分配计划)。
140.资源池分配模块407充当簿记，以在任何时刻跟踪正在使用的预期权重的资源池520，以便新作业能够始终进入适当权重的未用资源池中。资源池分配模块407以qos标识符作为输入，在资源分配计划中查找其请求的资源大小，接着找到能够满足资源需求的资源池520，然后返回对应资源池520的标识符作为输出。
141.资源分配计划接收模块1020从计划框架模块406接收资源分配计划信息。qos标识符接收模块1022从资源池标识符模块413接收资源池分配到的作业的qos标识符。
142.然后，资源池分配模块407确定可用资源池。接收模块1025从预创建模块401接收定义好的资源池520。执行信息接收模块从执行监控模块408接收执行信息。这样，可用资源池确定模块1024可以维护未在使用的可用资源池的记录。资源池分配模块407还可以根据从执行监控模块408接收到的数据来更新可用资源池的记录。
143.然后，资源池查找模块1028标识可用资源池以满足资源分配计划所规定的需求。在一些实施例中，所选择的资源池520与未分配给另一作业的计算资源的数量相关联。
144.然后，资源池分配模块407将已分配资源池520的标识符发送给作业提交器312的资源池标识符模块413。
145.在一些实施例中，在将所选择的资源池520发送给作业提交者312之后，资源池分配模块407指示所选择的资源池不可用于选择。在从执行监控模块408接收到作业执行完成的通知之后后，资源池分配模块指示所选择的资源池可用于选择。
146.这样，由qos标识符标识的每个作业被分配给资源池520。逻辑上，每个资源池520可以由与唯一权重和权重索引对应的标识符来标识，格式可以为“pool_weight#index”等。当每个作业在集群中完成时，如执行监视模块408所指示，可用资源池的记录被更新。
147.在资源池分配的一个示例中，资源池接收模块1025可以用定义好的资源池520进行初始化。对于每个权重，可以创建包括该权重的所有可用资源池520的一个列表。例如，共有8个资源，权重为“2”的可用资源池可以标识为[2#1、2#2、2#3、2#4]。堆栈或队列可以用作标识这些可用资源池的结构，并可以实现快速插入和检索/删除。
[0148]
图14示出了计划框架模块406的资源分配计划生成模块1002生成的资源分配计划的一个示例。每个形状表示当前子任务(或“作业”)“j”根据时间的资源分配(“计划内高度”)和持续时间，如图14所示。图14示出了标识为“j1”到“j10”的10个作业。虽然图14使用矩形示出了为每个作业计划好的形状，但应当该理解的是，实际上可以使用其它形状。
[0149]
图15示出了图14的包括资源池分配的资源分配计划。对于每个子任务，在该子任务开始运行之前，从资源分配计划中检索权重，并从对应的队列中检索可用资源池，例如“pool_id＝available_pools[w].dequeue”。图15示出了示例性资源池分配，例如“资源池1#1”。当每个子任务完成运行时，已完成子任务的pool_id将添加回可用资源池列表中，例如“available_pools[w].enqueue(pool_id)”。
[0150]
根据需要和当前资源分配计划(不依赖于来自执行监控模块的子任务状态信息)，这种资源池分配可以在线执行(因为子任务实时开始或结束，并且从执行监控模块接收到子任务状态信息)，也可以逻辑上“向前”运行。在线执行资源池分配可以适应比预期早或晚完成的子任务。
[0151]
图16为资源池标识符模块413的框图。资源池id检索模块1032将qos标识符发送给资源池分配模块407，并接收该qos标识符的资源池标识符。
[0152]
然后，qos id和资源池id传输模块1034将qos标识符及其相关联的资源池标识符发送给底层系统306的资源管理器314。
[0153]
在一些实施例中，资源池标识符模块413可以从资源池分配模块407中检索qos标识符的开始时间。在其它实施例中，开始时间可以从计划框架模块406中检索。计划内开始时间也可以是可选的。使用计划内开始时间可以提高资源在分布式计算系统100中的使用效率。如果调度器用于在资源池内使用先进先出策略，则计划内开始时间可能不需要精确定时。
[0154]
qos标识符810和已分配资源池520标识符被附加到提交给资源管理器314的工作负载中。
[0155]
图17示出了通过公平调度器实施图15所示的资源池定义的一个示例(图17中省略了资源池标识符)。给定资源池定义之后，调度器实施资源池中的子任务得到它们在集群资源的份额。作业被提交到其分配到的资源池，公平调度器确保作业至少得到其分配到的资源份额。
[0156]
如图17所示，当资源已经挤满(100％利用率)时，公平调度器和资源池权重可以保证子任务得到为其计划分配到的资源份额。当资源未挤满时，作业将按其资源池权重的比例公平地共用自由资源。
[0157]
现在参考图18，执行监控模块408用于监控工作流协调和底层系统级处的实际工
作负载进度。为此，执行监控模块408包括执行信息获取模块1102，执行信息获取模块1102从工作流协调器308和资源管理器314获取执行状态信息。在一个实施例中，执行信息获取模块1102从工作流协调器308和资源管理器314中检索(例如拉取)执行信息。在另一个实施例中，工作流协调器308和资源管理器314将执行信息发送(例如推送)给执行信息获取模块1102。从工作流协调器308获取到的执行状态信息包括关于最高工作流节点执行的信息，包括但不限于实际开始时间、实际完成时间、正常终止时间和异常终止时间。从资源管理器314获取到的执行状态信息包括关于底层系统作业的信息，包括但不限于实际开始时间、实际完成时间、完成百分比和实际资源需求。
[0158]
一旦执行监控模块408确定了实际工作负载进度，执行信息获取模块1102就将执行信息发送给计划框架模块406。然后，计划框架模块406的执行信息接收模块1012接收执行信息，并将执行信息发送给资源分配计划生成模块1002，这样可以相应地调整一个或多个现有资源分配计划。在资源需求分配模块404错误地确定原始资源需求的情况下，可能需要调整。例如，子任务需求预测不正确可能会导致原始资源需求的确定不正确。用户输入不准确(例如提供了不正确的资源需求估计)也可能导致资源需求的确定不正确。
[0159]
当确定需要调整时，资源分配计划生成模块1002根据实际资源需求为一个或多个先前计划内作业调整资源分配计划。调整可以包括重新计划所有子任务或重新计划各个子任务，以在本地按计划进行。例如，调整可以包括提高下游作业分配。以这种方式，即使在原始资源需求计划不正确的情况下，使用执行监控模块408也可以满足最高sla。
[0160]
在一个实施例中，在确定需要调整一个或多个资源分配计划时，资源分配计划生成模块1002评估一个或多个现有资源分配计划中是否存在足够容量以允许对其调整。如果不存在，则资源分配计划生成模块1002输出不能进行调整的指示信息。该信息可以使用适当的输出模块输出给用户。例如，如果资源分配计划生成模块1002确定一些子任务需要比原始计划多的资源，则不可能实现一个或多个资源分配计划的调整。在另一个实施例中，考虑不同工作流的优先级且调整一个或多个资源分配计划，这样即使已经消耗全部容量，也可以完成更高容量的任务。具体地，即使一个或多个资源分配计划中不存在备用容量，在本实施例中，资源分配计划生成模块1002也将资源从一个子任务分配到另一个更高容量的子任务。在又一个实施例中，资源分配计划生成模块1002调整一个或多个现有资源分配计划，这样虽然不满足给定sla，但可以满足更多sla。
[0161]
在一些实施例中，可以不改变已提交作业的计划内资源分配，因为改变计划资源分配需要重新分配资源池。在其它实施例中，例如，如果运行作业的运行时间比预期的长，并且调整后的资源分配计划指示该作业应该具有更多的资源，则可以改变该作业的资源池，以给予更多的资源。
[0162]
在确定了实际工作负载进度之后，执行监控模块408的执行信息获取模块1102还将执行信息发送给资源池分配模块407，以更新可用资源池520的记录。资源池分配模块407可以接收作业开始运行的通知，并接收作业完成的通知，以释放已分配资源池520并更新可用资源池的记录。
[0163]
图19为根据一个实施例的用于资源池预创建1200的步骤的流程图。资源池预创建1200是初始化过程，以在运行工作负载的操作之前，通过资源划分用资源池初始化底层系统306。资源池预创建1200由资源池预创建模块401执行。
[0164]
资源池预创建模块401在接收表示分布式计算系统100的计算集群中的计算资源150的总数量的数据时，在资源发现模块502处标识总资源中的资源(步骤1210)。
[0165]
下一个步骤是：根据计算资源150的总数量，在资源池生成器模块504处生成资源池(步骤1220)。每个资源池都与包括在总资源150的一个或多个分区(即资源子集)中的计算资源150的数量相关联。
[0166]
在权重分配模块508处，根据与每个资源池相关联的计算资源的数量，将权重分配给每个资源池(步骤1230)。
[0167]
在标识符模块506处，可以将资源池标识符分配给每个资源池(步骤1240)。
[0168]
在一些实施例中，定义好的资源池被初始化为一列可用资源池，作为可用于分配给子任务的资源，以执行子任务。
[0169]
然后，将定义好的资源池、资源池标识符和权重提交给计算集群的底层系统资源管理器314的调度器(步骤1250)。
[0170]
资源池预创建1200是在作业提交到底层系统306之前由sla计划单元302实现的。
[0171]
现在参考图20，描述了用于生成和更新资源分配计划的示例性方法1300。方法1300是在作业提交到底层系统306之前、在资源池预创建模块401定义好资源池520之后由sla计划单元302实现的。方法1300包括：在步骤1302中，对于每个工作流节点，标识底层子任务和底层子任务之间的依赖关系。然后，在步骤1304中，将唯一的服务质量(quality of service，qos)标识符分配给每个子任务。在步骤1306中，为每个子任务确定总资源需求。在步骤1308中，输出整个工作流的预留定义语言(reservation definition language，rdl)描述，并且在步骤1310中，为rdl描述中的每个节点生成资源分配计划。在步骤1312中，监控工作流协调和底层系统级处的工作负载的实际进度。在步骤1314中，根据实际资源需求，按需要更新一个或多个现有资源分配。然后，将资源分配计划和对应的qos标识符提交给资源池分配模块407(步骤1316)。
[0172]
现在参考图21，在一个实施例中，标识每个工作流节点的底层子任务的步骤1302包括：从句法上分析节点(w)执行的命令，以标识影响底层系统操作的子任务(步骤1402a)。在另一个实施例中，标识每个工作流节点的底层子任务的步骤1302包括：使用机器学习技术来预测节点(w)根据现有运行信息要执行的子任务(步骤1402b)。如上所述，可以使用除句法分析或预测之外的许多技术来发现底层子任务(如步骤1402c所示)。例如，尽管图21未示出，但步骤1302可以包括接收用户提供的关于底层子任务的预测。其它实施例同理。接着，将qos标识符分配给每个子任务的步骤1304包括：将编号(n)依次分配(步骤1404)给每个先前标识的子任务(包括不受控子任务)。然后，将对(w，n)用作当前节点的qos标识符(步骤1406)。
[0173]
参考图22，在一个实施例中，步骤1306包括：在步骤1502中，在每个节点的子任务之间均匀分配整体人工估计，例如通过用户输入接收到的人工估计。在另一个实施例中，在步骤1504中，使用机器学习根据过去执行历史信息，预测每个子任务的资源需求。在又一个实施例中，在预定时间段内抢占执行每个任务(步骤1506)。这时终止该子任务，并在步骤1508中，获取子任务的当前资源利用率的样本。然后，在步骤1510中，使用当前资源利用率样本对子任务的整体资源需求进行建模。其它实施例可以适用于为每个子任务确定总资源需求(如步骤1512所示)。然后，在步骤1514中，评估在qos标识符生成过程中是否已经标记
任何不受控子任务(图20的步骤1302和步骤1304)。如果否，则方法1300前进到下一步骤1308。否则，在步骤1516中，将一个或多个不受控子任务的资源需求的利用率维度设置为0，并且仅将持续时间分配给一个或多个不受控子任务。
[0174]
现在参考图23，生成资源分配计划的步骤1310包括：在步骤1602中，选择将资源分配指定给每个子任务的顺序。一旦选择好顺序，在步骤1604中，获取下一个子任务。接着，在步骤1606中，设置当前子任务根据时间(即形状)的资源分配和持续时间。接着，在步骤1608中，设置子任务开始时间(即位置)，并在步骤1610中，将子任务添加到资源分配计划中。然后，在步骤1612中，评估当前子任务是否已经错过截止日期。如果是，则在步骤1614中，将子任务添加到拒绝列表中。否则，在步骤1616中，判断是否仍然存在要指定资源分配的子任务。如果是，则该方法返回步骤1604并获取下一个子任务。否则，在步骤1618中，输出资源分配计划和拒绝列表。
[0175]
如上所述，各种实施例可以适用于选择子任务的顺序、形状和位置。例如，可以启发式、为了优化目标函数或随机地选择顺序、形状和位置。关键作业可以在不太关键的作业之前，进行顺序、形状和位置选择。其它实施例同理。还应当理解的是，步骤1602、步骤1606和步骤1608可以按不同的顺序或通过交织或迭代的方式执行。
[0176]
参考图24，在工作流协调和底层系统级处监控工作负载的实际进度的步骤1012包括：在步骤1702中，检索关于顶层工作流节点执行和底层系统作业的执行信息。然后，在步骤1704中，将检索到的信息发送给计划框架，以产生对一个或多个现有资源分配计划的调整。
[0177]
如图25所示，根据实际资源需求更新一个或多个现有资源分配计划的步骤1314包括：在步骤1802中，接收执行信息；根据接收到的执行信息评估实际资源需求是否与计划内资源需求不同(步骤1804)。如果否，则该方法进入下一步骤，即图20的步骤1316。否则，在一个实施例中，在步骤1806中，评估一个或多个现有资源分配计划中是否存在足够容量以允许对其调整。如果存在，在步骤1808中，根据实际工作负载执行信息和实际资源需求继续调整一个或多个现有资源分配计划。否则，输出不能调整的指示信息(例如给用户，步骤1810)，然后该方法进入步骤1316。如上所述，其它实施例同理。例如，即使一个或多个资源分配计划中不存在备用容量，也可以将一个子任务的资源分配给更高容量的子任务。或者，可以调整一个或多个现有资源分配计划，这样虽然不满足给定sla，但满足了更多sla。
[0178]
现在参考图26，qos标识符生成流程1900在底层系统306处实现，其部分重复了图20的步骤1304。流程1900包括：在步骤1902中，对于每个工作流节点，观察已提交底层系统作业的顺序。然后，在步骤1904中，生成唯一的qos标识符并将其附加到每个已提交作业中。然后，在步骤1906中，将qos标识符输出到资源池标识符模块413，以标识与该作业相关联的资源池，如下参考图28所述。
[0179]
现在参考图27，资源池分配流程2000由sla计划单元302的资源池分配模块407实现。流程2000开始于步骤2010，从底层系统306的作业提交器312接收qos标识符。该qos标识符标识要分配到资源池的作业。
[0180]
然后，在步骤2020中，根据所需资源，参考资源分配计划和可用资源池，选择资源池并将其分配给qos标识符。
[0181]
在步骤2030中，可以更新一列可用资源池。
[0182]
在步骤2040中，将已分配资源池标识符发送给底层系统306的作业提交器312。在一些实施例中，该步骤可以包括将提交时间发送给作业提交器312，指示由qos标识符标识的作业的开始时间。开始时间可以在资源分配计划中指示。
[0183]
现在参考图28，资源池标识流程2100在作业提交器312处实现，以检索qos标识符对应的资源池标识符。资源池标识流程2200发生在作业提交器312处，与sla计划单元302处的资源池分配流程2000同时发生。
[0184]
在步骤2110中，接收qos标识符生成模块412生成的qos标识符。
[0185]
在步骤2120中，将qos标识符发送给sla计划模块302，更具体地说，发送给资源池分配模块407，以在步骤2130中检索特定qos标识符对应的资源池520。还接收资源池520标识符。可选地，还可以接收开始时间。
[0186]
在步骤s2130中，在开始时间等处将qos标识符及其分配到的资源池520标识符发送给资源管理器314中的调度器。
[0187]
因此，资源管理器314在资源池预创建期间接收到定义好的资源池520，能够根据分配给该qos标识符的资源池520将合适的资源分配给子任务。资源管理器314知道哪些资源池，以及特定资源池标识符表示的资源数量，然后作业可以使用指定的资源开始运行。
[0188]
作业开始/完成的通知可以从底层系统306/控制系统发送给sla计划单元302中的执行监视模块408。
[0189]
资源管理器314中的调度器，例如公平调度器，实施资源分配计划中为计划内工作流节点指定的qos水平。以这种方式，可以确保作业能够在指定的截止日期前完成，并根据用户要求满足sla。
[0190]
这样，系统可以实施资源分配计划中为已提交作业指定的qos水平，该作业的qos标识符与关联到计划内工作流节点的qos标识符相同。因此，可以确保在底层系统级处存在的已提交作业达到特定服务水平，从而满足业务工作流sla。
[0191]
资源分配可以在不需要支持动态预留的控制系统(例如底层系统306中的调度器)的情况下进行。
[0192]
通过为所有可能分区预创建资源池，无论资源如何在运行作业之间划分，都可以在任何时刻实施资源计划。
[0193]
参考图29，在一些实施例中，资源150集群可以运行计划外的“临时”作业或子任务。结合上述资源池预创建，可以在定义好的资源池520中定义专用的临时资源池，这样可以保证用于临时作业的资源。当临时作业开始或完成时，其它资源池为了响应可以自动收缩或扩展。在一个示例中，用于计划内作业的资源池520可以构成资源集群的50％，用于临时作业的资源池520可以构成资源集群的50％，如图29所示。作业提交器312因此可以向资源池分配模块407发送计划外作业的作业标识符或qos标识符，并且可以选择用于临时作业的资源池520并将其发送给作业提交器312。
[0194]
在一些实施例中，通过提供多个临时资源池，可以为多个租户或多个用户提供不同的资源保证。
[0195]
在一些实施例中，可以在一天中的不同时间为临时作业或其它作业预留不同量的资源集群。例如，特定作业可以在白天计划。计划器可以在一天中的不同时间计划不同的最大值，用户可以结合一天的不同时间提交合适权重的临时资源池。
[0196]
在不支持资源池重新分配的调度器中，一旦作业开始运行，作业资源池就会固定。但是，在一定程度上，作业开始运行后，可用于作业的资源可能会改变。
[0197]
参考图30和图31，在一些实施例中，可以预定义额外的资源池520具有更高的权重和/或更低的权重，这样运行作业(子任务)可以动态地缩小和/或扩大。通过开始使用一组新的资源池，使用一组现有资源池520的现有作业的权重逻辑上比它们在原始资源分配计划中所具有的权重低/高。
[0198]
图30示出了根据一个实施例的计划运行作业的集体缩小。每个形状表示当前子任务(或“作业”)“j”根据时间的资源分配(“资源”轴)和持续时间(“时间”轴)。图30示出了标识为“j1”到“j11”的10个作业。虽然图30使用矩形示出了为每个作业计划的形状，但应当该理解的是，实际上可以使用其它形状。
[0199]
如图30所示，为了允许集体缩小所有运行作业，可以提前预定义额外的资源池520，这样通过将额外的作业分配给这些资源池(与已经运行作业同时运行)，已经运行作业将会得到较小的资源份额。
[0200]
在图30所示的示例中，可以将作业(“j11”)分配给资源池4'#1，该资源池通过给予权重8，得到4个资源单位。这将使得所有运行作业(“j6”、“j7”和“j8”)得到50％的现有资源。基本上，运行作业逻辑上减少到其以前大小的50％，50％的资源集群现在可用于将“j11”放置在资源池4'#1中，或作为资源池4'#11的子集将“额外”或其它作业放置在“额外”资源池中，例如1'#1、2'#1、3'#1等(每个都具有双倍权重)。
[0201]
这可以使计划器灵活地降低运行作业的重量，以便新作业可以更快运行。
[0202]
在一个示例中，资源池520可以预定义有非常大的权重(例如1000000)，这样所有运行作业都被延迟，直到高优先级资源池中的作业完成。这种方法的一个好处可以是不需要对持续时间和预测进行真正的改变或增强，因为运行作业稍后会进行转换，并且不会在操作中间重新调整大小。
[0203]
转向图31，每个形状表示当前子任务(或“作业”)“j”根据时间的资源分配(“资源”轴)和持续时间(“时间”轴)。图30示出了标识为“j1”到“j5”的5个作业。虽然图31使用矩形示出了为每个作业计划的形状，但应当该理解的是，实际上可以使用其它形状。
[0204]
如图31所示，可以延迟启动作业，以便运行作业可以通过对所有运行作业进行集体扩大来占用更多的集群资源。为了给运行作业提供额外的资源，新作业的调度可能会延迟。一旦运行作业开始完成，其它运行作业将得到适当的资源。这在图31中的一个示例中得到说明，其中新作业的调度被延迟，以允许资源池3#1(作业“j4”)占用整个资源集群。
[0205]
如图31所示，单个资源池520可以定义具有非常高的权重，这会有效地抢占所有运行作业并占用整个资源集群。如果作业突然变得非常重要等，这可能是有利的。
[0206]
在另一个实施例中，额外的资源池520可以预定义为较低权重(例如，运行作业中使用的50％权重的资源池)，然后切换到计划和分配给较低权重的资源池。基本上，运行作业会切换到逻辑上使用其现有资源的两倍资源。
[0207]
参考图32，在一些实施例中，可以省略一定数量的预定义资源池520，如果没有预期权重的资源池可用，则调整计划算法以采取行动(例如，添加依赖关系、重新调整作业大小和重新计划)。图32中的每个形状表示当前子任务(或“作业”)“j”根据时间的资源分配(“资源”轴)和持续时间(“时间”轴)。图32示出了标识为“j1”到“j10”的10个作业。虽然图32
使用矩形示出了为每个作业计划的形状，但应当该理解的是，实际上可以使用其它形状。在图32中，作业“j5”和作业“j1”之间存在依赖关系，这意味着作业“j5”在作业“j1”完成之前无法启动，因为作业“j5”需要一个权重为1的资源池。
[0208]
不太可能需要所有资源池520。例如，在1000个可用资源中，不太可能需要权重为1的第1000个资源池(1#1000)，因为不太可能同时将1000个作业分配给1个核。相反，在一些实施例中，可以执行受限资源池预创建，产生较小资源池的定义。
[0209]
在图32所示的示例中，共有8个资源，资源池可以定义如下：8x1#_：1#1、1#2、1#3
……
1#8；4x2#_：2#1、2#2、2#3、2#4；2x3#_：3#1、3#2；2x4#_：4#1、4#2；1x5#_：5#1；1x6#_：6#1；1x7#_：7#1；1x8#_：8#1。在受限资源池预创建中，资源池1#3
……
1#8、2#3和2#4可以省略。
[0210]
计划器可以考虑在知道受限资源池定义的情况下修改计划。在一个示例中，资源池分配过程可以及时向前运行，以检测可用资源池队列为空的作业。如果没有，则过程可以正常进行。如果可用资源池为空，则可以使用预期大小的资源池在这些作业和较早作业之间添加新的依赖关系，以便有问题的作业在其资源池可用时，在较早作业之后就启动，如图32中作业“j5”和作业“j1”之间的依赖关系中的示例所示。还可以改变作业大小，以便预期大小的资源池可用。考虑到新的依赖关系和/或作业大小，可以重新计划资源。
[0211]
参见图33，每个形状表示当前子任务(或“作业”)“j”根据时间的资源分配(“资源”轴)和持续时间(“时间”轴)。图33示出了标识为“j1”到“j10”的10个作业。虽然图33使用矩形示出了为每个作业计划的形状，但应当该理解的是，实际上可以使用其它形状。可以添加冗余资源池520以处理作业没有完全按照计划启动和停止的情况，需要比实际可用更多的一定大小的资源池。
[0212]
在作业可能不完全按照计划的启动时间的情况下，作业可能会在资源池尚未可用时提前启动。如果作业与运行作业提交到同一资源池，则两个作业都得到资源池中的50％资源。或者，在一些实施例中，可以为每个大小预定义一个或多个“冗余”资源池，并将这些资源池与其它资源池标识符一起添加到可用资源池队列中。当作业提前启动时，资源集群中的所有作业都可以按比例得到较少资源。
[0213]
在8个可用资源的示例中，资源池可以定义为8x1#_：1#1、1#2、1#3
……
1#8；4x2#_：2#1、2#2、2#3、2#4；2x3#_：3#1、3#2；2x4#_：4#1、4#2；1x5#_：5#1；1x6#_：6#1；1x7#_：7#1；1x8#_：8#1。在冗余资源池的实施例中，每个大小的一个额外“冗余”资源池可以是1#9、2#5、3#、4#3、5#2、6#2、7#2和8#2。在图33所示的示例中，在计划时间之前开始的作业(“j10”)可以使用冗余资源池3#3，而不是共用3#1。
[0214]
当然，上述实施例只用于说明，而不是以任何方式限制。所描述的实施例易于进行形式、部件设置、操作细节和顺序的许多修改。本发明旨在包括在其范围内的所有这些修改，如权利要求限定。