1. 程式人生 > >Spark四種分散式部署方式比較

Spark四種分散式部署方式比較

Apache Spark支援種分散式部署方式,分別是standalonespark on mesos spark on YARNKubernetes 其中,第一種類似於MapReduce 1.0所採用的模式,內部實現了容錯性和資源管理,後兩種則是未來發展的趨勢,部分容錯性和資源管理交由統一的資源管理系統完成:讓Spark執行在一個通用的資源管理系統之上,這樣可以與其他計算框架,比如MapReduce,公用一個叢集資源,最大的好處是降低運維成本和提高資源利用率(資源按需分配)。本文將介紹這種部署方式,並比較其優缺點。

standalone模式

即獨立模式,自帶完整的服務,可單獨部署到一個叢集中,無需依賴任何其他資源管理系統。從一定程度上說,該模式是其他兩種的基礎。借鑑

Spark開發模式,我們可以得到一種開發新型計算框架的一般思路:先設計出它的standalone模式,為了快速開發,起初不需要考慮服務(比如master/slave)的容錯性,之後再開發相應的wrapper,將stanlone模式下的服務原封不動的部署到資源管理系統yarn或者mesos上,由資源管理系統負責服務本身的容錯。目前Sparkstandalone模式下是沒有任何單點故障問題的,這是藉助zookeeper實現的,思想類似於Hbase master單點故障解決方案。將Spark standaloneMapReduce比較,會發現它們兩個在架構上是完全一致的:

1)  都是由master/slaves

服務組成的,且起初master均存在單點故障,後來均通過zookeeper解決(Apache MRv1JobTracker仍存在單點問題,但CDH版本得到了解決);

2) 各個節點上的資源被抽象成粗粒度的slot,有多少slot就能同時執行多少task。不同的是,MapReduceslot分為map slotreduce slot,它們分別只能供Map TaskReduce Task使用,而不能共享,這是MapReduce資源利率低效的原因之一,而Spark則更優化一些,它不區分slot型別,只有一種slot,可以供各種型別的Task使用,這種方式可以提高資源利用率,但是不夠靈活,不能為不同型別的

Task定製slot資源。總之,這兩種方式各有優缺點。

Spark On Mesos模式

這是很多公司採用的模式,官方推薦這種模式(當然,原因之一是血緣關係)。正是由於Spark開發之初就考慮到支援Mesos,因此,目前而言,Spark執行在Mesos上會比執行在YARN上更加靈活,更加自然。目前在Spark On Mesos環境中,使用者可選擇兩種排程模式之一執行自己的應用程式(可參考Andrew XiaMesos Scheduling Mode on Spark):

1)   粗粒度模式(Coarse-grained Mode):每個應用程式的執行環境由一個Dirver和若干個Executor組成,其中,每個Executor佔用若干資源,內部可執行多個Task(對應多少個“slot”)。應用程式的各個任務正式執行之前,需要將執行環境中的資源全部申請好,且執行過程中要一直佔用這些資源,即使不用,最後程式執行結束後,回收這些資源。舉個例子,比如你提交應用程式時,指定使用5executor執行你的應用程式,每個executor佔用5GB記憶體和5CPU,每個executor內部設定了5slot,則Mesos需要先為executor分配資源並啟動它們,之後開始排程任務。另外,在程式執行過程中,mesosmasterslave並不知道executor內部各個task的執行情況,executor直接將任務狀態通過內部的通訊機制彙報給Driver,從一定程度上可以認為,每個應用程式利用mesos搭建了一個虛擬叢集自己使用。

2)   細粒度模式(Fine-grained Mode):鑑於粗粒度模式會造成大量資源浪費,Spark On Mesos還提供了另外一種排程模式:細粒度模式,這種模式類似於現在的雲端計算,思想是按需分配。與粗粒度模式一樣,應用程式啟動時,先會啟動executor,但每個executor佔用資源僅僅是自己執行所需的資源,不需要考慮將來要執行的任務,之後,mesos會為每個executor動態分配資源,每分配一些,便可以執行一個新任務,單個Task執行完之後可以馬上釋放對應的資源。每個Task會彙報狀態給Mesos slaveMesos Master,便於更加細粒度管理和容錯,這種排程模式類似於MapReduce排程模式,每個Task完全獨立,優點是便於資源控制和隔離,但缺點也很明顯,短作業執行延遲大。

Spark On YARN模式

這是一種最有前景的部署模式。但限於YARN自身的發展,目前僅支援粗粒度模式(Coarse-grained Mode)。這是由於YARN上的Container資源是不可以動態伸縮的,一旦Container啟動之後,可使用的資源不能再發生變化,不過這個已經在YARN計劃中了。

spark on yarn 的支援兩種模式:

     1) yarn-cluster:適用於生產環境;
     2) yarn-client:適用於互動、除錯,希望立即看到app的輸出

yarn-clusteryarn-client的區別在於yarn appMaster,每個yarn app例項有一個appMaster程序,是為app啟動的第一個container;負責從ResourceManager請求資源,獲取到資源後,告訴NodeManager為其啟動containeryarn-clusteryarn-client模式內部實現還是有很大的區別。如果你需要用於生產環境,那麼請選擇yarn-cluster;而如果你僅僅是Debug程式,可以選擇yarn-client

Kubernetes模式

後續補充。。。

總結: 

這四種分散式部署方式各有利弊,通常需要根據實際情況決定採用哪種方案。進行方案選擇時,往往要考慮公司的技術路線(採用Hadoop生態系統還是其他生態系統)、相關技術人才儲備等。上面涉及到Spark的許多部署模式,究竟哪種模式好這個很難說,需要根據你的需求,如果你只是測試Spark Application,你可以選擇local模式。而如果你資料量不是很多,Standalone 是個不錯的選擇。當你需要統一管理叢集資源(HadoopSpark等),那麼你可以選擇Yarn或者mesos,但是這樣維護成本就會變高。
· 從對比上看,mesos似乎是Spark更好的選擇,也是被官方推薦的
· 但如果你同時執行hadoopSpark,從相容性上考慮,Yarn是更好的選擇。 · 如果你不僅運行了hadoopspark。還在資源管理上運行了dockerMesos更加通用。

· Standalone對於小規模計算叢集更適合!

參考博文:

官網參考