其中，***種類似于MapReduce 1.0所采用的模式，內(nèi)部實(shí)現(xiàn)了容錯(cuò)性和資源管理，后兩種則是未來(lái)發(fā)展的趨勢(shì)，部分容錯(cuò)性和資源管理交由統(tǒng)一的資源管理系統(tǒng)完成：讓Spark運(yùn)行在一個(gè)通用的資源管理系統(tǒng)之上，這樣可以與其他計(jì)算框架，比如MapReduce，公用一個(gè)集群資源，***的好處是降低運(yùn)維成本和提高資源利用率（資源按需分配）。本文將介紹這三種部署方式，并比較其優(yōu)缺點(diǎn)。

standalone模式，即獨(dú)立模式，自帶完整的服務(wù)，可單獨(dú)部署到一個(gè)集群中，無(wú)需依賴任何其他資源管理系統(tǒng)。從一定程度上說(shuō)，該模式是其他兩種的基礎(chǔ)。借鑒Spark開(kāi)發(fā)模式，我們可以得到一種開(kāi)發(fā)新型計(jì)算框架的一般思路：先設(shè)計(jì)出它的standalone模式，為了快速開(kāi)發(fā)，起初不需要考慮服務(wù)（比如master/slave）的容錯(cuò)性，之后再開(kāi)發(fā)相應(yīng)的wrapper，將stanlone模式下的服務(wù)原封不動(dòng)的部署到資源管理系統(tǒng)yarn或者mesos上，由資源管理系統(tǒng)負(fù)責(zé)服務(wù)本身的容錯(cuò)。目前Spark在standalone模式下是沒(méi)有任何單點(diǎn)故障問(wèn)題的，這是借助zookeeper實(shí)現(xiàn)的，思想類似于Hbase master單點(diǎn)故障解決方案。將Spark standalone與MapReduce比較，會(huì)發(fā)現(xiàn)它們兩個(gè)在架構(gòu)上是完全一致的：

1)  都是由master/slaves服務(wù)組成的，且起初master均存在單點(diǎn)故障，后來(lái)均通過(guò)zookeeper解決（Apache MRv1的JobTracker仍存在單點(diǎn)問(wèn)題，但CDH版本得到了解決）；

2) 各個(gè)節(jié)點(diǎn)上的資源被抽象成粗粒度的slot，有多少slot就能同時(shí)運(yùn)行多少task。不同的是，MapReduce將slot分為map slot和reduce slot，它們分別只能供Map Task和Reduce Task使用，而不能共享，這是MapReduce資源利率低效的原因之一，而Spark則更優(yōu)化一些，它不區(qū)分slot類型，只有一種slot，可以供各種類型的Task使用，這種方式可以提高資源利用率，但是不夠靈活，不能為不同類型的Task定制slot資源?？傊?，這兩種方式各有優(yōu)缺點(diǎn)。

Spark On Mesos模式。這是很多公司采用的模式，官方推薦這種模式（當(dāng)然，原因之一是血緣關(guān)系）。正是由于Spark開(kāi)發(fā)之初就考慮到支持Mesos，因此，目前而言，Spark運(yùn)行在Mesos上會(huì)比運(yùn)行在YARN上更加靈活，更加自然。目前在Spark On Mesos環(huán)境中，用戶可選擇兩種調(diào)度模式之一運(yùn)行自己的應(yīng)用程序（可參考Andrew Xia的“Mesos Scheduling Mode on Spark”）：

1)   粗粒度模式（Coarse-grained Mode）：每個(gè)應(yīng)用程序的運(yùn)行環(huán)境由一個(gè)Dirver和若干個(gè)Executor組成，其中，每個(gè)Executor占用若干資源，內(nèi)部可運(yùn)行多個(gè)Task（對(duì)應(yīng)多少個(gè)“slot”）。應(yīng)用程序的各個(gè)任務(wù)正式運(yùn)行之前，需要將運(yùn)行環(huán)境中的資源全部申請(qǐng)好，且運(yùn)行過(guò)程中要一直占用這些資源，即使不用，***程序運(yùn)行結(jié)束后，回收這些資源。舉個(gè)例子，比如你提交應(yīng)用程序時(shí)，指定使用5個(gè)executor運(yùn)行你的應(yīng)用程序，每個(gè)executor占用5GB內(nèi)存和5個(gè)CPU，每個(gè)executor內(nèi)部設(shè)置了5個(gè)slot，則Mesos需要先為executor分配資源并啟動(dòng)它們，之后開(kāi)始調(diào)度任務(wù)。另外，在程序運(yùn)行過(guò)程中，mesos的master和slave并不知道executor內(nèi)部各個(gè)task的運(yùn)行情況，executor直接將任務(wù)狀態(tài)通過(guò)內(nèi)部的通信機(jī)制匯報(bào)給Driver，從一定程度上可以認(rèn)為，每個(gè)應(yīng)用程序利用mesos搭建了一個(gè)虛擬集群自己使用。

2)   細(xì)粒度模式（Fine-grained Mode）：鑒于粗粒度模式會(huì)造成大量資源浪費(fèi)，Spark On Mesos還提供了另外一種調(diào)度模式：細(xì)粒度模式，這種模式類似于現(xiàn)在的云計(jì)算，思想是按需分配。與粗粒度模式一樣，應(yīng)用程序啟動(dòng)時(shí)，先會(huì)啟動(dòng)executor，但每個(gè)executor占用資源僅僅是自己運(yùn)行所需的資源，不需要考慮將來(lái)要運(yùn)行的任務(wù)，之后，mesos會(huì)為每個(gè)executor動(dòng)態(tài)分配資源，每分配一些，便可以運(yùn)行一個(gè)新任務(wù)，單個(gè)Task運(yùn)行完之后可以馬上釋放對(duì)應(yīng)的資源。每個(gè)Task會(huì)匯報(bào)狀態(tài)給Mesos slave和Mesos Master，便于更加細(xì)粒度管理和容錯(cuò)，這種調(diào)度模式類似于MapReduce調(diào)度模式，每個(gè)Task完全獨(dú)立，優(yōu)點(diǎn)是便于資源控制和隔離，但缺點(diǎn)也很明顯，短作業(yè)運(yùn)行延遲大。

Spark On YARN模式。這是一種最有前景的部署模式。但限于YARN自身的發(fā)展，目前僅支持粗粒度模式（Coarse-grained Mode）。這是由于YARN上的Container資源是不可以動(dòng)態(tài)伸縮的，一旦Container啟動(dòng)之后，可使用的資源不能再發(fā)生變化，不過(guò)這個(gè)已經(jīng)在YARN計(jì)劃（具體參考：https://issues.apache.org/jira/browse/YARN-1197）中了。

總之，這三種分布式部署方式各有利弊，通常需要根據(jù)公司情況決定采用哪種方案。進(jìn)行方案選擇時(shí)，往往要考慮公司的技術(shù)路線（采用Hadoop生態(tài)系統(tǒng)還是其他生態(tài)系統(tǒng)）、服務(wù)器資源（資源有限的話就不要考慮standalone模式了）、相關(guān)技術(shù)人才儲(chǔ)備等。

原文鏈接：http://dongxicheng.org/framework-on-yarn/apache-spark-comparing-three-deploying-ways/