servicemodejob（又名：onlinejob）是fuxi提供的一套准实时计算框架，通过毫秒级的调度开销和网络shuffle模式为小job提供更高的性能。目前odps对内生产集群约1/3的job通过servicemodejob进行处理，对其中小job比较多的集群，这个占比会提高到70%。
由于同一套servicemode服务会有多个project的job共用。需要对各个project的job进行资源隔离和弹性调度，servicemode提供了一套面向多租户（quota group）的完整解决方案。
servicemodejob多租户功能需要解决以下几个用户场景：
不同project作业之间的资源隔离和分组计费功能
在不同时段，各个project对servicemode服务的使用需求不同，需要提供分时quota的功能
servicemode服务的worker数可能会预先指定，构成一个sharedworkerpool，各个quota组的配置情况需要与worker数保持对应。
根据当前服务的剩余资源和各quota组的使用情况，对各组job进行弹性调度，并支持配置基线作业优先级，保证生产基线job。
鉴于servicemode服务all-or-nothing的调度策略，在quota组作业调度过程中需要尽可能减小资源调度碎片，提高资源使用率。
针对上述的几个用户场景，我们逐一对功能点进行展开。
每个租户根据自己的需要，配置相应的quota group。一个quota group包含｛maxquota,minquota｝两个配置。maxquota表示这个组最大能够持有的资源，minquota表示这个组最低期望获得的资源。由于各租户在不同时段对servicemode的使用需求不同，因此租户的配置是随时段改变的。
各租户的配置信息将组合成一张出资表，servicemode服务将根据出资表中的各组设置进行job调度和资源分配。一个典型的出资表如下所示：
整个出资表是一个多级map结构。第一级的key是时段，“0-9”表示0点到9点的配置，"default"表示默认配置。第二级的key是各个quotagroup的名字。最后是各个组在不同时段的配置。"groupid‘是quotagroup的标识id，用于和fuximaster角色同步校验quotagroup的配置。提交到servicemode上的job，只有所属的group在该时段有对应的出资才会得到调度。如例子中的group3仅在"0-9"时段有出资，因此在其他时段group3的作业不会得到调度。
一个组的minquota配置的越大，调度过程中越容易拿到资源；maxquota配置的越大，在空闲资源比较多时调度弹性会越大。在调度过程中，会保证每个组minquota的资源需求和maxquota的弹性收缩。具体的调度算法将在后续section进一步展开。
线上集群在servicemode服务打开quota模式以后，可以根据每个quotagroup的usedquota情况进行分组的计费。如下图所示：
线上集群的servicemode服务worker数目一般都进行了预先指定。这也是一个分时段的配置，我们称之为workerspans配置，例如下面的配置表示0-9点的worker数是15000个（workerspansnum=15000workerspansnum=15000），其他时段是5000个。
出资表中每个时段的totalminquota=∑nn=1(minquota)totalminquota=∑n=1n(minquota)，在设置时必须保证workerspansnum>=totalminquotaworkerspansnum>=totalminquota，而workerspansnum−totalminquotaworkerspansnum−totalminquota即是该时段的sharedworkerpool。这批sharedworker将在调度过程中作为额外的弹性资源分配给需要的quotagroup，因此workerspansnum<=totalmaxquota=∑nn=1(maxquota)workerspansnum<=totalmaxquota=∑n=1n(maxquota)。
在实际的场景里，sharedworkerpool是一个动态grow/shrink的池子。比如大部分组的资源请求都很少，只有一个组的资源请求>minquota且<=maxquota，这个时候所有的空闲资源都可以认为是sharedworkerpool。
每个quota group实际使用的资源称为usedquota，根据它和maxquota，minquota的关系，会有以下几种组状态。
当一个组的状态处于normal时，系统会优先对该组进行调度。如果当前没有来自于normal组的请求，会调度处于overused状态的组job。而对于drawback组，系统不会响应该组的任何资源请求，直到该组的的job进入终态释放资源后，组状态迁移回overused或normal，才会重新开始调度。
每个quota group在调度过程中会对应一个调度队列，每个调度队列内部会基于组状态，作业优先级和提交时间等规则进行排序（排序的规则后面一节会具体展开）。调度规则的伪代码如下：
无论是quota group组内的排序还是挑选topjob都依赖在上文中提到的排序规则。排序规则首先应该考虑的是作业的优先级。但在作业优先级相同的情况下，由于servicemode系统的all-or-nothing调度特性，如果仅仅考虑提交时间可能会产生比较大的调度碎片，使一些规模比较小的job出现等资源超时的现象（等资源时间超过10秒钟）。
因此，我们结合每个job的规模和提交的时间，提出了submitwindow的方法来解决这一问题。根据每个job提交的时间，以5秒（可配参数）为一个时间间隔，将job划分到不同的submitwindow中。submitwindow靠前的job会优先被调度，而对于submitwindow相同的job，job的request资源数目越少的调度优先级越高。
目前，servicemode多租户功能已经上线了多个生产集群。从实际的上线效果看，多租户功能达到了资源隔离和分组计费等重要作用。我们统计上线前后一个月时间内servicemode服务上作业的“等资源超时次数”（即等待资源的时间超过10秒钟），如下图。数据显示quota有助于保障各个租户能更及时地拿到资源，11日升级后等资源超时次数大幅下降，从升级前平均2363次下降到1636次，下降幅度31%。从等资源超时job/总提交job数的占比情况分析，也能得出这一结论。
蓝色线：等资源超时failed的job数目
红色线：等资源超时failed的job数/总提交job数 占比值
欢迎加入“数加·maxcompute购买咨询”钉钉群（群号： 11782920）进行咨询，群二维码如下：