記得從去年第一次在組會上講論文時講了Christina Delimitrou的HCloud論文後，陸陸續續的一直在讀她的論文，並在今年4月份的ASPLOS和她有了一張合影（當時我心裏的那個忐忑啊，想和她搭訕又不敢）。
這篇論文發表自2014年的ASPLOS（這些年她好像每年都會中一篇ASPLOS，膜拜），依舊是關於數據中心非常棘手的一個問題：現在數據中心的成本都非常高，各大廠商都在努力提高集羣的性能和靈活度來達到很高的經濟效益，但是現在大部分的集羣資源利用率依舊非常的低（前段時間和阿里雲的大佬們聊時瞭解到，阿里雲現在的集羣平均利用率能達到40%，目標是希望能達到60%），這樣嚴重的影響到了公司的經濟效益和以後集羣的擴展性。
這篇文章提出了Quasar，它通過對負載需要的資源進行預測和自動分配來對集羣進行管理，同時提高資源利用率並保證應用的性能不受影響。它整個框架分爲三部分。
- Quasar提供了一個高層次的接口來讓用戶描述它們對負載的性能需求給調度器，不同的負載對性能的需求不同，當然接口也不相同。對於分佈式框架如hadoop，其限制條件就是執行的時間；對於延遲敏感型應用，限制條件則爲每秒鐘的查詢次數和延遲QoS的限制等。
- Quasar使用了快速分類技術對不同的負載進行評估，例如不同的資源和不同的資源調度對負載的性能會產生什麼樣的影響？分類的結果就是準確的估計了當我們考慮了不同數目的服務器、單個服務器上的資源數量和來自其他負載的干擾時該負載的性能，Quasar通過將分類評估的問題分解爲幾個小的部分來降低了分類的複雜度。
- Quasar使用第二部分的分類結果來進行資源的分配，它同時使用了監控系統，當機器有空閒資源的情況下，負載的性能沒有得到滿足（即使負載發生了變化，例如job內部階段發生了變化）都說明這個分類是不正確的或者貪心算法導致了次優解，無論是是什麼導致分類不正確，只要條件允許Quasar都會調整資源的分配或者重新對負載進行分類和調度。
Quasar的代碼行數我是非常詫異的，只有6K代碼，增加一個應用也只需要幾百行代碼，在這樣的前提下能對應用性能帶來那麼大的提升真的很贊。
- Single batch job（純粹hadoop）：平均提升29%到58%。
- Multiple Batch Frameworks performance(Hadoop,Storm, and Spark混合)：提升27%。
- Large-Scale Cloud Provider：從15%的cpu利用率提升到62%,提升47%。