這篇論文發自SOSP 2013，又是AMPLAB的牛文（就是發Spark的那個組）。
一作是Kay Ousterhout，有幸在10月底在上海開的SOSP大會上目睹作者真容，她今年在SOSP斬獲兩篇文章，已經從 UC Berkeley 畢業了，現在自己創業公司名爲Kelda。她在Ada Workshop上分享了自己做學術的這麼一個經驗，有機會寫篇博客分享一下。
以下爲正文。
當下的數據分析集羣運行越來越多的短作業，這些短作業要求調度器能有很低的延遲、高併發和高吞吐，這一需求也在不斷地推動工業界和學術界尋求新的方法。
調度毫秒級別的短作業作業對調度器來說是一個巨大的挑戰，Sparrow就是在這樣的背景下被提出來，其針對於短作業來實現高併發和低延遲。
Sparrow是一個分佈式調度器，其不同於現在工業界用的單體式調度器，單體式調度器是整個集羣只有一個調度器來處理所有提交的作業，爲這些作業分配運行的機器，中心式可以看到整個集羣每個節點的狀態、資源使用量和空閒資源量等信息，調度器可以爲新來的作業分配空閒資源比較多的機器；但是分佈式調度器是集羣中有多個調度器，這些調度器分散在不同的節點上，這些調度器各自爲戰，相互之間沒有溝通，當有新的作業提交到調度器上後，調度器不會馬上爲其分配運行的機器（因爲調度器並不知道哪些機器有空閒資源），調度器會基於一定的規則去隨機探測集羣中的節點狀態，來尋找“最合適的”節點來運行作業（只能說是相對最合適）。
以上圖（a）爲例，當有兩個作業到達一個調度器後，這個調度器會爲每個作業在集羣中隨機選擇2個機器來發送探測（RPC），比如調度器爲task1探測了上面兩個機器，爲task2探測了下面兩個機器，哪個機器排隊的作業比較少則把作業放到哪個機器上運行（假設每個作業的運行時間是相同的）。由下圖的實驗結果可以看出，這種單作業採樣（per-task sampling）比調度器隨機放置的效果要好很多。但是，這裏要思考一個問題，以上圖爲例，2個作業一共探測了4臺機器，其中第二個作業探測的兩臺機器明顯是比第一臺探測的兩個機器排隊的作業要少一些，但是task1只能選擇它探測的那兩臺機器，這種問題怎麼解決呢？
爲了避免這種問題，作業提出了批作業採樣（batch samping），如上圖（b）爲例，對m個作業（m=2），每個作業探測d臺機器（d=2），然後調度器根據這m*d個探測信息來選擇其中最合適的m臺機器，並把作業調度到這些機器上運行。由下圖的實驗結果可以看出，這種batch samping的方法，比per task的效果要更好一些。
但是，以上都是基於每個作業的運行時間都是相同的假設來進行的，但是現實中每個task的作業是不相同的，這樣會出現以下兩種問題。
- 因爲多個調度器之間是獨立工作，互不溝通的，如果出現多個調度器同時把作業調度到這一個機器上該怎麼辦？那麼這臺機器相對於這些作業來說可能就不是“最合適的”了。
- 現在的作業調度是根據探測時返回的機器作業隊列爲依據的，但也會出現這種情況：一臺機器上有兩個作業在排隊，但是每個作業只需要10ms就可以運行結束；另外一臺機器上只有一個作業在排隊，但是這個作業需要100ms才能運行結束。按照現在的策略來說，調度器會將作業調度到只有1個作業排隊的機器上，這樣顯然是不合理的。
爲了解決這個問題，作者提出了後期綁定（Late binding）這樣一種方式。以一個生活中的例子來解釋，比如你現在在家非常非常餓，自己心目中已經選好了你最愛喫的幾家餐廳，但是這些餐廳都太火爆了，每天都要排隊，那怎麼知道排哪個隊伍能最快喫到飯呢？這時可以掏出手機，網上進行排號，當排號排到自己時參訂會把位置預留下來並打電話給你，告訴你排隊排到啦，位置也給你留着啦，趕快來喫飯啊~ 這樣就可以在家坐等電話響就可以了，並且也能保證最快喫到飯。
後期綁定就是用這樣的方法，調度器會對m*d個機器發送探測信息，當機器收到這些探測信息時，他們不急着返回信息給調度器，他們先預先留一個位置在作業的隊尾（排隊），當排隊排到的時候再向調度器返回信息，調度器則根據最先返回信息的m臺機器來調度作業。當m個作業都調度完畢後，調度器會告訴剩下的機器，不用再返回信息啦，我們這邊已經調度完了，或者等這些機器返回信息後再告訴他們已經沒有可以調度的作業了。
由上圖的實驗結果可以看到，使用了late binding的bach sampling的方法的小夥比前幾種都要好。
整篇文章的結構特別的好，層層遞進，容易理解，以後要多學一學這樣的寫作風格~