Apache Spark支持四種分布式部署方式，分別是standalone、spark on?mesos和 spark on?YARN，Kubernetes?其中悯姊，第一種類似于MapReduce 1.0所采用的模式，內(nèi)部實現(xiàn)了容錯性和資源管理贩毕，后兩種則是未來發(fā)展的趨勢悯许，部分容錯性和資源管理交由統(tǒng)一的資源管理系統(tǒng)完成：讓Spark運行在一個通用的資源管理系統(tǒng)之上，這樣可以與其他計算框架辉阶，比如MapReduce先壕，公用一個集群資源，最大的好處是降低運維成本和提高資源利用率（資源按需分配）睛藻。本文將介紹這四種部署方式启上，并比較其優(yōu)缺點。
standalone模式
即獨立模式店印，自帶完整的服務冈在，可單獨部署到一個集群中，無需依賴任何其他資源管理系統(tǒng)按摘。從一定程度上說包券，該模式是其他兩種的基礎纫谅。借鑒Spark開發(fā)模式，我們可以得到一種開發(fā)新型計算框架的一般思路：先設計出它的standalone模式溅固，為了快速開發(fā)付秕，起初不需要考慮服務（比如master/slave）的容錯性，之后再開發(fā)相應的wrapper侍郭，將stanlone模式下的服務原封不動的部署到資源管理系統(tǒng)yarn或者mesos上询吴，由資源管理系統(tǒng)負責服務本身的容錯。目前Spark在standalone模式下是沒有任何單點故障問題的亮元，這是借助zookeeper實現(xiàn)的猛计，思想類似于Hbase master單點故障解決方案。將Spark standalone與MapReduce比較爆捞，會發(fā)現(xiàn)它們兩個在架構上是完全一致的：
1) ?都是由master/slaves服務組成的奉瘤，且起初master均存在單點故障，后來均通過zookeeper解決（Apache MRv1的JobTracker仍存在單點問題煮甥，但CDH版本得到了解決）盗温；
2) 各個節(jié)點上的資源被抽象成粗粒度的slot，有多少slot就能同時運行多少task成肘。不同的是卖局，MapReduce將slot分為map slot和reduce slot，它們分別只能供Map Task和Reduce Task使用艇劫，而不能共享吼驶，這是MapReduce資源利率低效的原因之一，而Spark則更優(yōu)化一些店煞，它不區(qū)分slot類型，只有一種slot风钻，可以供各種類型的Task使用顷蟀，這種方式可以提高資源利用率，但是不夠靈活骡技，不能為不同類型的Task定制slot資源鸣个。總之布朦，這兩種方式各有優(yōu)缺點囤萤。
Spark On Mesos模式
這是很多公司采用的模式，官方推薦這種模式（當然是趴，原因之一是血緣關系）涛舍。正是由于Spark開發(fā)之初就考慮到支持Mesos，因此唆途，目前而言富雅，Spark運行在Mesos上會比運行在YARN上更加靈活掸驱，更加自然。目前在Spark On Mesos環(huán)境中没佑，用戶可選擇兩種調(diào)度模式之一運行自己的應用程序（可參考Andrew Xia的“Mesos Scheduling Mode on Spark”）：
1) ? 粗粒度模式（Coarse-grained Mode）：每個應用程序的運行環(huán)境由一個Dirver和若干個Executor組成毕贼，其中，每個Executor占用若干資源蛤奢，內(nèi)部可運行多個Task（對應多少個“slot”）鬼癣。應用程序的各個任務正式運行之前，需要將運行環(huán)境中的資源全部申請好啤贩，且運行過程中要一直占用這些資源待秃，即使不用，最后程序運行結束后瓜晤，回收這些資源锥余。舉個例子，比如你提交應用程序時痢掠，指定使用5個executor運行你的應用程序驱犹，每個executor占用5GB內(nèi)存和5個CPU，每個executor內(nèi)部設置了5個slot足画，則Mesos需要先為executor分配資源并啟動它們雄驹，之后開始調(diào)度任務。另外淹辞，在程序運行過程中医舆，mesos的master和slave并不知道executor內(nèi)部各個task的運行情況，executor直接將任務狀態(tài)通過內(nèi)部的通信機制匯報給Driver象缀，從一定程度上可以認為蔬将，每個應用程序利用mesos搭建了一個虛擬集群自己使用。
2) ? 細粒度模式（Fine-grained Mode）：鑒于粗粒度模式會造成大量資源浪費央星，Spark On Mesos還提供了另外一種調(diào)度模式：細粒度模式霞怀，這種模式類似于現(xiàn)在的云計算，思想是按需分配莉给。與粗粒度模式一樣毙石，應用程序啟動時，先會啟動executor颓遏，但每個executor占用資源僅僅是自己運行所需的資源徐矩，不需要考慮將來要運行的任務，之后叁幢，mesos會為每個executor動態(tài)分配資源滤灯，每分配一些，便可以運行一個新任務，單個Task運行完之后可以馬上釋放對應的資源力喷。每個Task會匯報狀態(tài)給Mesos slave和Mesos Master刽漂，便于更加細粒度管理和容錯，這種調(diào)度模式類似于MapReduce調(diào)度模式弟孟，每個Task完全獨立贝咙，優(yōu)點是便于資源控制和隔離，但缺點也很明顯拂募，短作業(yè)運行延遲大庭猩。
Spark On YARN模式
這是一種最有前景的部署模式。但限于YARN自身的發(fā)展陈症，目前僅支持粗粒度模式（Coarse-grained Mode）蔼水。這是由于YARN上的Container資源是不可以動態(tài)伸縮的，一旦Container啟動之后录肯，可使用的資源不能再發(fā)生變化趴腋，不過這個已經(jīng)在YARN計劃中了。
spark on yarn 的支持兩種模式：?
? ? ?1) yarn-cluster：適用于生產(chǎn)環(huán)境论咏；?
? ? ?2) yarn-client：適用于交互优炬、調(diào)試，希望立即看到app的輸出?
yarn-cluster和yarn-client的區(qū)別在于yarn appMaster厅贪，每個yarn app實例有一個appMaster進程蠢护，是為app啟動的第一個container；負責從ResourceManager請求資源养涮，獲取到資源后葵硕，告訴NodeManager為其啟動container。yarn-cluster和yarn-client模式內(nèi)部實現(xiàn)還是有很大的區(qū)別贯吓。如果你需要用于生產(chǎn)環(huán)境懈凹，那么請選擇yarn-cluster；而如果你僅僅是Debug程序悄谐，可以選擇yarn-client蘸劈。
Kubernetes模式
后續(xù)補充。尊沸。。
總結：?
這四種分布式部署方式各有利弊贤惯，通常需要根據(jù)實際情況決定采用哪種方案洼专。進行方案選擇時，往往要考慮公司的技術路線（采用Hadoop生態(tài)系統(tǒng)還是其他生態(tài)系統(tǒng)）孵构、相關技術人才儲備等屁商。上面涉及到Spark的許多部署模式，究竟哪種模式好這個很難說，需要根據(jù)你的需求蜡镶，如果你只是測試Spark Application雾袱，你可以選擇local模式。而如果你數(shù)據(jù)量不是很多官还，Standalone 是個不錯的選擇芹橡。當你需要統(tǒng)一管理集群資源（Hadoop、Spark等）望伦，那么你可以選擇Yarn或者mesos林说，但是這樣維護成本就會變高。?
· 從對比上看屯伞，mesos似乎是Spark更好的選擇腿箩，也是被官方推薦的?
· 但如果你同時運行hadoop和Spark,從兼容性上考慮，Yarn是更好的選擇劣摇。 · 如果你不僅運行了hadoop珠移，spark。還在資源管理上運行了docker末融，Mesos更加通用钧惧。?
· Standalone對于小規(guī)模計算集群更適合！
---------------------
作者：菜鳥級的IT之路
來源：CSDN
原文：https://blog.csdn.net/WYpersist/article/details/79731621
版權聲明：本文為博主原創(chuàng)文章滑潘，轉載請附上博文鏈接垢乙！
