Hadoop的MR結構和YARN結構是大數據時代的第一代產品，滿足了大家在離線計算上的需求，但是針對實時運算卻存在不足，為滿足這一需求，后來的大佬研發了spark計算方法，大大的提高了運算效率。

Spark的計算原理

spark的結構為：

節點介紹：

1. Cluster Manager：在standalone模式中即為Master主節點，控制整個集群，監控worker。在YARN模式中為資源管理器負責分配資源，有點像YARN中ResourceManager那個角色，大管家握有所有的干活的資源，屬于乙方的總包。
2. WorkerNode：可以干活的節點，聽大管家ClusterManager差遣，是真正有資源干活的主。從節點，負責控制計算節點，啟動Executor或者Driver。
3. Executor：在WorkerNode上起的一個進程，相當于一個包工頭，負責準備Task環境和執行。
4. Task：負責內存和磁盤的使用。Task是施工項目里的每一個具體的任務。
5. Driver：統管Task的產生與發送給Executor的，運行Application 的main()函數，是甲方的司令員。
6. SparkContext：與ClusterManager打交道的，負責給錢申請資源的，是甲方的接口人。

整個互動流程是這樣的：

1. 甲方來了個項目，創建了SparkContext，SparkContext去找ClusterManager申請資源同時給出報價，需要多少CPU和內存等資源。ClusterManager去找WorkerNode并啟動Excutor，并介紹Excutor給Driver認識;
2. Driver根據施工圖拆分一批批的Task，將Task送給Executor去執行;
3. Executor接收到Task后準備Task運行時依賴并執行，并將執行結果返回給Driver;
4. Driver會根據返回回來的Task狀態不斷的指揮下一步工作，直到所有Task執行結束;

運行流程及特點為：

• Sparkcontext的作用：一是分發task，申請資源等功能外，更重要的一個功能是將RDD拆分成task，即繪制DAG圖。

借用上圖我們再來了解一下spark的運算過程：

1. 構建Spark Application的運行環境，啟動SparkContext;
2. SparkContext向資源管理器(可以是Standalone，Mesos，Yarn)申請運行Executor資源，并啟動StandaloneExecutorbackend;
3. Executor向SparkContext申請Task;
4. SparkContext將應用程序分發給Executor;
5. SparkContext構建成DAG圖，將DAG圖分解成Stage、將Taskset發送給Task Scheduler，最后由Task Scheduler將Task發送給Executor運行;
6. Task在Executor上運行，運行完釋放所有資源;

RDD計算案例

我們用一個案例來分析RDD的計算過程：

• 在客戶端通過RDD構建一個RDD的圖形，如圖第一部分rdd1.join(rdd2).groupby(…).filter(…)。
• sparkcontext中的DAGScheduler會將上步的RDD圖形構建成DAG圖形，如圖第二部分;
• TaskScheduler會將DAG圖形拆分成多個Task;
• Clustermanager通過Yarn調度器將Task分配到各個node的Executer中，結合相關資源進行運算。

DAGScheduler對于RDD圖形的劃分是有一定規律的：

1. stage的劃分是觸發action的時候從后往前劃分的，所以本圖要從RDD_G開始劃分。
2. RDD_G依賴于RDD_B和RDD_F，隨機決定先判斷哪一個依賴，但是對于結果無影響。
3. RDD_B與RDD_G屬于窄依賴，所以他們屬于同一個stage，RDD_B與老爹RDD_A之間是寬依賴的關系，所以他們不能劃分在一起，所以RDD_A自己是一個stage1;
4. RDD_F與RDD_G是屬于寬依賴，他們不能劃分在一起，所以最后一個stage的范圍也就限定了，RDD_B和RDD_G組成了Stage3;
5. RDD_F與兩個爹RDD_D、RDD_E之間是窄依賴關系，RDD_D與爹RDD_C之間也是窄依賴關系，所以他們都屬于同一個stage2;
6. 執行過程中stage1和stage2相互之間沒有前后關系所以可以并行執行，相應的每個stage內部各個partition對應的task也并行執行;
7. stage3依賴stage1和stage2執行結果的partition，只有等前兩個stage執行結束后才可以啟動stage3;
8. 我們前面有介紹過Spark的Task有兩種：ShuffleMapTask和ResultTask，其中后者在DAG最后一個階段推送給Executor，其余所有階段推送的都是ShuffleMapTask。在這個案例中stage1和stage2中產生的都是ShuffleMapTask，在stage3中產生的ResultTask;
9. 雖然stage的劃分是從后往前計算劃分的，但是依賴邏輯判斷等結束后真正創建stage是從前往后的。也就是說如果從stage的ID作為標識的話，先需要執行的stage的ID要小于后需要執行的ID。就本案例來說，stage1和stage2的ID要小于stage3，至于stage1和stage2的ID誰大誰小是隨機的，是由前面第2步決定的。

Executor是最終運行task的苦力，他將Task的執行結果反饋給Driver，會根據大小采用不同的策略：

• 如果大于MaxResultSize，默認1G，直接丟棄;
• 如果“較大”，大于配置的frameSize(默認10M)，以taksId為key存入BlockManager
• else，全部吐給Driver。