CN103491024A - 一种面向流式数据的作业调度方法及装置 - Google Patents

Abstract

本发明涉及一种面向流式数据的作业调度方法，包括以下步骤：调度管理器从调度队列中实时获取待调度作业，根据待调度作业的信息利用有向无环图生成处理单元队列;调度管理器根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点；执行器在启动处理单元时，先在该物理节点上创建一个linux容器，然后在linux容器内部启动处理单元。本发明将处理单元调度到非本地通信数较小、负载较低的物理节点上，可以将需要频繁通信的处理单元集中到同一物理节点，减少了跨物理节点的网络通信。

Description

一种面向流式数据的作业调度方法及装置

技术领域

本发明涉及计算机并行计算领域，特别涉及一种面向流式数据的作业调度方法及装置。

背景技术

近年来，随着实时搜索、广告推荐、社交网络、日志在线分析等应用的不断发展，一种新的数据形态——流式数据正在兴起。流式数据是指一组大量、快速、不间断的事件序列。在不同场景下，流式数据可以是实时查询、用户点击、在线日志、流媒体等多种数据形式。流式应用注重实时交互，过高延时的响应会严重影响其功能或用户体验。由于流式数据的重要性和独特性，一批流式数据处理***应用而生，例如Yahoo！的S4***。

事件是流式数据的基本组成单位，以键-值（key-value）形式出现。处理单元是处理事件的基本单位，有特定的事件类型和键，专门处理具有相应类型和键的事件。处理单元接收流式数据，对其中的事件进行处理，然后输出事件或者直接发布结果。

流式数据处理具有通信流量大、计算量大、响应速度快等特点，对***性能要求较高。在流式数据处理中，处理单元被分布在物理节点上，使用其CPU、内存、网络带宽等物理资源，物理节点过载会直接影响处理单元的性能表现。此外，处理单元需要相互通信、传输流式数据，这将产生网络延时和通信代价。如何根据流式数据的特点，合理地调度处理单元是流式数据处理的关键问题。

现有流式数据处理***未综合考虑处理单元通信和物理节点实时负载，只是保证处理单元在数据量上分布均衡，但是由于不同处理单元对各种资源的需求不同，数量上的均衡并不意味资源使用和实际负载的均衡。而且相互频繁通信的处理单元可能被调度到远程环境，增加其通信代价和延时。现有调度方法不能很好地满足流式数据处理的需求，造成物理节点负载不均、通信延时较高的现象，影响流式数据处理的整体性能。

发明内容

本发明所要解决的技术问题是提供一种通过计算非本地通信数和主导资源比例，并以此为标准对物理节点进行排序，可以将处理单元调度到非本地通信较少、负载较低的物理节点上的面向流式数据的作业调度方法及装置。

本发明解决上述技术问题的技术方案如下：一种面向流式数据的作业调度方法，包括以下步骤：

步骤1：调度管理器从存储待调度作业的调度队列中实时获取待调度作业，并根据待调度作业的信息利用有向无环图生成包括多个处理单元的处理单元队列，所述调度管理器设置于高配置的物理节点上，未设置有调度管理器的其他物理节点上分别设置有一个执行器;

步骤2：调度管理器根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点，每个物理节点上设置有处理单元的数量为零至多个；

步骤3:执行器在启动处理单元时，先在该物理节点上创建一个linux容器，然后在linux容器内部启动处理单元。

本发明的有益效果是：该方法将需要频繁通信的处理单元集中到同一物理节点，减少跨物理节点的网络通信。同时，在通信代价相同或者物理节点负载过高的情况下，该方法会选择负载较低的物理节点进行部署，避免过载现象发生。本发明减少了流式数据处理的通信代价和网络延时，实现了负载均衡，提高了流式数据处理的整体性能。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步，所述步骤1具体包括以下步骤：

步骤1.1：调度管理器根据先入先出原则从存储待调度作业的调度队列中获取待调度作业；

步骤1.2：根据待调度作业的预定的业务需求信息和并发需求信息，将作业分解为以处理单元为顶点、以数据通路为边的有向无环图；

步骤1.3：从有向无环图中选择一个没有入边的顶点，将该没有入边的顶点加入处理单元队列中；

步骤1.4：从有向无环图中删除所述步骤1.3中选择的没有入边的顶点，并删除从该没有入边的顶点发出的所有边；

步骤1.5：判断所述有向无环图中是否还有顶点，如果有则转至步骤1.2；如果没有则结束。

进一步，所述步骤2进一步包括以下步骤：

步骤2.1：计算每个物理节点的非本地通信数和主导资源比例，所述非本地通信数指与当前物理节点上的处理单元进行网络通信的、不在同一物理节点的待调度的处理单元的数量，所述主导资源比例指多种资源需求可用比中最高的资源需求可用比；

步骤2.2：根据非本地通信数和主导资源比例，对物理节点进行排序，得到排序列表，并将列表中的物理节点标记为“未读”；

步骤2.3：从所述排序列表中选择第一个“未读”的物理节点，并将其标记为“已读”；

步骤2.4：判断所述选择的第一个“未读”的物理节点的加权负载值是否小于预定值，如果小于预定值，则将待调度的处理单元放置于该物理节点上，结束；

步骤2.5：所述排序列表中是否还有“未读”的物理节点，如果有则转至步骤2.3；如果没有，则选择排序列表中的第一个物理节点。

进一步，计算物理节点的非本地通信数时进一步包括：

将非本地通信数初始化为0；

假设当前物理节点上的处理单元已经调度到该物理节点，然后遍历所有已经完成调度的处理单元；

如果一个处理单元与待调度的处理单元需要通信、且两个处理单元不在同一物理节点上，则当前的非本地通信数加一，最后得到非本地通信数。

进一步，所述主导资源比例的计算方法具体为：

计算该物理节点每种资源的资源需求可用比，所述资源需求可用比是处理单元的资源需求量与物理节点的资源可用量的比例；

选择多种资源需求可用比中最高的一个即为该物理节点的主导资源比例。

进一步，所述步骤2.2中，根据非本地通信数和主导资源比例，对物理节点从小到大排序具体包括以下步骤：

两个物理节点先比较非本地通信数，如果不等，则非本地通信数小的物理节点排在前面；如果相等，再比较二者的主导资源比例，主导资源比例小的物理节点排在前面。

进一步，所述加权负载值的具体计算方法为：

加权负载值=CPU利用率*0.3+内存利用率*0.3+网络带宽利用率*0.4。

进一步，一种面向流式数据的作业调度装置，包括调度管理器，执行器和调度队列；

所述调度管理器，设置于高配置的物理节点上，用于从调度队列中实时获取待调度作业，并根据待调度作业的信息利用有向无环图生成包括多个处理单元的处理单元队列，根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点，每个物理节点设置有至少一个处理单元；

所述执行器，用于启动处理单元，将调度管理器调度给该物理节点的处理单元放置于linux容器内部，在linux容器内部启动处理单元；

所述调度队列，与调度管理器部署在同一物理节点上，用于存储待调度作业。

进一步，所述调度管理器包括收集模块和调度模块；

所述收集模块，用于收集每个执行器所在物理节点的IP地址、通信端口、每种资源的总量及可用量，执行器资源使用状况及处理单元的资源使用状况；

所述调度模块，用于从调度队列中获取待调度作业，并根据待调度作业的信息生成包括多个处理单元的处理单元队列，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别调度给对应的物理节点。

进一步，每个所述处理单元均设置有唯一的处理单元标识。

附图说明

图1为本发明方法步骤流程图；

图2为本发明生成处理单元队列的流程图；

图3为本发明处理单元有向无环图的示意图；

图4为本发明处理单元有向无环图变化的示意图；

图5为本发明处理单元调度方法的流程图；

图6为部署处理单元的流程图；

图7为本发明装置结构图。

附图中，各标号所代表的部件列表如下：

1、调度管理器，2、执行器，3、调度队列。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

如图1所示，为本发明方法步骤流程图；图2为本发明生成处理单元队列的流程图；图3为本发明处理单元有向无环图的示意图；图4为本发明处理单元有向无环图变化的示意图；图5为本发明处理单元调度方法的流程图；图6为部署处理单元的流程图；图7为本发明装置结构图。

实施例1

本发明实施例实现了一个流式数据处理***，该***包括多个执行器和一个调度管理器。其中执行器是运行于物理节点上的守护进程，除调度管理器所在的物理节点以外，***管理的每个物理节点上都运行着一个执行器。

执行器可以在该物理节点上启动和关闭处理单元。启动处理单元时，执行器将先在物理节点上创建一个指定资源容量的Linux容器，然后在Linux容器内部启动处理单元需要执行的任务。处理单元与Linux容器一一对应，每个处理单元都放置在一个Linux容器之中。Linux容器可以为其中的进程分配指定资源，由于流式数据处理模型通常伴以高流量通信，所以本***分配的资源类型比较全面，包括CPU、内存、网络带宽等。这样，每个处理单元都在Linux容器内部，使用***分配的指定资源，相互独立运行，实现了资源隔离，避免了资源竞争，提升了处理单元的整体性能和运行稳定性。

同时，执行器还用于监控处理单元的运行状态和资源使用状况，由于每个Linux容器内部只有一个处理单元，因此监控处理单元可以转化为监控Linux容器的资源使用状况。执行器定时向调度管理器的收集模块发送心跳。每次需要发送心跳时，执行器会汇总其管理的处理单元的资源使用状况和执行器总体的资源使用状况，将其组织为心跳，发送给收集模块。心跳间隔可以通过配置文件进行设置和管理。

在流式数据处理***中，处理单元间会传递事件序列，因此本发明需要支持处理单元相互间进行通信，***为此提供了名字空间机制。***为每个处理单元分配一个全局唯一的标识（ID），处理单元在初始化时只需记录与之通信的处理单元ID以及相应的业务逻辑关系。***的名字空间会维护处理单元标识（ID）到其通信地址（IP地址与端口）的映射关系。处理单元首次与其他处理单元通信时，需要先访问名字空间，获取其通信地址，再与之通信。

调度管理器是***的核心管理者，包括收集模块、调度模块两个部分。为避免程序内部进程过多，影响程序性能和稳定性，***以进程的形式实现两个模块，模块之前通过远程过程调用（Remote Procedure Call）进行通信。两个模块理论上可以部署在不同物理节点，但为减少通信开销，实际运行中应部署在同一物理节点上。

收集模块维护全局执行器资源信息，包括每个执行器所在物理节点的IP地址、通信端口以及每种资源的总量、可用量等，调度模块以上述资源信息为基础进行调度。在调度模块启动、关闭相应的处理单元之后，收集模块根据该处理模块的资源需求和部署节点，会更新全局资源信息。此外，收集模块接收各个执行器定时发送的心跳，其中包括执行器的资源使用状况及处理单元的资源使用状况，主要包括执行器和处理单元的状态和各种资源的资源利用率。

调度模块定时从调度队列中获取待调度任务，根据任务信息生成处理单元，在获取收集模块全局资源信息的基础上，使用处理单元调度方法，调度、启动处理单元；此外根据***的运行需求或***管理员的指令，调度模块可以控制、动态迁移处理单元。***管理员或者外部程序通过客户端与整个***进行交互，具体方式是通过客户端与调度模块交互，交互内容包括提交任务或指定指令。

本发明实施例中具有两类配置文件，分别供调度管理器和执行器使用。其中调度管理器的配置文件包括调度模块、收集模块的通信地址、资源分配策略选项、Linux容器配置信息等，三个模块启动时需要获取配置文件内容进行初始化。执行器配置文件包括执行器通信端口、资源管理中收集模块的通信地址、本物理节点绑定网卡等信息，执行器在启动时也需要通过获取配置文件内容进行初始化，并向收集模块发送心跳，进行注册。

图1为本发明方法步骤流程图。该方法按照以下步骤对进行调度部署，具体包括：

步骤1：调度管理器从存储待调度作业的调度队列中实时获取待调度作业，并根据待调度作业的信息利用有向无环图生成包括多个处理单元的处理单元队列，所述调度管理器设置于高配置的物理节点上，未设置有调度管理器的其他物理节点上分别设置有一个执行器;

步骤2：调度管理器根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点，每个物理节点上设置有处理单元的数量为零至多个；

步骤3:执行器在启动处理单元时，先在该物理节点上创建一个linux容器，然后在linux容器内部启动处理单元。

在本发明实施例中，步骤1根据下述方法获得待调度作业：根据“先入先出原则”，从作业队列中获得待调度作业。***的作业调度队列供所有用户共同使用，用户使用客户端管理工具提交作业，先提交的作业将率先被调度。

图2为本发明实施例的生成处理单元队列的流程图，用于根据调度作业信息，生成待调度的处理单元队列，其步骤如下：

所述步骤1具体包括以下步骤：

步骤1.1：调度管理器根据先入先出原则从存储待调度作业的调度队列中获取待调度作业；

步骤1.2：根据待调度作业的预定的业务需求信息和并发需求信息，将作业分解为以处理单元为顶点、以数据通路为边的有向无环图（DirectedAcyclic Graph）；

步骤1.3：从有向无环图中选择一个没有入边的顶点，将该没有入边的顶点加入处理单元队列中；

步骤1.4：从有向无环图中删除所述步骤1.3中选择的没有入边的顶点，并删除从该没有入边的顶点发出的所有边；

步骤1.5：判断所述有向无环图中是否还有顶点，如果有则转至步骤1.2；如果没有则结束。

在本发明实施例中，步骤1.2所述的有向无环图由顶点和边组成，其中顶点为处理单元，边为数据通路。处理单元队列是对处理单元进行“拓扑排序”得到的结果。拓扑排序是指对有向无环图的顶点的一种排序，它使得如果存在一条从顶点A到顶点B的路径，那么在排序中B出现在A的后面。

图3为本发明实施例的处理单元有向无环图的示意图。图3所示例子中，***根据作业信息，生成了A、B、C、E、D、F、G、H供7个处理单元。外部流式数据从A、B、C三个处理单元流入***，经过一系列的处理后，最终在处理单元H汇聚，并输出结果。从单个处理单元的角度来看，以D为例，它接收A、B、C发送的事件序列，经过处理后生成新的事件，并将生成的事件发送给F。

图4为本发明实施例的处理单元有向无环图变化的示意图。拓扑排序是对有向无环图进行不断变换得到的排序，具体变换方式是每次从图中选择一个没有入边的顶点，然后将该顶点以及从该顶点发出的边删除。图3就是图3进行这种变换的中间形态。在图3中，我们选择没有入边的顶点A，并删除从A发出的两条边，于是就得到了图4所示的有向无环图。对图3所示的有向无环图进行完整的拓扑排序，可以得到A、B、C、D、E、F、G、H的序列。

图5为本发明实施例的处理单元调度方法的流程图，用于调度处理单元，为处理单元选择合适的物理节点，其步骤如下：

步骤2.1：计算每个物理节点的非本地通信数和主导资源比例，所述非本地通信数指与当前物理节点上的处理单元进行网络通信的、不在同一物理节点的待调度的处理单元的数量，所述主导资源比例指多种资源需求可用比中最高的资源需求可用比；

步骤2.2：根据非本地通信数和主导资源比例，对物理节点进行排序，得到排序列表L，并将列表中的物理节点标记为“未读”；

步骤2.3：从所述排序列表L中选择第一个“未读”的物理节点N，并将其标记为“已读”；

步骤2.4：判断所述选择的第一个“未读”的物理节点的加权负载值是否小于80%，如果小于80%，则将待调度的处理单元放置于该物理节点上，结束；

步骤2.5：所述排序列表L中是否还有“未读”的物理节点，如果有则转至步骤2.3；如果没有，则选择排序列表L中的第一个物理节点。

在本发明实施例中，上述步骤2.1提到的“非本地通信数”指需要与待调度处理单元进行网络通信的、且不在同一物理节点的处理单元的数量。物理节点的非本地通信数根据下面方法计算：将非本地通信数初始化为0，并假设待调度处理单元已经部署到该物理节点，然后遍历所有已经完成调度的处理单元，如果一个处理单元与待调度处理单元需要通信、且两个处理单元不在同一物理节点上，则“非本地通信数”加一。最后得到的“非本地通信数”即为所求。以图3所示的处理单元为例，假设***已经对处理单元A、B、C完成了调度，3个处理单元被调度到不同的物理节点a、b、c上，***现在需要调度处理单元D。由于处理单元D需要与A、B、C通信，那么对于D来说，物理节点a、b、c的“非本地通信数都是2。假如***中还包括另一个物理节点d，那么d的“非本地通信数”是3。

在本发明实施例中，步骤2.1采用下面方法计算物理节点的主导资源比例：计算该物理节点每种资源的资源需求可用比，所述资源需求可用比是处理单元的资源需求量与物理节点的资源可用量的比例，多种资源需求可用比中最高的一个即为该物理节点的主导资源比例。举例来说，本***维护CPU、内存、网络带宽三种资源，一个处理单元的资源需求为<1CPU,2G内存,1Mbits/s>，此时物理节点的可用资源为3个CPU、10G内存、4Mbits/s，那么CPU、内存、网络带宽的资源需求可用比分别为1/3、1/5、1/4。由于1/3最大，所以该物理节点的主导资源比例是1/3，主导资源是CPU。

值得注意的是，如果一个物理节点某种资源的的资源可用量小于处理单元的资源需求，则认为该物理节点没有足够的资源，将其主导资源比标记为无穷大，不参与排序。举例来说，一个处理单元的资源需求为<1CPU,2G内存,1Mbits/s>，而此时物理节点的可用资源为3个CPU、1G内存、4Mbits/s，该物理节点没有足够可用资源，就将其主导资源比例标记为无穷大。如果所有的物理节点都没有足够资源，则本次调度失败，则将处理单元重新放回调度队列，一段时间后重新进行调度。

在发明实施例中，步骤2.2根据非本地通信数和主导资源比例，对物理节点从小到大排序。两个物理节点先比较非本地通信数，如果不等，则非本地通信数小的物理节点排在前面；如果相等，再比较二者的主导资源比例，主导资源比例小的物理节点排在前面。

在发明实施例中，步骤2.4所述的加权负载值是根据CPU、内存、网络带宽三种资源计算出的加权负载，加权负载值等于“CPU利用率*0.3+内存利用率*0.3+网络带宽利用率*0.4”。

图6为本发明实施例的部署处理单元的流程图，所述步骤3用于在选择物理节点之后部署处理单元，具体包括：

步骤3.1，在全局资源信息中，减去处理单元的资源配额；

步骤3.2，将处理单元的信息下发给所述选择的物理节点；

步骤3.3，在该物理节点上创建Linux容器（Linux Container），并根据处理单元的资源需求为Linux容器设置资源配额；

步骤3.4，在所述步骤3.3中创建的Linux容器内，启动处理单元。

在本发明实施例中，步骤701所指全局资源信息，是指调度管理器的收集模块维护的所有物理节点的各种资源总量及资源可用量。一个物理节点的各种资源总量可以表示为<32CPU,64G内存,100Mb/s>，此时的资源可用量可以表示为<8CPU,15G内存,30Mb/s>。我们假设所选的物理节点a的资源可用量为<8CPU,15G内存,30Mb/s>，待部署处理单元的资源需求为<2CPU,4G内存,10Mb/s>，那么就需要在a的资源可用量中减去处理单元的资源需求，更新后a的资源可用量为<6CPU,11G内存,20Mb/s>。

本***选择使用Linux容器（Linux Container）为处理单元提供资源隔离环境，Linux容器是轻量级的虚拟化技术，性能开销非常小，通常可以忽略不计，非常适合流式数据处理注重性能的特性。此外，Linux容器可以动态调整资源容量，为本***的资源配额自动伸缩方法提供可行性。在Linux容器内部启动处理单元，根据Linux容器的性质，其内部的处理单元只能使用分配给它的资源配额，在资源紧张时，不会抢占其他处理单元的资源。

一种面向流式数据的作业调度装置，包括调度管理器1，执行器2和调度队列3；

所述调度管理器1，设置于高配置的物理节点上，用于从调度队列3中实时获取待调度作业，并根据待调度作业的信息利用有向无环图生成包括多个处理单元的处理单元队列，根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点，每个物理节点设置有至少一个处理单元；

所述执行器2，用于启动处理单元，将调度管理器1调度给该物理节点的处理单元放置于linux容器内部，在linux容器内部启动处理单元；

所述调度队列3，与调度管理器部署在同一物理节点上，用于存储待调度作业。

所述调度管理器1包括收集模块和调度模块；

所述收集模块，用于收集每个执行器所在物理节点的IP地址、通信端口、每种资源的总量及可用量，执行器资源使用状况及处理单元的资源使用状况；

所述调度模块，用于从调度队列中获取待调度作业，并根据待调度作业的信息生成包括多个处理单元的处理单元队列，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别调度给对应的物理节点。

每个所述处理单元均设置有唯一的处理单元标识。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种面向流式数据的作业调度方法，其特征在于，包括以下步骤：

步骤1：调度管理器从存储待调度作业的调度队列中实时获取待调度作业，并根据待调度作业的信息利用有向无环图生成包括多个处理单元的处理单元队列，所述调度管理器设置于高配置的物理节点上，未设置有调度管理器的其他物理节点上分别设置有一个执行器;

步骤2：调度管理器根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点，每个物理节点上设置有处理单元的数量为零至多个；

步骤3:执行器在启动处理单元时，先在该物理节点上创建一个linux容器，然后在linux容器内部启动处理单元。

2.根据权利要求1所述的面向流式数据的作业调度方法，其特征在于：所述步骤1具体包括以下步骤：

步骤1.1：调度管理器根据先入先出原则从存储待调度作业的调度队列中获取待调度作业；

步骤1.2：根据待调度作业的预定的业务需求信息和并发需求信息，将作业分解为以处理单元为顶点、以数据通路为边的有向无环图；

步骤1.3：从有向无环图中选择一个没有入边的顶点，将该没有入边的顶点加入处理单元队列中；

步骤1.4：从有向无环图中删除所述步骤1.3中选择的没有入边的顶点，并删除从该没有入边的顶点发出的所有边；

步骤1.5：判断所述有向无环图中是否还有顶点，如果有则转至步骤1.2；如果没有则结束。

3.根据权利要求1所述的面向流式数据的作业调度方法，其特征在于：所述步骤2进一步包括以下步骤：

步骤2.1：计算每个物理节点的非本地通信数和主导资源比例，所述非本地通信数指与当前物理节点上的处理单元进行网络通信的、不在同一物理节点的待调度的处理单元的数量，所述主导资源比例指多种资源需求可用比中最高的资源需求可用比；

步骤2.2：根据非本地通信数和主导资源比例，对物理节点进行排序，得到排序列表，并将列表中的物理节点标记为“未读”；

步骤2.3：从所述排序列表中选择第一个“未读”的物理节点，并将其标记为“已读”；

步骤2.4：判断所述选择的第一个“未读”的物理节点的加权负载值是否小于预定值，如果小于预定值，则将待调度的处理单元放置于该物理节点上，结束；

步骤2.5：所述排序列表中是否还有“未读”的物理节点，如果有则转至步骤2.3；如果没有，则选择排序列表中的第一个物理节点。

4.根据权利要求3所述的面向流式数据的作业调度方法，其特征在于：计算物理节点的非本地通信数时进一步包括：

将非本地通信数初始化为0；

假设当前物理节点上的处理单元已经调度到该物理节点，然后遍历所有已经完成调度的处理单元；

如果一个处理单元与待调度的处理单元需要通信、且两个处理单元不在同一物理节点上，则当前的非本地通信数加一，最后得到非本地通信数。

5.根据权利要求3所述的面向流式数据的作业调度方法，其特征在于：所述主导资源比例的计算方法具体为：

计算该物理节点每种资源的资源需求可用比，所述资源需求可用比是处理单元的资源需求量与物理节点的资源可用量的比例；

选择多种资源需求可用比中最高的一个即为该物理节点的主导资源比例。

6.根据权利要求3所述的面向流式数据的作业调度方法，其特征在于：

所述步骤2.2中，根据非本地通信数和主导资源比例，对物理节点从小到大排序具体包括以下步骤：

两个物理节点先比较非本地通信数，如果不等，则非本地通信数小的物理节点排在前面；如果相等，再比较二者的主导资源比例，主导资源比例小的物理节点排在前面。

7.根据权利要求3所述的面向流式数据的作业调度方法，其特征在于：所述加权负载值的具体计算方法为：

加权负载值=CPU利用率*0.3+内存利用率*0.3+网络带宽利用率*0.4。

8.一种面向流式数据的作业调度装置，其特征在于：包括调度管理器（1），执行器（2）和调度队列（3）；

所述调度管理器（1），设置于高配置的物理节点上，用于从调度队列（3）中实时获取待调度作业，并根据待调度作业的信息利用有向无环图生成包括多个处理单元的处理单元队列，根据物理节点的非本地通信数和主导资源比例，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别分配给对应的物理节点，每个物理节点设置有至少一个处理单元；

所述执行器（2），用于启动处理单元，将调度管理器（1）调度给该物理节点的处理单元放置于linux容器内部，在linux容器内部启动处理单元；

所述调度队列（3），与调度管理器部署在同一物理节点上，用于存储待调度作业。

9.根据权利要求8所述的面向流式数据的作业调度装置，其特征在于：所述调度管理器（1）包括收集模块和调度模块；

所述收集模块，用于收集每个执行器所在物理节点的IP地址、通信端口、每种资源的总量及可用量，执行器资源使用状况及处理单元的资源使用状况；

所述调度模块，用于从调度队列中获取待调度作业，并根据待调度作业的信息生成包括多个处理单元的处理单元队列，为处理单元队列中的每个处理单元分别选择物理节点，将所有处理单元分别调度给对应的物理节点。

10.根据权利要求8所述的面向流式数据的作业调度装置，其特征在于：每个所述处理单元均设置有唯一的处理单元标识。

Images