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來進行資源的合理分配，因為此時的計算是分布式計算，而不再是過去傳統的單個節點的計算了。

Spark作業運行架構原理解析