
MapReduce
排程器
|
187
表
7-2
公平排程器分配範例
─
總需求量超過總容量
80
個插槽
資源池
需求量
最小分享
實際分享
Mary 20 0 20
Bob 40 0 30
Jane 120 0 30
到目前為止,我們已經說明了即時的任務提交情形,也就是由使用者提交
MapReduce
任務。這看起來不錯,但這些任務並沒有很高的時間敏感度(
time-sensitive
)。現在,
讓我們假設有一個名為
production
的資源池,用來定期自動化執行
ETL
任務。重點是
為了在固定時間內完成,每個任務必須拿到特定個數的
map
插槽(當然,這裡假設您
知道每個
map
工作的平均執行時間,以及每次任務大約需要執行多少工作,不過那是
另一個故事)。身為一個系統管理者,在總容量
80
個插槽中,我們將這個資源池設定
為需要
50
個
map
最小分享插槽。
現在,假設有一個
production
的任務需要
30
個
map
工作,
Mary
的需求量為
40
,
Bob
的需求量為
30
(如表
7-3
所示)。由於總容量只有
80
個工作插槽,我們很明顯已過度
訂閱(
over-subscribed
)。每個人都無法取得他們想要的,至少不是
Mary
跟
Bob
。還
記得分配最小分享總是發生在公平分享之前嗎?還有我們不會發放超過一個資源池的
需求量?在這個案例中,
production
會馬上取得所要求的
30
個插槽(因為它設有
50
個最小分享)。剩下的插槽會根據公平分享原則,所以結果是
Mary
跟
Bob
會分別取
得
25
個插槽。
表
7-3
公平排程器分配範例 ...