一：再論Spark集羣部署
1， 從Spark Runtime的角度來講由五大核心對象：Master、Worker、Executor、Driver、CoarseGrainedExecutorBackend；
2， Spark在做分佈式集羣系統設計的時候：最大化功能獨立、模塊化封裝具體獨立的對象、強內聚鬆耦合。
3，當Driver中的SparkContext初始化的時候會提交程序給Master，Master如果接受該程序在Spark中運行的話，就會爲當前的程序分配AppID，同時會分配具體的計算資源，需要特別注意的是，Master是根據當前提交程序的配置信息來給集羣中的Worker發指令分配具體的計算資源，但是，Master發出指令後並不關心具體的資源是否已經分配，轉來說Master是發指令後就記錄了分配的資源，以後客戶端再次提交其它的程序的話就不能使用該資源了。其弊端是可能會導致其它要提交的程序無法分配到本來應該可以分配到的計算資源；最終的優勢在Spark分佈式系統功能若耦合的基礎上最快的運行系統（否則如果Master要等到資源最終分配成功後才通知Driver的話，就會造成Driver阻塞，不能夠最大化並行計算資源的使用率）。
需要補充說明的是：Spark在默認情況下由於集羣中一般都只有一個Application在運行，所有Master分配資源策略的弊端就沒有那麼明顯了。
二：Job提交過程源碼解密
1，一個非常重要的技巧通過在spark-shell中運行一個Job來了解Job提交的過程，然後在用源碼驗證這個過程；
sc.textFile(“/kkkkkk”).flatMap(line => line.split(” “)).map(word => (word,1)).reduceByKey(+).saveAsTextFile(“/ssssss”)
2，在Spark中所有的Action都會觸發一個至少一個Job，在上述代碼中是通過saveAsTextFile來觸發Job的；
3，SparkContext在實例化的時候會構造以下對象：SparkDeploySchedulerBackend負責集羣計算資源的管理和調度，
DAGScheduler負責高層調度（例如Job中Stage的劃分、數據本地性等內容），
TaskSchedulerImple負責具體Stage內部的底層調度（例如具體每個Task的調度、Task的容錯等），
MapOutputTrackerMaster負責Shuffle中數據輸出和讀取的管理；
4，TaskSchedulerImpl內部的調度：
三：Task的運行解密：
1，Task是運行在Executor中，而Executor又是位於CoarseGrainedExecutorBackend中的，且CoarseGrainedExecutorBackend和Executor是一一對應的；
2，當CoarseGrainedExecutorBackend接收到TaskSetManager發過來的LaunchTask消息後會反序列化TaskDescription，然後使用CoarseGrainedExecutorBackend中唯一的Executor來執行任務；
