管理Spark 2.0實現(xiàn)動態(tài)擴容實踐實例分析
“去年10月，去哪兒網(wǎng)實現(xiàn)了Spark 1.5.2版本運行在Mesos資源管理框架上。目前，線上已經(jīng)注冊了44 個Spark任務(wù)，在運行這些任務(wù)的過程中，他們遇到的最大的問題就是動態(tài)擴容問題。 ”
背景
去年10月，我們實現(xiàn)了Spark 1.5.2版本運行在Mesos這個資源管理框架上。隨后Spark出了新版本我們又對Spark進(jìn)行了小升級，升級并沒有什么太大的難度，沿用之前的修改過的代碼重新編譯，替換一下包，把歷史任務(wù)全部發(fā)一遍就能很好的升級到1.6.1也就是現(xiàn)在集群的版本，1.6.2并沒有升級因為感覺改動不是很大。到現(xiàn)在正好一年的時間，線上已經(jīng)注冊了44 個Spark任務(wù)，其中28個為Streaming任務(wù)，在運行這些任務(wù)的過程中，我們遇到了很多問題，其中最大的問題是動態(tài)擴容問題，即當(dāng)業(yè)務(wù)線增加更復(fù)雜的代碼邏輯或者業(yè)務(wù)的增長導(dǎo)致處理量上升的時候會使Spark因計算資源不足，這時候如果沒有做流量控制則Spark任務(wù)會因內(nèi)存承受不了而失敗，如果做了流量控制則Kafka的lag會有堆積，這時候一般就需要增加更多的executor來處理，但是增加多少合適一般不太好判斷，于是要反復(fù)地修改配置重新發(fā)布來找到一個合理的配置。
我們在Marathon上使用Logstash的時候也有類似的問題，當(dāng)由于接入一個比較大的日志導(dǎo)致流量突然增加使得Logstash處理不了時，Kafka的Lag產(chǎn)生堆積，這時我們只需直接上Marathon的界面上點Scale然后填入更大的實例數(shù)字就能啟動了一些Logstash實例自動平衡地去處理了。當(dāng)發(fā)現(xiàn)某個結(jié)點是慢結(jié)點不干活的時候，只需要在Marathon上將對應(yīng)的任務(wù)Kill掉就會自動再發(fā)一個任務(wù)替補他的位置，那么Logstash既然都可以做到為什么Spark不可以？因此我們決定在Spark 2.0版本的時候來實現(xiàn)這個功能，同時我們也會改進(jìn)其它的一些問題，另外Spark2.0是一個比較大的版本升級，配置與之前的1.6.1不同，不能做到直接全部重發(fā)一遍任務(wù)來做到全部升級。
（ 圖1）使用Logstash的管理架構(gòu)
Mesos-dispacher架構(gòu)與問題
在這里我們首先介紹一些Mesos的一些相關(guān)概念，Mesos的Framework是資源分配與調(diào)度的發(fā)起者，Spark自帶了一個spark-mesos-dispacher的Framework用來管理Spark的資源調(diào)度。而Marathon也是一個Framework他的本質(zhì)和mesos-dispacher或spark schedular相同。
（圖2）Mesos-dispacher架構(gòu)
在圖2在這個架構(gòu)中，你首先得向mesos注冊一個mesos-dispacher的Framework，然后，通過spark-sumbit腳本來向mesos-dispacher發(fā)布任務(wù)，mesos-dispacher接到任務(wù)以后開始調(diào)度他負(fù)責(zé)發(fā)一個Spark Driver，然后driver在mesos模式下，他會再次向mesos注冊這個任務(wù)的Framework也就是我們看到的Spark UI，也可以理解為他自己也是個調(diào)度器，然后這個Framework根據(jù)配置來向Mesos申請資源來發(fā)一些Spark Executor。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%