免費開通大數據服務：https://www.aliyun.com/product/odps

轉載自boyan

概述

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調度和資源分配。一個典型的出資表如下所示：

{"default":{ "group1":{ "GroupId":1,"MaxQuota":5000,"MinQuota":3000}, "group2":{ "GroupId":2,"MaxQuota":5000,"MinQuota":2000} }, "0-9":{ "group1":{ "GroupId":1,"MaxQuota":15000,"MinQuota":10000}, "group3":{ "GroupId":3,"MaxQuota":3000,"MinQuota":3000} } }

整個出資表是一個多級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情況進行分組的計費。如下圖所示：

SharedWorker Pool

線上集群的ServiceMode服務Worker數目一般都進行了預先指定。這也是一個分時段的配置，我們稱之為WorkerSpans配置，例如下面的配置表示0-9點的Worker數是15000個（WorkerSpansNum=15000WorkerSpansNum=15000），其他時段是5000個。

default:5000,0-9:15000

出資表中每個時段的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資源彈性調度算法

每個Quota Group實際使用的資源稱為UsedQuota，根據它和MaxQuota，MinQuota的關系，會有以下幾種組狀態。

enum QuotaState {Normal, /* UsedQuota <= MinQuota */Overused, /* UsedQuota > MinQuota && UsedQuota < MaxQuota */Drawback, /* UsedQuota >= MaxQuota */ ｝

當一個組的狀態處于Normal時，系統會優先對該組進行調度。如果當前沒有來自于Normal組的請求，會調度處于Overused狀態的組Job。而對于Drawback組，系統不會響應該組的任何資源請求，直到該組的的Job進入終態釋放資源后，組狀態遷移回Overused或Normal，才會重新開始調度。

每個Quota Group在調度過程中會對應一個調度隊列，每個調度隊列內部會基于組狀態，作業優先級和提交時間等規則進行排序（排序的規則后面一節會具體展開）。調度規則的偽代碼如下：

while (true) {while (true){1. 選擇一個topJob：1.1 如果有EmergentJob，即作為topJob，并reset EmergentJob為空；1.2 否則，從各個group的隊列(pri, FIFO)選擇隊列頭job，如果隊列頭job有基線任務（prodLevel）則優先分配；如果沒有則按(usedQuota<minQuota, pri, FIFO)規則進行遍歷，可以認為usedQuota越小，作業優先級越高，提交越早的即為topJob：2. 調度topJob：a. freeRes >= topJob.size，則直接assign給topJob，并從對應的group隊列中刪除。如果在assign時所在group已經是usedQuota > minQuota，則該job加入到toPreemptList（可被搶占的）。freeRes可能有剩余的，continue進入下一輪調度。b. freeRes < topJob.size，如果沒開搶占，本輪調度失敗，topJob作為EmergentJob。如果開搶占：- 如果topJob所在group是usedQuota < minQuota，就獲得搶占資格，去toPreemptList中從前往后搶占直到資源足夠topJob的請求。- 否則沒有搶占資格，本輪調度失敗，topJob作為EmergentJob。} }

SubmitWindow

無論是Quota Group組內的排序還是挑選topJob都依賴在上文中提到的排序規則。排序規則首先應該考慮的是作業的優先級。但在作業優先級相同的情況下，由于ServiceMode系統的All-or-Nothing調度特性，如果僅僅考慮提交時間可能會產生比較大的調度碎片，使一些規模比較小的Job出現等資源超時的現象（等資源時間超過10秒鐘）。
因此，我們結合每個job的規模和提交的時間，提出了SubmitWindow的方法來解決這一問題。根據每個Job提交的時間，以5秒（可配參數）為一個時間間隔，將Job劃分到不同的SubmitWindow中。SubmitWindow靠前的Job會優先被調度，而對于SubmitWindow相同的Job，Job的Request資源數目越少的調度優先級越高。

struct SchItemPerJobPriorityComparer {// priority > submitWindow > aonReqCnt > createTimebool operator()(const SchItemPerJobPtr &job1, const SchItemPerJobPtr &job2) const{ if (job1->priority < job2->priority) return true;else if (job1->priority > job2->priority) return false;else if (job1->submitWindow < job2->submitWindow) return true;else if (job1->submitWindow > job2->submitWindow) return false;else if (job1->mTotalAonReq < job2->mTotalAonReq) return true;else if (job1->mTotalAonReq > job2->mTotalAonReq) return false;else if (job1->submitTime < job2->submitTime) return true;else return false;} };

總結

目前，ServiceMode多租戶功能已經上線了多個生產集群。從實際的上線效果看，多租戶功能達到了資源隔離和分組計費等重要作用。我們統計上線前后一個月時間內ServiceMode服務上作業的“等資源超時次數”（即等待資源的時間超過10秒鐘），如下圖。數據顯示quota有助于保障各個租戶能更及時地拿到資源，11日升級后等資源超時次數大幅下降，從升級前平均2363次下降到1636次，下降幅度31%。從等資源超時Job/總提交Job數的占比情況分析，也能得出這一結論。
藍色線：等資源超時Failed的Job數目
紅色線：等資源超時Failed的Job數/總提交Job數 占比值

歡迎加入“數加·MaxCompute購買咨詢”釘釘群（群號： 11782920）進行咨詢，群二維碼如下：

總結

以上是生活随笔為你收集整理的Fuxi ServiceModeJob 多租户（Quota Group） 功能介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。