管理Spark 2.0實現(xiàn)動態(tài)擴容實踐實例分析

　　“去年10月，去哪兒網實現(xiàn)了Spark 1.5.2版本運行在Mesos資源管理框架上。目前，線上已經注冊了44 個Spark任務，在運行這些任務的過程中，他們遇到的最大的問題就是動態(tài)擴容問題。 ”

　　背景

　　去年10月，我們實現(xiàn)了Spark 1.5.2版本運行在Mesos這個資源管理框架上。隨后Spark出了新版本我們又對Spark進行了小升級，升級并沒有什么太大的難度，沿用之前的修改過的代碼重新編譯，替換一下包，把歷史任務全部發(fā)一遍就能很好的升級到1.6.1也就是現(xiàn)在集群的版本，1.6.2并沒有升級因為感覺改動不是很大。到現(xiàn)在正好一年的時間，線上已經注冊了44 個Spark任務，其中28個為Streaming任務，在運行這些任務的過程中，我們遇到了很多問題，其中最大的問題是動態(tài)擴容問題，即當業(yè)務線增加更復雜的代碼邏輯或者業(yè)務的增長導致處理量上升的時候會使Spark因計算資源不足，這時候如果沒有做流量控制則Spark任務會因內存承受不了而失敗，如果做了流量控制則Kafka的lag會有堆積，這時候一般就需要增加更多的executor來處理，但是增加多少合適一般不太好判斷，于是要反復地修改配置重新發(fā)布來找到一個合理的配置。

　　我們在Marathon上使用Logstash的時候也有類似的問題，當由于接入一個比較大的日志導致流量突然增加使得Logstash處理不了時，Kafka的Lag產生堆積，這時我們只需直接上Marathon的界面上點Scale然后填入更大的實例數字就能啟動了一些Logstash實例自動平衡地去處理了。當發(fā)現(xiàn)某個結點是慢結點不干活的時候，只需要在Marathon上將對應的任務Kill掉就會自動再發(fā)一個任務替補他的位置，那么Logstash既然都可以做到為什么Spark不可以？因此我們決定在Spark 2.0版本的時候來實現(xiàn)這個功能，同時我們也會改進其它的一些問題，另外Spark2.0是一個比較大的版本升級，配置與之前的1.6.1不同，不能做到直接全部重發(fā)一遍任務來做到全部升級。

　?。?圖1）使用Logstash的管理架構

　　Mesos-dispacher架構與問題

　　在這里我們首先介紹一些Mesos的一些相關概念，Mesos的Framework是資源分配與調度的發(fā)起者，Spark自帶了一個spark-mesos-dispacher的Framework用來管理Spark的資源調度。而Marathon也是一個Framework他的本質和mesos-dispacher或spark schedular相同。

　?。▓D2）Mesos-dispacher架構

　　在圖2在這個架構中，你首先得向mesos注冊一個mesos-dispacher的Framework，然后，通過spark-sumbit腳本來向mesos-dispacher發(fā)布任務，mesos-dispacher接到任務以后開始調度他負責發(fā)一個Spark Driver，然后driver在mesos模式下，他會再次向mesos注冊這個任務的Framework也就是我們看到的Spark UI，也可以理解為他自己也是個調度器，然后這個Framework根據配置來向Mesos申請資源來發(fā)一些Spark Executor。