[TOC]
1 說明
根據之前old li（百度高級大數據工程師）給的一張草圖重新整理，並用processon繪圖一下，這樣就更加清晰了。需要注意的是，這裏是基於Spark 2.x以下的版本，因爲在之前，底層通信是基於AKKA ACTOR的方式，但是之後就是使用RPC的方式了。（最近原來是想把spark 2.x的源碼好好閱讀一下，但是公司已有的系統都是基於spark 1.x的，並且最近才更新到spark 1.6.3，所以也不折騰，就把spark 1.x的好好搞透，也不影響後面進一步的深入學習與解理，因爲這些都是觸類旁通的。）
另外，這裏的原理圖是spark standalone模式，關於其它模式（如spark on yarn），後面則會再整理一下。
2 運行架構原理圖與解析
原理圖如下：
說明如下：
- 1.啓動
Spark集羣，其實就是通過運行spark-all.sh腳本來啓動master節點和worker節點，啓動了一個個對應的master進程和worker進程； - 2.
worker啓動之後，向master進程發送註冊信息（該過程基於AKKA Actor事件驅動模型）； - 3.
worker向master註冊成功之後，會不斷向master發送心跳包，監聽master節點是否存活（該過程基於AKKA Actor事件驅動模型）； - 4.
driver向Spark集羣提交作業，通過spark-submit.sh腳本，向master節點申請資源（該過程基於AKKA Actor事件驅動模型）； - 5.
master收到Driver提交的作業請求之後，向worker節點指派任務，其實就是讓其啓動對應的executor進程； - 6.
worker節點收到master節點發來的啓動executor進程任務，就啓動對應的executor進程，同時向master彙報啓動成功，處於可以接收任務的狀態； - 7.當
executor進程啓動成功後，就像Driver進程反向註冊，以此來告訴driver，誰可以接收任務，執行spark作業（該過程基於AKKA Actor事件驅動模型）； - 8.
driver接收到註冊之後，就知道了向誰發送spark作業，這樣在spark集羣中就有一組獨立的executor進程爲該driver服務； - 9.
SparkContext重要組件運行——DAGScheduler和TaskScheduler，DAGScheduler根據寬依賴將作業劃分爲若干stage，併爲每一個階段組裝一批task組成taskset（task裏面就包含了序列化之後的我們編寫的spark transformation）;然後將taskset交給TaskScheduler，由其將任務分發給對應的executor； - 10.
executor進程接收到driver發送過來的taskset，進行反序列化，然後將這些task封裝進一個叫taskrunner的線程中，放到本地線程池中，調度我們的作業的執行；
3 疑惑與解答
1.爲什麼要向Executor發送taskset？
移動數據的成本遠遠高於移動計算，在大數據計算領域中，不管是spark還是MapReduce，都遵循一個原則：移動計算，不移動數據！
2.因爲最終的計算都是在worker的executor上完成的，那麼driver爲什麼要將spark作業提交給master而不提交給worker？
可以舉個簡單的例子來說明這個問題，假如現在集羣有8 cores、8G內存（兩個worker節點，資源一樣的，所以每個worker節點爲4 cores、4G），而提交的spark任務需要4 cores、6G內存，如果要找worker，請問哪一個worker能搞定？顯然都不能，所以需要通過master來進行資源的合理分配，因爲此時的計算是分佈式計算，而不再是過去傳統的單個節點的計算了。