Spark學習（3）——Spark基於Standalone+Yarn任務提交流程詳解

一、Standalone模式兩種提交任務方式

1.1、Standalone-client提交任務方式

（1）提交命令

./spark-submit 
--master spark://node1:7077 
--class org.apache.spark.examples.SparkPi 
../lib/spark-examples-1.6.0-hadoop2.6.0.jar 
1000

或者

./spark-submit 
--master spark://node1:7077 
--deploy-mode client 
--class org.apache.spark.examples.SparkPi 
../lib/spark-examples-1.6.0-hadoop2.6.0.jar 
100

（2）執行原圖解：

（3）執行流程

1. client模式提交任務後，會在客戶端啓動Driver進程。
2. Driver會向Master申請啓動Application啓動的資源。
3. 資源申請成功，Driver端將task發送到worker端執行。
4. worker將task執行結果返回到Driver端。

 （4）總結

client模式適用於測試調試程序。Driver進程是在客戶端啓動的，這裏的客戶端就是指提交應用程序的當前節點。在Driver端可以看到task執行的情況。生產環境下不能使用client模式，是因爲：假設要提交100個application到集羣運行，Driver每次都會在client端啓動，那麼就會導致客戶端100次網卡流量暴增的問題。

1.2、Standalone-cluster提交任務方式

（1）提交命令

./spark-submit 
--master spark://node1:7077 
--deploy-mode cluster
--class org.apache.spark.examples.SparkPi 
../lib/spark-examples-1.6.0-hadoop2.6.0.jar 
100

（2）執行原理圖解

（3）執行流程

1. cluster模式提交應用程序後，會向Master請求啓動Driver.
2. Master接受請求，隨機在集羣一臺節點啓動Driver進程。
3. Driver啓動後爲當前的應用程序申請資源。
4. Driver端發送task到worker節點上執行。
5. worker將執行情況和執行結果返回給Driver端。

（4）總結

Driver進程是在集羣某一臺Worker上啓動的，在客戶端是無法查看task的執行情況的。假設要提交100個application到集羣運行,每次Driver會隨機在集羣中某一臺Worker上啓動，那麼這100次網卡流量暴增的問題就散佈在集羣上。

總結Standalone兩種方式提交任務，Driver與集羣的通信包括：

• Driver負責應用程序資源的申請
• 任務的分發。
• 結果的回收。
• 監控task執行情況。

 

二、Yarn模式兩種提交任務方式

2.1、yarn-client提交任務方式

（1）提交命令

./spark-submit 
--master yarn
 --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar
100
或者
./spark-submit 
--master yarn–client
 --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar
100

或者
./spark-submit 
--master yarn 
--deploy-mode  client 
 --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar
100

（2）執行原理圖解

（3）執行流程

1.	客戶端提交一個Application，在客戶端啓動一個Driver進程。
2.	應用程序啓動後會向RS(ResourceManager)發送請求，啓動AM(ApplicationMaster)的資源。
3.	RS收到請求，隨機選擇一臺NM(NodeManager)啓動AM。這裏的NM相當於Standalone中的Worker節點。
4.	AM啓動後，會向RS請求一批container資源，用於啓動Executor.
5.	RS會找到一批NM返回給AM,用於啓動Executor。
6.	AM會向NM發送命令啓動Executor。
7.	Executor啓動後，會反向註冊給Driver，Driver發送task到Executor,執行情況和結果返回給Driver端。

（4）總結

Yarn-client模式同樣是適用於測試，因爲Driver運行在本地，Driver會與yarn集羣中的Executor進行大量的通信，會造成客戶機網卡流量的大量增加.

（5）ApplicationMaster的作用：

1.	爲當前的Application申請資源
2.	給NameNode發送消息啓動Executor。
注意：ApplicationMaster有launchExecutor和申請資源的功能，並沒有作業調度的功能。

2.2、yarn-cluster提交任務方式

（1）提交命令

./spark-submit 
--master yarn 
--deploy-mode cluster 
--class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar
100
或者
./spark-submit 
--master yarn-cluster
--class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar
100

（2）執行原理圖解

（3）執行流程

1.	客戶機提交Application應用程序，發送請求到RS(ResourceManager),請求啓動AM(ApplicationMaster)。
2.	RS收到請求後隨機在一臺NM(NodeManager)上啓動AM（相當於Driver端）。
3.	AM啓動，AM發送請求到RS，請求一批container用於啓動Executor。
4.	RS返回一批NM節點給AM。
5.	AM連接到NM,發送請求到NM啓動Executor。
6.	Executor反向註冊到AM所在的節點的Driver。Driver發送task到Executor。

（4）總結

Yarn-Cluster主要用於生產環境中，因爲Driver運行在Yarn集羣中某一臺nodeManager中，每次提交任務的Driver所在的機器都是隨機的，不會產生某一臺機器網卡流量激增的現象，缺點是任務提交後不能看到日誌。只能通過yarn查看日誌。

（5）ApplicationMaster的作用：

1.	爲當前的Application申請資源
2.	給NameNode發送消息啓動Excutor。
3.	任務調度。
	停止集羣任務命令：yarn application -kill applicationID

三、窄依賴和寬依賴

RDD之間有一系列的依賴關係，依賴關係又分爲窄依賴和寬依賴。

（1）窄依賴

父RDD和子RDD partition之間的關係是一對一的、或者父RDD一個partition只對應一個子RDD的partition情況下，父RDD和子RDD partition關係是多對一的。不會有shuffle的產生。

（2）寬依賴

父RDD與子RDD partition之間的關係是一對多。會有shuffle的產生。

四、Stage

（1）什麼是Stage

stage是由一組並行的task組成。

Spark任務會根據RDD之間的依賴關係，形成一個DAG有向無環圖;

DAG會提交給DAGScheduler，DAGScheduler會把DAG劃分相互依賴的多個stage;

劃分stage的依據就是RDD之間的寬窄依賴。遇到寬依賴就劃分stage,每個stage包含一個或多個task任務;

然後將這些task以taskSet的形式提交給TaskScheduler運行。

（2）stage切割規則：從後往前，遇到寬依賴就切割stage

（3）stage計算模式：pipeline管道計算模式

（4）疑問1:數據一直在管道里面什麼時候數據會落地？

1. 對RDD進行持久化。
2. shuffle write的時候。

Stage的task並行度是由stage的最後一個RDD的分區數來決定的 。

 

五、Spark資源調度和任務調度

5.1、Spark資源調度和任務調度的流程

啓動集羣后，Worker節點會向Master節點彙報資源情況，Master掌握了集羣資源情況。當Spark提交一個Application後，根據RDD之間的依賴關係將Application形成一個DAG有向無環圖。任務提交後，Spark會在Driver端創建兩個對象：DAGScheduler和TaskScheduler，DAGScheduler是任務調度的高層調度器，是一個對象。DAGScheduler的主要作用就是將DAG根據RDD之間的寬窄依賴關係劃分爲一個個的Stage，然後將這些Stage以TaskSet的形式提交給TaskScheduler（TaskScheduler是任務調度的低層調度器，這裏TaskSet其實就是一個集合，裏面封裝的就是一個個的task任務,也就是stage中的並行度task任務），TaskSchedule會遍歷TaskSet集合，拿到每個task後會將task發送到計算節點Executor中去執行（其實就是發送到Executor中的線程池ThreadPool去執行）。task在Executor線程池中的運行情況會向TaskScheduler反饋，當task執行失敗時，則由TaskScheduler負責重試，將task重新發送給Executor去執行，默認重試3次。如果重試3次依然失敗，那麼這個task所在的stage就失敗了。stage失敗了則由DAGScheduler來負責重試，重新發送TaskSet到TaskSchdeuler，Stage默認重試4次。如果重試4次以後依然失敗，那麼這個job就失敗了。job失敗了，Application就失敗了。

TaskScheduler不僅能重試失敗的task,還會重試straggling（落後，緩慢）task（也就是執行速度比其他task慢太多的task）。如果有運行緩慢的task那麼TaskScheduler會啓動一個新的task來與這個運行緩慢的task執行相同的處理邏輯。兩個task哪個先執行完，就以哪個task的執行結果爲準。這就是Spark的推測執行機制。在Spark中推測執行默認是關閉的。推測執行可以通過spark.speculation屬性來配置。

注意：

• 對於ETL類型要入數據庫的業務要關閉推測執行機制，這樣就不會有重複的數據入庫。
• 如果遇到數據傾斜的情況，開啓推測執行則有可能導致一直會有task重新啓動處理相同的邏輯，任務可能一直處於處理不完的狀態。

圖解Spark資源調度和任務調度的流程：

5.2、粗粒度資源申請和細粒度資源申請

（1）粗粒度資源申請(Spark）

在Application執行之前，將所有的資源申請完畢，當資源申請成功後，纔會進行任務的調度，當所有的task執行完成後，纔會釋放這部分資源。

優點：在Application執行之前，所有的資源都申請完畢，每一個task直接使用資源就可以了，不需要task在執行前自己去申請資源，task啓動就快了，task執行快了，stage執行就快了，job就快了，application執行就快了。

缺點：直到最後一個task執行完成纔會釋放資源，集羣的資源無法充分利用。

（2）細粒度資源申請（MapReduce）

Application執行之前不需要先去申請資源，而是直接執行，讓job中的每一個task在執行前自己去申請資源，task執行完成就釋放資源。

優點：集羣的資源可以充分利用。

缺點：task自己去申請資源，task啓動變慢，Application的運行就相應的變慢了。