SparkContext源碼分析

粗略的說(shuō)明一下SparkContext源碼！ createTaskScheduler（）針對(duì)不同的提交模式，執(zhí)行不同的方法（local，standalone、yanr等）

standalone模式===》》創(chuàng)建一個(gè)TaskSchedulerImpl

1、???????底層通過(guò)操作SchedulerBackend，針對(duì)不同種類(lèi)的cluster（standalone、yarn。mesoso（亞馬遜））調(diào)度task

2、???????他也可以通過(guò)一個(gè)LoaclBackend，并且將isLocal設(shè)置為true，來(lái)在本地模式下工作

3、???????他負(fù)責(zé)處理一下通用的邏輯，比如說(shuō)決定多個(gè)job的調(diào)度順序（FIFO），啟動(dòng)推測(cè)任務(wù)執(zhí)行

4、???????客戶(hù)端首先應(yīng)該調(diào)用它的initialize（）方法和start（）方法，然后通過(guò)runTasks（）方法提交tasksets

創(chuàng)建SparkDeploySchedulerBackend（）

initializer方法中創(chuàng)建一個(gè)Pool調(diào)度池，FIFO、FAIR

taskScher。start（）方法=====》調(diào)用了一下SparkDeploySchedulerBackend的start方法

此時(shí)：val AppDesc = newApplicationDescription（sc.appName、maxCores,sc.executorMemory,command,appUIaddress）

創(chuàng)建一個(gè)ApplicationDescription，非常重要！它代表了當(dāng)前執(zhí)行的Application的一下情況，包括Application最大需要多少CPU core? 每個(gè)slave上需要多大內(nèi)存。

創(chuàng)建APPclient（Application與spark之間通信）

一個(gè)借口。

它負(fù)責(zé)接收一個(gè)spark master的url，以及一個(gè)ApplicationDescription，和一個(gè)集群事件的監(jiān)聽(tīng)器，以及各種事件發(fā)生時(shí)，監(jiān)聽(tīng)器的回調(diào)函數(shù)！

start（）方法，創(chuàng)建一個(gè)clientActor

調(diào)用registerWithMaster()里面調(diào)用tryRegisterAllMasters()，里面去連接所有的master。

DAGScheduler：實(shí)現(xiàn)了面向stage的調(diào)度機(jī)制的高層次的調(diào)度層，他會(huì)為每一個(gè)job計(jì)算一個(gè)stage的DAG（有向無(wú)環(huán)圖），追蹤RDD和stage的輸出是否被物化（寫(xiě)入磁盤(pán)或者內(nèi)存等地方），并且尋找一個(gè)最少消耗（最優(yōu)、最小）調(diào)度機(jī)制來(lái)運(yùn)行job，他會(huì)將stage作為tasksets提交到底層的TaskScheduler上，來(lái)在集群上運(yùn)行他們（task）。

除了處理stage的DAG，還負(fù)責(zé)決定運(yùn)行每個(gè)task的最佳位置，基于當(dāng)前的緩存狀態(tài)，將這些最佳位置提交給底層的TaskSchedulerImpl，此外，他會(huì)處理由于shuffle輸出文件丟失導(dǎo)致的失敗，在這種情況下，舊的stage可能會(huì)被重新提交，一個(gè)stage內(nèi)部的失敗，如果不是由于shuffle文件丟失導(dǎo)致的，會(huì)被TaskScheduler處理，他會(huì)多次重復(fù)每一個(gè)task，知道最后實(shí)在不行，才會(huì)去取消整個(gè)stage。

SparkUI：jetty工具類(lèi)。

總結(jié)

以上是生活随笔為你收集整理的SparkContext源码分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。