Hadoop的MR結(jié)構(gòu)和YARN結(jié)構(gòu)是大數(shù)據(jù)時(shí)代的第一代產(chǎn)品，滿足了大家在離線計(jì)算上的需求，但是針對(duì)實(shí)時(shí)運(yùn)算卻存在不足，為滿足這一需求，后來(lái)的大佬研發(fā)了spark計(jì)算方法，大大的提高了運(yùn)算效率。

Spark的計(jì)算原理

spark的結(jié)構(gòu)為：

節(jié)點(diǎn)介紹：

1. Cluster Manager：在standalone模式中即為Master主節(jié)點(diǎn)，控制整個(gè)集群，監(jiān)控worker。在YARN模式中為資源管理器負(fù)責(zé)分配資源，有點(diǎn)像YARN中ResourceManager那個(gè)角色，大管家握有所有的干活的資源，屬于乙方的總包。
2. WorkerNode：可以干活的節(jié)點(diǎn)，聽(tīng)大管家ClusterManager差遣，是真正有資源干活的主。從節(jié)點(diǎn)，負(fù)責(zé)控制計(jì)算節(jié)點(diǎn)，啟動(dòng)Executor或者Driver。
3. Executor：在WorkerNode上起的一個(gè)進(jìn)程，相當(dāng)于一個(gè)包工頭，負(fù)責(zé)準(zhǔn)備Task環(huán)境和執(zhí)行。
4. Task：負(fù)責(zé)內(nèi)存和磁盤(pán)的使用。Task是施工項(xiàng)目里的每一個(gè)具體的任務(wù)。
5. Driver：統(tǒng)管Task的產(chǎn)生與發(fā)送給Executor的，運(yùn)行Application 的main()函數(shù)，是甲方的司令員。
6. SparkContext：與ClusterManager打交道的，負(fù)責(zé)給錢(qián)申請(qǐng)資源的，是甲方的接口人。

整個(gè)互動(dòng)流程是這樣的：

1. 甲方來(lái)了個(gè)項(xiàng)目，創(chuàng)建了SparkContext，SparkContext去找ClusterManager申請(qǐng)資源同時(shí)給出報(bào)價(jià)，需要多少CPU和內(nèi)存等資源。ClusterManager去找WorkerNode并啟動(dòng)Excutor，并介紹Excutor給Driver認(rèn)識(shí);
2. Driver根據(jù)施工圖拆分一批批的Task，將Task送給Executor去執(zhí)行;
3. Executor接收到Task后準(zhǔn)備Task運(yùn)行時(shí)依賴并執(zhí)行，并將執(zhí)行結(jié)果返回給Driver;
4. Driver會(huì)根據(jù)返回回來(lái)的Task狀態(tài)不斷的指揮下一步工作，直到所有Task執(zhí)行結(jié)束;

運(yùn)行流程及特點(diǎn)為：

• Sparkcontext的作用：一是分發(fā)task，申請(qǐng)資源等功能外，更重要的一個(gè)功能是將RDD拆分成task，即繪制DAG圖。

借用上圖我們?cè)賮?lái)了解一下spark的運(yùn)算過(guò)程：

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

RDD計(jì)算案例

我們用一個(gè)案例來(lái)分析RDD的計(jì)算過(guò)程：

• 在客戶端通過(guò)RDD構(gòu)建一個(gè)RDD的圖形，如圖第一部分rdd1.join(rdd2).groupby(…).filter(…)。
• sparkcontext中的DAGScheduler會(huì)將上步的RDD圖形構(gòu)建成DAG圖形，如圖第二部分;
• TaskScheduler會(huì)將DAG圖形拆分成多個(gè)Task;
• Clustermanager通過(guò)Yarn調(diào)度器將Task分配到各個(gè)node的Executer中，結(jié)合相關(guān)資源進(jìn)行運(yùn)算。

DAGScheduler對(duì)于RDD圖形的劃分是有一定規(guī)律的：

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

Executor是最終運(yùn)行task的苦力，他將Task的執(zhí)行結(jié)果反饋給Driver，會(huì)根據(jù)大小采用不同的策略：

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