lApplication：Spark Application的概念和Hadoop MapReduce中的類似，指的是使用者編寫的Spark應用程式，包含了一個Driver 功能的代碼和分布在叢集中多個節點上運作的Executor代碼；
lDriver：Spark中的Driver即運作上述Application的main()函數并且建立SparkContext，其中建立SparkContext的目的是為了準備Spark應用程式的運作環境。在Spark中由SparkContext負責和ClusterManager通信，進行資源的申請、任務的配置設定和監控等；當Executor部分運作完畢後，Driver負責将SparkContext關閉。通常用SparkContext代表Drive；
lExecutor：Application運作在Worker 節點上的一個程序，該程序負責運作Task，并且負責将資料存在記憶體或者磁盤上，每個Application都有各自獨立的一批Executor。在Spark on Yarn模式下，其程序名稱為CoarseGrainedExecutorBackend，類似于Hadoop MapReduce中的YarnChild。一個CoarseGrainedExecutorBackend程序有且僅有一個executor對象，它負責将Task包裝成taskRunner，并從線程池中抽取出一個空閑線程運作Task。每個CoarseGrainedExecutorBackend能并行運作Task的數量就取決于配置設定給它的CPU的個數了；
lCluster Manager：指的是在叢集上擷取資源的外部服務，目前有：
Ø Standalone：Spark原生的資源管理，由Master負責資源的配置設定；
Ø Hadoop Yarn：由YARN中的ResourceManager負責資源的配置設定；
lWorker：叢集中任何可以運作Application代碼的節點，類似于YARN中的NodeManager節點。在Standalone模式中指的就是通過Slave檔案配置的Worker節點，在Spark on Yarn模式中指的就是NodeManager節點；
l作業（Job）：包含多個Task組成的并行計算，往往由Spark Action催生，一個JOB包含多個RDD及作用于相應RDD上的各種Operation；
l階段（Stage）：每個Job會被拆分很多組Task，每組任務被稱為Stage，也可稱TaskSet，一個作業分為多個階段；
l任務（Task）： 被送到某個Executor上的工作任務；
Spark運作基本流程參見下面示意圖
1. 建構Spark Application的運作環境（啟動SparkContext），SparkContext向資料總管（可以是Standalone、Mesos或YARN）注冊并申請運作Executor資源；
2. 資料總管配置設定Executor資源并啟動StandaloneExecutorBackend，Executor運作情況将随着心跳發送到資料總管上；
3. SparkContext建構成DAG圖，将DAG圖分解成Stage，并把Taskset發送給Task Scheduler。Executor向SparkContext申請Task，Task Scheduler将Task發放給Executor運作同時SparkContext将應用程式代碼發放給Executor。
4. Task在Executor上運作，運作完畢釋放所有資源。
Spark運作架構特點：
l每個Application擷取專屬的executor程序，該程序在Application期間一直駐留，并以多線程方式運作tasks。這種Application隔離機制有其優勢的，無論是從排程角度看（每個Driver排程它自己的任務），還是從運作角度看（來自不同Application的Task運作在不同的JVM中）。當然，這也意味着Spark Application不能跨應用程式共享資料，除非将資料寫入到外部存儲系統。
lSpark與資料總管無關，隻要能夠擷取executor程序，并能保持互相通信就可以了。
l送出SparkContext的Client應該靠近Worker節點（運作Executor的節點)，最好是在同一個Rack裡，因為Spark Application運作過程中SparkContext和Executor之間有大量的資訊交換；如果想在遠端叢集中運作，最好使用RPC将SparkContext送出給叢集，不要遠離Worker運作SparkContext。
lTask采用了資料本地性和推測執行的優化機制。
DAGScheduler把一個Spark作業轉換成Stage的DAG（Directed Acyclic Graph有向無環圖），根據RDD和Stage之間的關系找出開銷最小的排程方法，然後把Stage以TaskSet的形式送出給TaskScheduler，下圖展示了DAGScheduler的作用：
DAGScheduler決定了運作Task的理想位置，并把這些資訊傳遞給下層的TaskScheduler。此外，DAGScheduler還處理由于Shuffle資料丢失導緻的失敗，這有可能需要重新送出運作之前的Stage（非Shuffle資料丢失導緻的Task失敗由TaskScheduler處理）。
TaskScheduler維護所有TaskSet，當Executor向Driver發送心跳時，TaskScheduler會根據其資源剩餘情況配置設定相應的Task。另外TaskScheduler還維護着所有Task的運作狀态，重試失敗的Task。下圖展示了TaskScheduler的作用：
在不同運作模式中任務排程器具體為：
l Spark on Standalone模式為TaskScheduler；
l YARN-Client模式為YarnClientClusterScheduler
l YARN-Cluster模式為YarnClusterScheduler
那麼 RDD在Spark架構中是如何運作的呢？總高層次來看，主要分為三步：
1.建立 RDD 對象
2.DAGScheduler子產品介入運算，計算RDD之間的依賴關系。RDD之間的依賴關系就形成了DAG
3.每一個JOB被分為多個Stage，劃分Stage的一個主要依據是目前計算因子的輸入是否是确定的，如果是則将其分在同一個Stage，避免多個Stage之間的消息傳遞開銷。
以下面一個按 A-Z 首字母分類，查找相同首字母下不同姓名總個數的例子來看一下 RDD 是如何運作起來的。
步驟 1 ：建立 RDD 上面的例子除去最後一個 collect 是個動作，不會建立 RDD 之外，前面四個轉換都會建立出新的 RDD 。是以第一步就是建立好所有 RDD( 内部的五項資訊 ) 。
步驟 2 ：建立執行計劃 Spark 會盡可能地管道化，并基于是否要重新組織資料來劃分 階段 (stage) ，例如本例中的 groupBy() 轉換就會将整個執行計劃劃分成兩階段執行。最終會産生一個 DAG(directed acyclic graph ，有向無環圖 ) 作為邏輯執行計劃。
步驟 3 ：排程任務 将各階段劃分成不同的 任務 (task) ，每個任務都是資料和計算的合體。在進行下一階段前，目前階段的所有任務都要執行完成。因為下一階段的第一個轉換一定是重新組織資料的，是以必須等目前階段所有結果資料都計算出來了才能繼續。
假設本例中的 hdfs://names 下有四個檔案塊，那麼 HadoopRDD 中 partitions 就會有四個分區對應這四個塊資料，同時 preferedLocations 會指明這四個塊的最佳位置。現在，就可以建立出四個任務，并排程到合适的叢集結點上。
Spark注重建立良好的生态系統，它不僅支援多種外部檔案存儲系統，提供了多種多樣的叢集運作模式。部署在單台機器上時，既可以用本地（Local）模式運作，也可以使用僞分布式模式來運作；當以分布式叢集部署的時候，可以根據自己叢集的實際情況選擇Standalone模式（Spark自帶的模式）、YARN-Client模式或者YARN-Cluster模式。Spark的各種運作模式雖然在啟動方式、運作位置、排程政策上各有不同，但它們的目的基本都是一緻的，就是在合适的位置安全可靠的根據使用者的配置和Job的需要運作和管理Task。
Standalone模式是Spark實作的資源排程架構，其主要的節點有Client節點、Master節點和Worker節點。其中Driver既可以運作在Master節點上中，也可以運作在本地Client端。當用spark-shell互動式工具送出Spark的Job時，Driver在Master節點上運作；當使用spark-submit工具送出Job或者在Eclips、IDEA等開發平台上使用”new SparkConf.setManager(“spark://master:7077”)”方式運作Spark任務時，Driver是運作在本地Client端上的。
其運作過程如下：
1.SparkContext連接配接到Master，向Master注冊并申請資源（CPU Core 和Memory）；
2.Master根據SparkContext的資源申請要求和Worker心跳周期内報告的資訊決定在哪個Worker上配置設定資源，然後在該Worker上擷取資源，然後啟動StandaloneExecutorBackend；
3.StandaloneExecutorBackend向SparkContext注冊；
4.SparkContext将Applicaiton代碼發送給StandaloneExecutorBackend；并且SparkContext解析Applicaiton代碼，建構DAG圖，并送出給DAG Scheduler分解成Stage（當碰到Action操作時，就會催生Job；每個Job中含有1個或多個Stage，Stage一般在擷取外部資料和shuffle之前産生），然後以Stage（或者稱為TaskSet）送出給Task Scheduler，Task Scheduler負責将Task配置設定到相應的Worker，最後送出給StandaloneExecutorBackend執行；
5.StandaloneExecutorBackend會建立Executor線程池，開始執行Task，并向SparkContext報告，直至Task完成。
6.所有Task完成後，SparkContext向Master登出，釋放資源。
YARN是一種統一資源管理機制，在其上面可以運作多套計算架構。目前的大資料技術世界，大多數公司除了使用Spark來進行資料計算，由于曆史原因或者單方面業務處理的性能考慮而使用着其他的計算架構，比如MapReduce、Storm等計算架構。Spark基于此種情況開發了Spark on YARN的運作模式，由于借助了YARN良好的彈性資源管理機制，不僅部署Application更加友善，而且使用者在YARN叢集中運作的服務和Application的資源也完全隔離，更具實踐應用價值的是YARN可以通過隊列的方式，管理同時運作在叢集中的多個服務。
Spark on YARN模式根據Driver在叢集中的位置分為兩種模式：一種是YARN-Client模式，另一種是YARN-Cluster（或稱為YARN-Standalone模式）。
任何架構與YARN的結合，都必須遵循YARN的開發模式。在分析Spark on YARN的實作細節之前，有必要先分析一下YARN架構的一些基本原理。
Yarn架構的基本運作流程圖為：
其中，ResourceManager負責将叢集的資源配置設定給各個應用使用，而資源配置設定和排程的基本機關是Container，其中封裝了機器資源，如記憶體、CPU、磁盤和網絡等，每個任務會被配置設定一個Container，該任務隻能在該Container中執行，并使用該Container封裝的資源。NodeManager是一個個的計算節點，主要負責啟動Application所需的Container，監控資源（記憶體、CPU、磁盤和網絡等）的使用情況并将之彙報給ResourceManager。ResourceManager與NodeManagers共同組成整個資料計算架構，ApplicationMaster與具體的Application相關，主要負責同ResourceManager協商以擷取合适的Container，并跟蹤這些Container的狀态和監控其進度。
Yarn-Client模式中，Driver在用戶端本地運作，這種模式可以使得Spark Application和用戶端進行互動，因為Driver在用戶端，是以可以通過webUI通路Driver的狀态，預設是http://hadoop1:4040通路，而YARN通過http:// hadoop1:8088通路。
YARN-client的工作流程分為以下幾個步驟：
1.Spark Yarn Client向YARN的ResourceManager申請啟動Application Master。同時在SparkContent初始化中将建立DAGScheduler和TASKScheduler等，由于我們選擇的是Yarn-Client模式，程式會選擇YarnClientClusterScheduler和YarnClientSchedulerBackend；
2.ResourceManager收到請求後，在叢集中選擇一個NodeManager，為該應用程式配置設定第一個Container，要求它在這個Container中啟動應用程式的ApplicationMaster，與YARN-Cluster差別的是在該ApplicationMaster不運作SparkContext，隻與SparkContext進行聯系進行資源的分派；
3.Client中的SparkContext初始化完畢後，與ApplicationMaster建立通訊，向ResourceManager注冊，根據任務資訊向ResourceManager申請資源（Container）；
4.一旦ApplicationMaster申請到資源（也就是Container）後，便與對應的NodeManager通信，要求它在獲得的Container中啟動啟動CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend啟動後會向Client中的SparkContext注冊并申請Task；
5.Client中的SparkContext配置設定Task給CoarseGrainedExecutorBackend執行，CoarseGrainedExecutorBackend運作Task并向Driver彙報運作的狀态和進度，以讓Client随時掌握各個任務的運作狀态，進而可以在任務失敗時重新啟動任務；
6.應用程式運作完成後，Client的SparkContext向ResourceManager申請登出并關閉自己。
在YARN-Cluster模式中，當使用者向YARN中送出一個應用程式後，YARN将分兩個階段運作該應用程式：第一個階段是把Spark的Driver作為一個ApplicationMaster在YARN叢集中先啟動；第二個階段是由ApplicationMaster建立應用程式，然後為它向ResourceManager申請資源，并啟動Executor來運作Task，同時監控它的整個運作過程，直到運作完成。
YARN-cluster的工作流程分為以下幾個步驟：
1. Spark Yarn Client向YARN中送出應用程式，包括ApplicationMaster程式、啟動ApplicationMaster的指令、需要在Executor中運作的程式等；
2. ResourceManager收到請求後，在叢集中選擇一個NodeManager，為該應用程式配置設定第一個Container，要求它在這個Container中啟動應用程式的ApplicationMaster，其中ApplicationMaster進行SparkContext等的初始化；
3. ApplicationMaster向ResourceManager注冊，這樣使用者可以直接通過ResourceManage檢視應用程式的運作狀态，然後它将采用輪詢的方式通過RPC協定為各個任務申請資源，并監控它們的運作狀态直到運作結束；
4. 一旦ApplicationMaster申請到資源（也就是Container）後，便與對應的NodeManager通信，要求它在獲得的Container中啟動啟動CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend啟動後會向ApplicationMaster中的SparkContext注冊并申請Task。這一點和Standalone模式一樣，隻不過SparkContext在Spark Application中初始化時，使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler進行任務的排程，其中YarnClusterScheduler隻是對TaskSchedulerImpl的一個簡單包裝，增加了對Executor的等待邏輯等；
5. ApplicationMaster中的SparkContext配置設定Task給CoarseGrainedExecutorBackend執行，CoarseGrainedExecutorBackend運作Task并向ApplicationMaster彙報運作的狀态和進度，以讓ApplicationMaster随時掌握各個任務的運作狀态，進而可以在任務失敗時重新啟動任務；
6. 應用程式運作完成後，ApplicationMaster向ResourceManager申請登出并關閉自己。
了解YARN-Client和YARN-Cluster深層次的差別之前先清楚一個概念：Application Master。在YARN中，每個Application執行個體都有一個ApplicationMaster程序，它是Application啟動的第一個容器。它負責和ResourceManager打交道并請求資源，擷取資源之後告訴NodeManager為其啟動Container。從深層次的含義講YARN-Cluster和YARN-Client模式的差別其實就是ApplicationMaster程序的差別。
l YARN-Cluster模式下，Driver運作在AM(Application Master)中，它負責向YARN申請資源，并監督作業的運作狀況。當使用者送出了作業之後，就可以關掉Client，作業會繼續在YARN上運作，因而YARN-Cluster模式不适合運作互動類型的作業；
l YARN-Client模式下，Application Master僅僅向YARN請求Executor，Client會和請求的Container通信來排程他們工作，也就是說Client不能離開。
在以下運作示範過程中需要啟動Hadoop和Spark叢集，其中Hadoop需要啟動HDFS和YARN，啟動過程可以參見第三節《Spark程式設計模型（上）--概念及Shell試驗》。
在Spark叢集的節點中，40%的資料用于計算，60%的記憶體用于儲存結果，為了能夠直覺感受資料在記憶體和非記憶體速度的差別，在該示範中将使用大小為1G的Sogou3.txt資料檔案（參見第三節《Spark程式設計模型（上）--概念及Shell試驗》的3.2測試資料檔案上傳），通過對比得到差距。
使用HDFS指令觀察Sogou3.txt資料存放節點的位置
$cd /app/hadoop/hadoop-2.2.0/bin
$hdfs fsck /sogou/SogouQ3.txt -files -blocks -locations
通過可以看到該檔案被分隔為9個塊放在叢集中
通過如下指令啟動Spark-Shell，在示範當中每個Executor配置設定1G記憶體
$cd /app/hadoop/spark-1.1.0/bin
$./spark-shell --master spark://hadoop1:7077 --executor-memory 1g
通過Spark的監控界面檢視Executors的情況，可以觀察到有1個Driver 和3個Executor，其中hadoop2和hadoop3啟動一個Executor，而hadoop1啟動一個Executor和Driver。在該模式下Driver中運作SparkContect，也就是DAGSheduler和TaskSheduler等程序是運作在節點上，進行Stage和Task的配置設定和管理。
第一步 讀取檔案後計算資料集條數，并計算過程中使用cache()方法對資料集進行緩存
val sogou=sc.textFile("hdfs://hadoop1:9000/sogou/SogouQ3.txt")
sogou.cache()
sogou.count()
通過頁面監控可以看到該作業分為8個任務，其中一個任務的資料來源于兩個資料分片，其他的任務各對應一個資料分片，即顯示7個任務擷取資料的類型為（NODE_LOCAL），1個任務擷取資料的類型為任何位置（ANY）。
在存儲監控界面中，我們可以看到緩存份數為3，大小為907.1M，緩存率為38%
運作結果得到資料集的數量為1000萬筆資料，總共花費了352.17秒
第二步 再次讀取檔案後計算資料集條數，此次計算使用緩存的資料，對比前後
通過頁面監控可以看到該作業還是分為8個任務，其中3個任務資料來自記憶體（PROCESS_LOCAL），3個任務資料來自本機（NODE_LOCAL），其他2個任務資料來自任何位置（ANY）。任務所耗費的時間多少排序為：ANY> NODE_LOCAL> PROCESS_LOCAL，對比看出使用記憶體的資料比使用本機或任何位置的速度至少會快2個數量級。
整個作業的運作速度為34.14秒，比沒有緩存提高了一個數量級。由于剛才例子中資料隻是部分緩存（緩存率38%），如果完全緩存速度能夠得到進一步提升，從這體驗到Spark非常耗記憶體，不過也夠快、夠鋒利！
通過如下指令啟動Spark-Shell，在示範當中配置設定3個Executor、每個Executor為1G記憶體
$./spark-shell --master YARN-client --num-executors 3 --executor-memory 1g
第一步 把相關的運作JAR包上傳到HDFS中
通過HDFS檢視界面可以看到在 /user/hadoop/.sparkStaging/應用編号，檢視到這些檔案：
第二步 啟動Application Master，注冊Executor
應用程式向ResourceManager申請啟動Application Master，在啟動完成後會配置設定Cotainer并把這些資訊回報給SparkContext，SparkContext和相關的NM通訊，在獲得的Container上啟動Executor，從下圖可以看到在hadoop1、hadoop2和hadoop3分别啟動了Executor
第三步 檢視啟動結果
YARN-Client模式中，Driver在用戶端本地運作，這種模式可以使得Spark Application和用戶端進行互動，因為Driver在用戶端是以可以通過webUI通路Driver的狀态，預設是http://hadoop1:4040通路，而YARN通過http:// hadoop1:8088通路。
通過頁面監控可以看到該作業分為8個任務，其中一個任務的資料來源于兩個資料分片，其他的任務各對應一個資料分片，即顯示7個任務擷取資料的類型為（NODE_LOCAL），1個任務擷取資料的類型為任何位置（RACK_LOCAL）。
通過運作日志可以觀察到在所有任務結束的時候，由 YARNClientScheduler通知YARN叢集任務運作完畢，回收資源，最終關閉SparkContext，整個過程耗費108.6秒。
第二步 檢視資料緩存情況
通過監控界面可以看到，和Standalone一樣38%的資料已經緩存在記憶體中
第三步 再次讀取檔案後計算資料集條數，此次計算使用緩存的資料，對比前後
通過頁面監控可以看到該作業還是分為8個任務，其中3個任務資料來自記憶體（PROCESS_LOCAL），4個任務資料來自本機（NODE_LOCAL），1個任務資料來自機架（RACK_LOCAL）。對比在記憶體中的運作速度最快，速度比在本機要快至少1個數量級。
YARNClientClusterScheduler替代了Standalone模式下得TaskScheduler進行任務管理，在任務結束後通知YARN叢集進行資源的回收，最後關閉SparkContect。部分緩存資料運作過程耗費了29.77秒，比沒有緩存速度提升不少。
通過如下指令啟動Spark-Shell，在示範當中配置設定3個Executor、每個Executor為512M記憶體
$cd /app/hadoop/spark-1.1.0
$./bin/spark-submit --master YARN-cluster --class class3.SogouResult --executor-memory 512m LearnSpark.jar hdfs://hadoop1:9000/sogou/SogouQ3.txt hdfs://hadoop1:9000/class3/output2
第一步 把相關的資源上傳到HDFS中，相對于YARN-Client多了LearnSpark.jar檔案
這些檔案可以在HDFS中找到，具體路徑為 http://hadoop1:9000/user/hadoop/.sparkStaging/應用編号 ：
第二步 YARN叢集接管運作
首先YARN叢集中由ResourceManager配置設定Container啟動SparkContext，并配置設定運作節點，由SparkConext和NM進行通訊，擷取Container啟動Executor，然後由SparkContext的YarnClusterScheduler進行任務的分發和監控，最終在任務執行完畢時由YarnClusterScheduler通知ResourceManager進行資源的回收。
在YARN-Cluster模式中指令界面隻負責應用的送出，SparkContext和作業運作均在YARN叢集中，可以從http:// hadoop1:8088檢視到具體運作過程，運作結果輸出到HDFS中，如下圖所示：
在進行Hadoop2.X 64bit編譯安裝中由于使用到64位虛拟機，安裝過程中出現下圖錯誤：
[hadoop@hadoop1 spark-1.1.0]$ bin/spark-shell --master YARN-client --executor-memory 1g --num-executors 3
Spark assembly has been built with Hive, including Datanucleus jars on classpath
Exception in thread "main" java.lang.Exception: When running with master 'YARN-client' either HADOOP_CONF_DIR or YARN_CONF_DIR must be set in the environment.
at org.apache.spark.deploy.SparkSubmitArguments.checkRequiredArguments(SparkSubmitArguments.scala:182)
at org.apache.spark.deploy.SparkSubmitArguments.<init>(SparkSubmitArguments.scala:62)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:70)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
參考資料：
（1）《Spark1.0.0 運作架構基本概念》 http://blog.csdn.net/book_mmicky/article/details/25714419
（2）《Spark架構與作業執行流程簡介》 http://www.cnblogs.com/shenh062326/p/3658543.html
（3）《Spark1.0.0 運作架構基本概念》 http://shiyanjun.cn/archives/744.html
作者：石山園 出處：http://www.cnblogs.com/shishanyuan/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。如果覺得還有幫助的話，可以點一下右下角的【推薦】，希望能夠持續的為大家帶來好的技術文章！想跟我一起進步麼？那就【關注】我吧。