实施例提供多个用户的调度队列示意图，如图3所示，其中包括有三个用户的 用户，分别为用户1、用户2和用户3 ;在调度队列中分别记录有每一个用户的资源配额和资 源使用阈值；并且在调度队列中有每个用户的至少一个作业。
[0092] 上述步骤101-步骤102相当于本发明实施例作业调度方法中的预处理过程，预处 理可以缩小备选作业范围，一定程度上减少整个处理方法的时空复杂度。
[0093] 本实施例中选取到第一作业之后，可以在服务器中将该第一作业记录为第一作业 个二元组〈User，Job〉，即〈用户信息，第一作业的标识〉。
[0094] 优选地，执行完分别选取至少一个用户中每个用户的第一作业之后，还可以包 括：
[0095] 利用所述至少一个用户中每个用户的第一作业建立第一作业信息列表；
[0096] 逐个所述第一作业信息列表中每个第一作业对应的用户的已用资源是否大于资 源使用阈值，若大于资源使用阈值，则从所述第一作业信息列表中删除所述第一作业，得到 更新后的第一作业信息列表。
[0097] 相应的，所述从至少一个用户的所述每个用户的第一作业中选取出第二作业，包 括：从更新后的所述第一作业信息列表中选取第二作业。
[0098] 其中，所述资源使用阈值可以为根据实际情况设置，比如可以设置为40%。
[0099] 上述建立第一作业信息列表的方法可以为：利用第一作业二元组建立所述第一作 业信息列表。
[0100] 图4为构建第一作业信息列表过程的示意图，其中，用户调度队列中有用户a、用 户b、用户c，每个用户的调度队列中记录有作业信息；所述作业信息包括有对应的用户、第 一特征参数。从每个用户的调度队列中选取第一特征参数最大的一个作业作为该用户的第 一作业；比如，图4中选取用户a的作业（a，0. 5)，用户b的作业（b，0. 5)，用户c的作业（c， 0. 6)，将上述选取的多个用户的第一作业作为第一作业信息列表。
[0101] 进一步的，上述用户的已用资源的计算方法可以有以下两种计算方式：
[0102] 第一种、直接从服务器的记录中获取到用户的已用资源的记录；
[0103] 第二中，从服务器的记录中获取用户的已用资源的记录之后，将用户的已用资源 与调度队列中待调度的作业的所需资源做和，得到计算后的用户的已用资源。可以以百分 比的形式表示。
[0104] 另外，还可以包括从第一作业信息列表中筛除作业为空的二元组。
[0105] 本实施例中，所述选取出第二作业，可以包括以下两种实现方式：
[0106] 方式一、根据所述每个用户的第一作业的第一特征参数，从所述至少一个用户中 选取最大的第一特征参数对应的作业作为第二作业。
[0107] 方式二、根据用户的已用资源是否大于预设的用户的资源配额对所述至少一个用 户进行分类，将已用资源大于预设的用户的资源配额的用户作为第一类用户，将已用资源 不大于预设的用户的资源配额的用户作为第二类用户；从所述第二类用户中选取最大的第 一特征参数对应的作业作为第二作业。
[0108] 可以理解的是，在使用上述方式二时，有可能会出现第二类用户为零的情况，如果 无第二类用户，则从所述第一类用户中选取最大的第一特征参数对应的作业作为第二作 业。
[0109] 图5为选择作业流程的示意图，图中用户a已用资源超过了资源使用阈值，在初期 针对第一作业进行删除的操作中就会被去除；用户b和用户c已用资源未超过用户的资源 配额，从用户b和用户c选取一个紧急度最高的作业（c, 0. 6)，记为第二作业。
[0110] 根据上述思路，假设每个用户的第一作业记为job;每个用户与其第一作业组成 第一作业二元组，记为〈user,job〉；所有第一作业二元组组成一个第一作业列表，记为 user_job_list。首先，初始化未超过资源配额的最紧急作业第二类用户对应的第一作业 为job_in，且job_in.urgency为0 ;初始化第一类用户对应的第一作业job_beyond，job_beyond,urgency为0。本实施例针对上述步骤103的算法流程如下：
[0111]
[0113] 优选地，所述选取第三作业，包括：获取到所述第二作业对应的第一用户，判断所 述第一用户是否满足第二预设条件，若满足第二预设条件，则依次从所述第一用户的运行 作业列表中选取作业，判断选取的作业的第一特征参数是否小于第二预设门限值，若小于 第二预设门限值，则将选取的作业作为第三作业，结束处理；若不满足第二预设条件，从除 所述第一用户外的其他用户中选取符合第二预设条件的第二用户，依次从所述第二用户的 运行作业列表中选取作业，判断选取的作业的第一特征参数是否小于第二预设门限值，若 小于第二预设门限值，则将选取的作业作为第三作业。
[0114] 上述第二预设门限值小于第一预设门限值，比如可以设置所述第二预设门限值为 0. 85 ;即不能够抢占处理紧急度高于0. 85的作业的处理资源。如此，就能够在保证最紧急 的作业的处理效率之外，还能够保证较为紧急的作业的处理资源不被抢占。
[0115] 优选地，所述依次从所述第一用户的运行作业列表中选取作业之前，所述方法还 包括：基于所述第一用户的运行作业列表中的至少一个作业的第一特征参数，将所述运行 作业列表中的至少一个作业进行排序。其中，所述排序的方式具体根据第一特征参数从小 至 1J大的顺序进行排序，
[0116] 根据上述思路，假设每个用户的第一作业记为job;每个用户与其第一作业组成 第一作业二元组，记为〈user,job〉；所有第一作业二元组组成一个第一作业列表，记为 user_job_list。首先，初始化未超过资源配额的最紧急作业第二类用户对应的第一作业 为job_in，且job_in.urgency为0 ;初始化第一类用户对应的第一作业job_beyond，job_ beyond,urgency为0。本实施例中第二作业抢占资源的操作算法可以如下：
[0117]
[0118] 根据上述调度策略，实施例实现了可以满足公平和SL0多元目标的原型调度器， 称之为M-SLO Scheduler。同时，实施例还实现了保障作业SL0但忽视多租户公平的调度 器，称之为Deadline Scheduler。为了进行对比，验证本实施例提出调度策略的有效性，实 验以现有的保证公平但忽视SL0的Hadoop Capacity Scheduler作为参照对比项。对调度 策略的实验评价涵盖两类实验场景，一类实验场景是一次性提交大量作业，使用优先调度 算法进行调度，不触发资源抢占；一类实验场景是定时多次提交作业，使用优先调度算法进 行调度，同时触发资源抢占。实验对比维度分别为Deadline保证率、作业执行效率以及公 平性三个方面。
[0119] 实验环境选取一个由5台服务器节点组成的集群，每台节点包括24核CPU、16GB 内存，CPU型号为IntelXeonE5645,内核版本为3. 2.O-23-generic，集群资源总量为120 核CPU和80GB内存。集群租户选用A、B、C三个不同租户，其资源配额分别为25%、25%和 50 %，资源使用阈值统一为60 %。
[0120] 作业的服务水平目标（SL0)是重点关注的调度指标，实验通过Deadline保证率来 量化SL0的保证程度。图6记录了在不同场景下三种调度器的作业Deadline保证率。在 一次提交大量作业的场景下，CapacityScheduler(最浅的灰色条）的作业Deadline保证 率为76. 43%，而M-SLOScheduler(最深的灰色条）和DeadlineScheduler(深度居中的 灰色条）的作业Deadline保证率分别高达98. 57%和99. 82%，提升幅度在20个百分点以 上。在多次提交作业的场景下，CapacityScheduler的作业Deadline保证率仅为55. 28%， 而M-SLOScheduler和DeadlineScheduler通过资源抢占，可以将作业Deadline保证率 分别提高到90. 29 %和93. 78%，提高幅度在35个百分点以上。总体来看，相比Capacity Scheduler，M-SLOScheduler和DeadlineScheduler的调度机制可以显著提高作业的 Deadline保证率。
[0121] 作业执行效率是衡量调度策略的重要指标，本文以作业执行完成的总时间来量化 全局作业执行效率。图7记录了在不同场景下三种调度器的作业执行总时间，Capacity Scheduler(最浅的灰色条）、M_SL0Scheduler(最深的灰色条）和DeadlineScheduler(深 度居中的灰色条）。在一次提交大量作业的场景下，相比CapacityScheduler，M-SLO Scheduler和DeadlineScheduler可以小幅减少作业执行总时间，提高作业执行效率。 在多次提交作业的场景下，相比CapacityScheduler，M-SLOScheduler和Deadline Scheduler则会小幅增加作业执行总时间。这是因为在多次提交作业的场景下，为了保证后 续提交的紧急作业按时完成，会触发资源抢占，中断部分正在运行中的非紧急作业，因此总 执行时间会小幅增长。综合来看，三者作业执行效率大体相当。其中，在不触发抢占的情况 下，M-SLOScheduler和DeadlineScheduler的作业执行效率略优；在触发抢占的情况下 M-SLOScheduler和DeadlineScheduler的作业执行效率则略逊于CapacityScheduler。
[0122] 在各类应用场景中，由于需要中断运行中的作业，抢占机制都会增加作业执行开 销。但是，抢占机制也会提供更为灵活的调度机制，可以提高作业的Deadline保证率，这本 身就是调度系统中的一个权衡和折中。本文聚焦于多租户集群场景，因此需要关注不同租 户之间的公平性。公平是一个较为抽象的概念，本文以每个租户的作业执行时间来量化公 平性概念。如果存在某一个或多个租户的作业执行时间明显增长，则说明系统没有保证该 租户的资源使用权益，租户间的公平受到了影响；反之则证明系统保证了租户间的公平。
[0123] 图8和图9分别记录了多个用户一次提交作业和多次提交作业场景下的各租户作 业执行时间；图8和图9中从左到右分别为用户a、用户b和用户c。图8中，相比于Capacity Scheduler，M_SLOScheduler的租户作业执行时间最多增长了 2. 4%，DeadlineScheduler 的租户作业执行时间最多增长了 22. 7%。图9中，由于触发抢占，作业执行时间的变化幅 度更大，相比于CapacityScheduler，M-SL0Scheduler的租户作业执行时间最多增长了 5. 3%，Dead