簡介
大規模數據分析框架正在朝短任務和高並行度低延時方向發展。高並行度短運行時間（百毫秒級）任務調度爲作業調度器的設計帶來了挑戰，既要求每秒百萬級調度，又要提供毫秒級延時，還要保持高可用性（high availability）。我們闡述一個分散，隨機採樣的調度來提供接近最優的性能，分散調度相比集中調度可以避免吞吐量和可用性限制。我們在110臺機器的集羣上部署了我們的調度器 Sparrow，發現Sparrow與貪心調度器的差距只有12%。
1 介紹
如今的數據分析集羣運行着越來越短越來越多的任務。受到工業需求（對低延時、交互式的數據處理的需求，工業界和學術界爲了以秒級時延分析數據而開發了多種內存計算框架，比如Dremel，Spark，Impala）的啓發。我們歡迎這種趨勢，下一代框架目標在於亞秒級響應時間。將響應時間控制到100ms的範圍會催發一大批非常強勁的應用，比如，面向用戶的服務可以運行復雜的並行計算，比如語言翻譯以及高度定製的搜索方案。
由亞秒級任務組成的作業對調度是一個艱難的挑戰。對亞秒級任務的需求不僅僅來自於低延時任務，也來自於分解長運行時間的批作業爲大量的小任務。比如，一種提高公平以及緩解straggler（集羣計算拖後腿的機器）的技術[17]。當任務以百毫秒級運行是，調度決定必須以超高吞吐樑的方式運行：一個包含1萬臺機器每個機器16核的集羣，如果需要按百毫秒級運行任務，那麼每秒需要做百萬個調度決策。調度還需要在低延時下進行：對100ms的任務，超過幾十毫秒的調度（包括了排隊時延）時延將帶來不可忍受的開銷。由於系統以交互的方式直接面向用戶，高可用性也是一個需求。這些設計需求與傳統的批處理系統不同。
修改如今的集中調度器來支持亞秒級並行任務有着苦難的工程挑戰，支持亞秒級任務需要處理超過目前最快的調度器兩個數量級的吞吐量（Mesos[8]，YARN[16]，SLURM[10]），使用一個節點來發射所有的任務相當困難。而且高可用性需要以亞秒級的時間複製或者恢復大量的狀態。
本論文探索另一個極端；我們使用一組各自的機器來進行調度，不存在集中調度也不存在邏輯上集中的狀態。離散調度提供有吸引力的拓展性和可用性。通過添加調度器，系統就可以支持更多的請求，如果一個調度器出現問題了，用戶可以馬上請求其他的調度器。考慮到併發調度會造成調度決策衝突，提供集中調度器相似的響應時間會成爲一個挑戰。
我們設計了Sparrow，一個利用了二選平衡負載理論[14]無狀態分佈式的調度器， 二選平衡負載理論提出調度每個任務時，探測兩個隨機的服務器，然後將任務交給隊列更少的哪個服務器。我們介紹以下三個技術來有效利用平衡負載理論：
Batch Sampling: 因爲作業響應時間對尾任務等待時間很敏感（直到最後一個任務完成，這個作業才完成），二選平衡理論在並行作業中表現很差。批採樣使用最近的多重選擇方法[18]來解決這個問題。批採樣對m個任務隨機選取d*m個機器進行採樣。我們發現，不像二選理論， 當作業的並行性增加的時候，批採樣性能不會急速下滑。
Late Binding:二選理論有兩個問題：一， 機器隊列長度不是等待時間一個好的預測，二因爲消息時延，同時運行的多個調度器經歷競態條件。晚綁定通過延遲分配任務，直到任務快要運行來避免這個問題。比起只使用批採樣，降低了45%的平均等待時間。
Policies and Constraints: Sparrow使用多重隊列來保證全局策略，還支持分析框架所需要的按作業和按任務佈置。policies 和 constraints都沒有在理論模型中被提到，但是在真是的集羣中有很重要的影響。‘
我們在110臺機器的集羣上部署了Sparrow來評估Sparrow的表現。當我們調度TPC-H詢問（這是一個BENCHMARK）時， Sparrow提供低於理想調度器12%時間的響應時間， 平均隊列延遲低於9ms， 調度器錯誤恢復時間低於120ms。 Sparrow對短任務提供了低響應時延。除去離散化的調度方案，Sparrow保持了良好的公平性，隔絕了不同優先度的用戶。模擬結果顯示，打不過集羣的規模提升到數萬個核時，Sparrow依然表現良好。我們的結果顯示當作業有短時延時，離散調度的Sparrow是集中調度的一個可行替代。
2 設計目標
本文着重對低時延應用的細粒度任務調度。
低時延的工作相比批處理對調度有更多的要求，因爲批處理一次請求很長時間的資源，因此不需要頻繁的調度。爲了支持亞秒級任務，調度器必須提供毫秒級調度延時，且提供每秒百萬級調度決策。額外的，因爲低時延框架很可能用於直接面對用戶的服務，調度器應該能容忍調度器錯誤。
Sparrow提供的細粒度任務調度，是集羣資源管理器的補充。Sparrow不爲每個任務發射進程；相反，Sparrow假設每臺機器上已經有一個長時間運行的執行進程（executor process），Sparrow只需要發送一個短的任務描述（而不是很大的執行文件）。這些執行進程是由集羣的（靜態部分？）發射的，或通過集羣的資源管理器（YARN， Mesos，Omega）發射的， 這些資源管理器也爲Sparrow分配資源。
集中調度器能提供很多複雜的調度特徵，Sparrow爲了提供高吞吐量和低延時，對這些特徵做了近似。Sparrow不支持一些限制（比如，"我的任務不能跟X用戶的任務在同一個機器上運行"）， 不支持bin packing，也不支持gang scheduling。
Sparrow支持小部分能夠輕易擴展，降低時延的特徵，Sparrow儘量保持系統的簡單。很多應用爲多用戶提供低時延請求服務， 當需求和超過系統負擔時，Sparrow保證嚴格的優先度調度。Sparrow同時支持基本的任務放置限制，比如每個任務限制（比如說， 每個任務的運行應該和他的輸入數據在一個機器）和每個作業限制（比如說，該作業所有的任務都應該放到攜帶GPU的機器上）。該特徵跟Hadoop Mapreduce 和 Spark的調度器相似。
3 基於採樣的並行作業調度
傳統的任務調度器保持着每個機器上跑的每個任務的所有信息， 並使用這些信息來分配接下來到達的任務。Sparrow採取一個完全不同的策略：Sparrow有多個並行的調度器，調度器不維持有關集羣負載的任何信息。需要調度的時候，調度器向工作機器發送信息來獲得回饋，並以此來作爲調度的信息。Sparrow拓展了目前的負載均衡技術[14]，[18]，並加入了晚綁定來提高性能。
3.1 術語和作業模型
集羣有工作機器和調度器組成，工作機器執行任務，調度器分配任務。一個作業由m個任務組成，每個任務都被分配到一個工作機器上。作業可以被任何調度器處理。工作機器在固定數量的槽上運行任務。我們避免更加複雜的裝箱問題， 這會給設計帶來過多的複雜性。如果一個工作機器被分配超過他的槽的數目，他會將任務放入隊列，直到做夠的資源被釋放。我們使用等待時間來描述一個任務被提交到這個任務被執行的間隔時間，服務時間來描述工作機器執行任務花費的時間，響應時間用來描述作業提交到作業中最後一個任務完成的間隔時間， 延時用來描述一個作業中的總的調度延時和排隊延時。我們使用作業的響應時間減去作業的理想響應時間（即調度不需要時間，也不會被放入隊列，等於作業中最長的任務的服務時間）。
在評估不同的調度策略時，我們假設所有的作業都是一趟任務組成的。在真是的集羣中，由於作業的任務數超過用戶被分配的計算資源，作業可能被分爲多趟的任務執行。我們使用單趟任務模型來評估調度策略是因爲單趟任務最容易收到調度策略的影響，即使一個任務被延遲也會影響到整個作業的響應時間。不過Sparrow也能出來多趟任務模型。
3.2 單任務採樣
Sparrow的設計參考了二選平衡理論[14]， 二選平衡理論在無狀態，隨機的調度方案下降低任務的等待時間。二選平衡理論指出在調度時隨機選取兩個工作機器，將被調度任務分配到低負載的機器上 比 隨機安排任務到一個工作機器上以指數的形式降低了等待時間[14]。
我們首先考慮直接使用二選平衡理論，調度器隨機選擇兩個工作機器，併發送每個機器一個探測消息，探測消息是輕量級的RPC（remote procedure call）。工作機器用目前的等待隊列長度回覆探測，然後調度器將任務分配到那個有更短隊列的工作機器。調度器對每個任務都採用這個調度方案。我們稱這種方案爲單任務採樣。
單任務採樣比起隨機分配有了相當大的性能提升，但相比貪心調度器表現任然差了2倍以上。直覺上說，在單任務採樣中，作業的響應時間受到作業中任務的最長等待時間制約，這使得作業的響應時間比任務的平均響應時間長了很多。我們模擬了單任務採樣和隨機分配的對比， 模擬的場景是10000臺4核的機器，網絡RTT是1ms， 每個作業包含100個任務，並按泊松分佈到達， 任務的執行時間爲指數分佈，期望是100ms，同一個作業中的所有任務執行時間相等。測試結果如圖3， 響應時間隨着負載增加而增加，這是由於工作機器隊列變長導致的等待時間變長。在80%負載時，單任務採樣比隨機分配表現好3倍，不過比起貪心調度，依然造成2.6倍的響應時間。
3.3 批採樣
批採樣通過共享一個作業中所有任務的探測信息來優化單任務採樣[18]。單任務採樣中一對探測可能運氣不好得到2個重負載機器的採樣如圖（2a中的任務1），而另外一對探測器得到2個輕負載機器的採樣（如圖2a中的任務2），這樣會增加作業的響應時間。批採樣聚集所有任務的探測信息，然後將m個任務分配到負載最輕的機器上。如果2，單任務採樣選擇了隊列長度爲1和3的兩個機器，批採樣選擇了隊列長度爲1和2的兩個機器。
使用批採樣調度時，調度器隨機選擇dm個工作機器，調度器發送探測到這dm個機器，每個機器回覆一個隊列長度的值，然後調度器分配任務到最低負載的m個機器上，如果我們選擇d=2，那麼我們就得到了2b圖。
如圖3，在80%負載的時候，批採樣的平均響應時間只有單任務採樣的73%。不過依然是貪心調度的192%。
3.4 基於採樣調度的問題
基於採樣的調度在高負載時表現不好有兩個原因。第一，調度器根據隊列長度來做決策，但是隊列長度只是等待時間一個粗略的預測。即使工作機器回覆任務執行時間，要準確預測任務執行時間也是相當有難度的。
採樣同時存在條件競爭的問題，當多個調度器並行執行，並在一個工作機器上做決策時[13]，調度器獲得的回覆就不是那麼準確了。考慮兩個不同的調度器同時探測到一個空閒的工作機器w，兩個調度器肯定分配任務到w上，然後只有一個調度器真正的將任務分配到了空隊列上，因爲對另一個調度器來說，信息過時了。如果這個調度器知道w不是空的話，他可能就不會分配任務到w了。
3.5 晚綁定
Sparrow使用晚綁定來解決後一個問題。使用晚綁定，工作機器不直接回復探測，而是在任務隊列末端預留一個位置。當預留位置達到隊列的前端，工作機器再發送一個RPC給調度器。調度器爲先回復的m個工作機器分配任務，然後給剩餘的（d-1）m個工作機器回覆無操作信號。在這麼情況下，調度器保證任務會被分配到m個最早開始任務的機器上。對於執行時間爲指數分佈的任務，在80%負載的情況下， 晚綁定的平均響應時間爲只使用批採樣的55%，跟貪心調度器的差距只有5%（如圖3）。
晚綁定的缺點在於當工作節點發送RPC去請求任務時，他正處於空閒。所有我們知道的集羣調度器都做了權衡：調度器等到工作節點發送消息表示它有足夠的資源時才分配任務。根據我們的設定目標，這個權衡相比不採用晚綁定導致了2%的效率損失。工作節點空閒的比率是（d*RTT）/（t+d*RTT）（d指每個任務的探測數，t指平均任務執行時間）。根據我們在EC2上的未經優化的部署，平均RTT是1ms。我們期望最短的任務能在100ms內完成，我們使用的探測係數不會超過2， 以上數據得出會造成不超過2%的效率損失。對於我們的目標工作量，這個權衡是值得的。圖3的數據是合併了網絡延時的。在某些網絡延時跟任務運行時間同等數量級的情況下，晚綁定就不值得了。
3.6 主動取消
當調度器發射了一個作業的所有任務後，它有兩種方式來處理預留的探測：主動發射一個取消RPC到工作機器，或者等待工作機器請求任務，然後回覆工作機器任務已發完。我們使用模擬來研究主動取消的效果，發現當負載爲95%時，主動取消可以降低平均響應時間6個百分點。負載爲ρ時，工作機器的空閒時間實際少於1-ρ：它使用ρ的時間執行任務，但是還需要額外的時間來從調度器請求任務。在1ms RTT， 探測係數爲2，任務平均執行時間爲100ms時，使用主動取消會使得工作機器的忙時間平均降低1%。當負載趨近100%時，響應時間接近無限，工作機器忙時間降低1%會導致明顯的響應時間減少。當工作機器接受到主動取消前已經發送任務請求時，會導致額外的RPC：在95%的負載下，主動取消導致2%的額外RPC。我們認爲這額外的RPC相比提升的性能是值得的權衡，我們實現的Sparrow也包含了主動取消功能。當網絡延時對比任務執行時間比率越高時主動取消作用越明顯。
4 調度政策和限制
Sparrow支持一小部分有用的政策。本節介紹兩種重要的調度政策：限制任務的運行機器，資源緊張時，用戶間優先級問題。
4.1 處理放置限制
Sparrow處理兩種限制，按作業限制和按任務限制。這些限制在數據並行框架下非常常見，比如限制任務智能被分配到包含任務輸入數據的機器上運行。如第二節提到的，Sparrow不支持一些通用的資源管理限制。
平凡的按作業限制（比如該作業所有的任務必須在包含GPU的機器上運行）是受Sparrow支持的。Sparrow從滿足限制條件的機器中隨機選取dm個備選，然後按照之前的方式調度。
Sparrow也支持作業內的按任務限制，比如限制任務到包含其輸入數據的機器上運行。把任務分配到數據旁會減少響應時間，因爲數據不需要傳過網絡。對於作業內的按任務限制，每個任務都有不同的運行機器集，所以Sparrow不能使用批採樣來調度。相反Sparrow採用單任務採樣，調度器選擇兩個滿足限制條件的機器探測，並且可以使用晚綁定。
儘管Sparrow在處理按任務限制時不能使用批採樣，Sparrow仍然能提供接近最優的響應時間，畢竟對於單任務限制，集中調度器也沒有多少選擇。按任務限制的作業仍然能夠使用晚綁定，這就保證了任務能儘可能早的獲得機器。如HDFS的存儲方案會備份數據到3個地方，所以即使貪心調度也僅多一個額外選擇。
4.2 資源分配政策
當需求的資源和超過資源的總量時，Sparrow調度器儘可能按照政策分配資源。Sparrow支持兩種調度政策：嚴格優先級和加權公平分享。
Sparrow通過保持多個隊列來支持一下的政策：FIFO， 早截至時間優先， 短任務優先。這些政策都可以規約成爲每個作業分配優先級，然後高運行級優先。集羣操作器有時也會希望直接分配優先級。爲了支持這些政策，Sparrow爲每個優先級保持一個隊列，當資源足夠時，Sparrow先回應高優先隊列的預定。由於隨機選擇備用機器加上節點不使用複雜的協議來交互信息，低優先級的任務可能比高優先級的任務先執行。我們相信這是一個值得的權衡，因爲這種機制對高優先級任務提供了良好的性能。Sparrow目前不支持搶佔。
Sparrow也支持加權公平分享。每個機器對每個用戶維持一個不同的隊列，然後在這些隊列上運行加權公平排隊。這個機制按預期提供了集羣範圍的公平：使用同一個機器的兩個用戶會得到他們權重比的資源，同樣，使用同一個機器集的用戶會得到他們權重比的資源。我們使用這個簡單的機制是因爲更加精確的機制會導致問題變得複雜。Sparrow簡單的機制提供了接近完美的表現。