Spark on mesos的坑以及解決辦法

該文章寫於spark1.6.2版本。
由於Fine mode對短任務效能影響過大，所以採用的是Coarse mode方式進行排程。

主要的一些問題：

1. 1.6版本開始dynamic allocation無法使用

   例如spark-shell之類的程式，空閒時期資源長期佔用卻無法釋放，造成資源利用率低下。

2. 單個slave上無法啟動多個executor

   每個mesos slave上一個application只能啟動一個executor。帶來的問題是，如果你的slave是<20 cores,100G RAM>，一個需求<20 cores，10G RAM>的application就會將其資源用光，造成90G RAM的浪費。
   具體可參考http://www.jianshu.com/p/27762a1f9b7b

3. 每個executor使用的cpu數量不可控

   例如某個application申請<5 cores,10G RAM>，如果每個slave只有4 cores,就會造成出現的兩個executor,一個是<4 cores,10G RAM>，另一個是<1 core, 10G RAM>。
   因為一個executor執行了過多的task，在記憶體不足的情況下就非常容易造成OOM,長時間GC等問題。
   具體可參考http://www.jianshu.com/p/27762a1f9b7b

4. blockmgr沒有自動刪除
   大量佔用磁碟空間

這些問題都在2.0中得到了解決，但是2.0的改動較大，涉及到大量程式的修改，所以就將如下的改進和bugfix都合到了1.6.2上，重新build了一個版本，問題解決。

已有的解決方案：

• [SPARK-12330][MESOS] Fix mesos coarse mode cleanup
• [SPARK-13002][MESOS] Send initial request of executors for dyn allocation
• [SPARK-5095][MESOS] Support launching multiple mesos executors in coarse grained mesos mode.
• [SPARK-12583][MESOS] Mesos shuffle service: Don't delete shuffle files before application has stopped
• [SPARK-13001][CORE][MESOS] Prevent getting offers when reached max cores

修復後的叢集濟源利用率

修改後的叢集負載情況(ganglia):

這裡寫圖片描述

修改後的叢集負載情況(ganglia):

這裡寫圖片描述