SOSP'17 Monotasks: Architecting for Performance Clarity in Data AnalyticsnFrameworks

Monotasks: Architecting for Performance Clarity in Data Analytics Frameworks

Kay Ousterhout (UC Berkeley); Christopher Canel (Carnegie Mellon University);

這篇論文收錄在Resource management Session內。

背景

論文第一作者Kay Ousterhout是UC Berkeley NetSys Lab的Ph.D.，師從Sylvia Ratnasamy (該論文第三作者，DHT的創始人之一) 。Ph.D.期間主要精力都放在對Spark等大數據分析平台進行性能分析。本文也是從Performance Clarity角度來重新設計了data analytics framework。論文第四作者Scott Shenker是網路界大佬，SDN運動的主要開創人之一，OpenFlow paper的作者之一，ONF的聯合創始人。

這是一篇很有趣的文章，作者認為一個系統在設計的時候就應該把Performance Clarity作為目標之一，而非像目前data analytics framework的做法，事後考慮。論文作者基於Spark，重新設計了一種新的架構MonoSpark，代碼已開源（https://github.com/NetSys/spark-monotasks）。

解決的問題：

如今在使用data analytics framework時，用戶需要根據所運行的任務和數據規模來選擇合適Configuration（比如該使用多少機器，該使用什麼配置的VM，該分配多少內存CPU資源）。優化Configuration對用戶來說是一個很頭疼的事情，主要原因是因為目前的是data analytics framework在設計的時候，並沒有從Performance

Clarity*角度出發。比如在目前的frameworks里，用戶很難回答如下問題：

1． 我是否需要足夠大的內存來對硬碟數據進行Cache？

2． 如果我將網路帶寬從1Gbps升級到10Gbps，我的任務能獲得多少的性能提升？

3． 我是否需要對數據存儲進行壓縮？

4． 每台機器應該處理多少數據？

5． 我的任務有沒有因為與其他用戶的資源競爭而受到影響？

Performance Clarity*: 用戶能清楚地知道系統的瓶頸在哪裡，並且能預測任務在不同Configuration時的表現。

雖然最近幾年已有諸如Ernest [1] 和 CherryPick [2] 這樣工作來為任務選擇合適的Configuration（有時間的話，筆者會專門寫一篇文章介紹這兩篇工作）。但是這些工作只是找到好的Configuration，由於Performance Clarity的原因，它們仍然無法回答上面那些問題。本文作者認為，目前的data analytics framework在Performance Clarity上表現很差的原因是：目前的架構使用的都是fine-grained pipelining，而每個Task對不同資源（CPU，Disk I/O，網路I/O）的使用是non-uniform的。當有多個task同時使用某個資源時，就會導致資源競爭。然而在目前的framework里，對競爭資源調度是由操作系統而非framework來負責的。如此一來，framework就很難獲取和掌控每種資源對任務的影響，從而導致Performance Clarity很差。

解決方法和結果：

為了讓framework能夠掌控底層資源的調度，作者對Task使用的資源進行了解耦。本文提出了Monotask的概念：將原來的一個task分割成若干個monotasks，每個monotask只使用一種資源。如此一來，對於同一資源的競爭就只會出現在使用同一種資源的多個monotasks之中。Framework可以通過在每個資源上安排Scheduler來掌控對每個資源的調度。下圖舉了個例子：圖(a)為傳統的fine-grained pipelining，圖(b)為分解後的monotasks的調度。從例子中我們可以發現，當任務被分解成monotask後，由每個資源的scheduler來負責調度對應資源的monotask。通過將task分解成monotask，我們可以清楚的知道一個任務在每種資源上花費了多長時間，又有多大程度地受到了其他task的影響。整個過程更加清晰可控。

但是將task分解成多個monotask的代價就是一個task無法同時使用多種資源（比如在網路傳輸的同時進行數據讀取），會導致一個task的執行時間變長。作者提出的解決方法是將一個job分解成足夠多的multitasks，從而使得同一job的多個獨立的monotask可以構成pipelining。值得一提的是，本文作者Kay Ousterhout在HotOS13時提出的 TinyTask [3] 也使用了將一個task分解成很多tinytask的idea，來減少straggler和提高resource sharing。

作者將Monotask的idea實現在Spark上，實驗結果表明在損失最多9%的執行時間時，系統的Performance Clarity得到了大幅提高。使用Monotask預測一個任務在不同軟體和硬體配置環境下的執行時間的誤差最多為28%。

該系統存在的問題：

1. Jobs with few tasks: 在上面的介紹中，我們已經提到了本文的做法需要很多monotask才能充分利用pipelining。如果一個job的task很少，則需要手動增加這個任務的task個數才能導出更多的monotask。

2. Jobs with large tasks: 當一個task的中間很大，無法放到內存中時，傳統的做法是臨時存到硬碟里，最後再合併。而MonoSpark的設計則要求所有數據必須能夠存在內存里，當task數據很大時則需要將該job切割成更多的小規模的multistasks。

3. Scheduling: MonoSpark的 Disk Scheduling和Multitask Scheduling都比較簡單。比如Disk scheduling只是將disk request在多個disk上做load balance，而不是根據load。

[1] Venkataraman, Shivaram, et al. "Ernest: Efficient Performance Prediction for Large-Scale Advanced Analytics." NSDI. 2016.

[2] Alipourfard, Omid, et al. "CherryPick: Adaptively Unearthing the Best Cloud Configurations for Big Data Analytics." NSDI. 2017.

[3] Ousterhout, Kay, et al. "The Case for Tiny Tasks in Compute Clusters." HotOS. Vol. 13. 2013.