Spark internal - 多樣化的運行模式（上）

Spark的運行模式多種多樣，在單機上既能夠以本地模式運行，也能夠以僞分佈式模式運行。而當以分佈式的方式運行在Cluster集羣中時，底層的資源調度可使用Mesos 或者是Hadoop Yarn ，也可使用Spark自帶的Standalone Deploy模式

Spark處於活躍的開發過程當中，代碼變更頻繁，因此本文儘可能不涉及具體的代碼分析，僅從結構和流程的角度進行闡述。

運行模式列表

基本上，Spark的運行模式取決於傳遞給SparkContext的MASTER環境變量的值，個別模式還須要輔助的程序接口來配合使用，目前支持的Master字符串及URL包括：

Local[N] ：本地模式 使用N個線程

Local-cluster ：僞分佈式模式

Spark:// ：Standalone Deploy模式，須要部署Spark到相關節點

Mesos:// ：Mesos模式，須要部署Spark和Mesos到相關節點

Yarn-standalone ：SparkContext和任務都運行在Yarn集羣中

Yarn-client ：SparkConext運行在本地，task運行在Yarn集羣中

 

此外還有一些用於調試的URL

 

大體工做流程

整體上來講，這些運行模式都基於一個類似的工做流程，SparkContext做爲調度的總入口，在初始化過程當中會分別建立DAGScheduler做業調度和TaskScheduler任務調度兩極調度模塊

做業調度模塊是基於Stage的高層調度模塊，它爲每一個Spark  Job計算具備依賴關係的多個Stage任務階段（一般根據Shuffle來劃分Stage），而後將每一個Stage劃分爲具體的一組任務（一般會考慮數據的本地性等）以Task  Sets的形式提交給底層的任務調度模塊來具體執行

任務調度模塊負責具體啓動任務，監控和彙報任務運行狀況

不一樣運行模式的主要區別就在於他們各自實現了本身特定的任務調度模塊，用來實際執行計算任務

 

相關基本類

TaskScheduler  / SchedulerBackend

爲了抽象出一個公共的接口供DAGScheduler做業調度模塊使用，全部的這些運行模式實現的任務調度模塊都是基於兩個Trait：TaskScheduler和  SchedulerBackend

理論上，TaskScheduler的實現用於與DAGScheduler交互，負責任務的具體調度和運行，核心接口是submitTasks 和 CancelTasks

SchedulerBackend的實現用於與底層資源調度系統交互（如mesos/YARN），配合TaskScheduler實現具體任務執行所需的資源分配，核心接口是receiveOffers

這二者之間的實際交互過程取決於具體調度模式，理論上這二者的實現是成對匹配工做的，拆分紅兩部分，有利於類似的調度模式共享代碼功能模塊

TaskSchedulerImpl

TaskSchedulerImpl實現了TaskScheduler Trait，提供了大多數Local和Cluster調度模式的任務調度接口，此外還實現了resourceOffers和statusUpdate兩個接口給Backend調用，用於提供調度資源和更新任務狀態。另外在提交任務，更新狀態等階段調用Backend的receiveOffers函數用來發起一次任務資源調度請求

Executor

實際任務的運行，最終都由Executor類來執行，Executor對每個Task啓動一個TaskRunner類，並經過ExectorBackend的接口返回task運行結果

 

具體實現

 

 

 

Local[N]

Local本地模式使用 LocalBackend 配合TaskSchedulerImpl

LocalBackend 響應Scheduler的receiveOffers請求，根據可用CPU  Core的設定值[N]直接生成WorkerOffer資源返回給Scheduler，並經過Executor類在線程池中依次啓動和運行Scheduler返回的任務列表

Spark Standalone Deploy

Standalone模式使用SparkDeploySchedulerBackend配合TaskSchedulerImpl ，而SparkDeploySchedulerBackend自己拓展自CoarseGrainedSchedulerBackend

CoarseGrainedSchedulerBackend是一個基於Akka Actor實現的粗粒度的資源調度類，在整個SparkJob運行期間，CoarseGrainedSchedulerBackend會監聽並持有註冊給它的Executor資源（相對於細粒度的調度，Executor基於每一個任務的生命週期建立和銷燬），而且在接受Executor註冊，狀態更新，響應Scheduler請求等各類時刻，根據現有Executor資源發起任務調度流程

Executor自己經過各類途徑啓動，在Spark Standalone模式中，SparkDeploySchedulerBackend經過Client類向Spark  Master 發送請求在獨立部署的Spark集羣中啓動CoarseGrainedExecutorBackend，根據所需的CPU資源Core的數量，一個或多個CoarseGrainedExecutorBackend在Spark  Worker節點上啓動並註冊給CoarseGrainedSchedulerBackend的DriverActor

完成所需Actor的啓動以後，以後的任務調度就在CoarseGrainedSchedulerBackend和CoarseGrainedExecutorBackend的Actor之間直接完成

Local-cluster

僞分佈模式基於Standalone模式實現，實際就是在SparkContext初始化的過程當中如今本地啓動一個單機的僞分佈Spark集羣，以後的流程與Standalone模式相同

Mesos

Mesos模式根據調度的顆粒度，分別使用CoarseMesosSchedulerBackend和MesosSchedulerBackend配合TaskSchedulerImpl

粗粒度的CoarseMesosSchedulerBackend拓展自CoarseGrainedSchedulerBackend，相對於父類額外作的工做就是實現了MScheduler接口，註冊到Mesos資源調度的框架中，用於接收Mesos的資源分配，在獲得資源後經過Mesos框架遠程啓動CoarseGrainedExecutorBackend，以後的任務交互過程和Spark  standalone模式同樣，由DriverActor和Executor Actor直接完成

細粒度的MesosSchedulerBackend不使用CoarseMesosSchedulerBackend的基於Actor的調度模式，所以直接繼承自SchedulerBackend，一樣實現了MScheduler接口，註冊到Mesos資源調度的框架中，用於接收Mesos的資源分配。不一樣的是在接收資源後，MesosSchedulerBackend啓動的是基於Task任務的遠程Executor，經過在遠程執行  ./sbin/spark-executor命令來啓動MesosExecutorBackend，在MesosExecutorBackend中直接launch對應的Task

Yarn-standalone

Yarn-Standalone模式相對其它模式有些特殊，須要由外部程序輔助啓動APP。用戶的應用程序經過org.apache.spark.deploy.yarn.Client啓動

Client經過Yarn Client API在Hadoop集羣上啓動一個Spark  ApplicationMaster，Spark ApplicationMaster首先註冊本身爲一個YarnApplication  Master，以後啓動用戶程序，SparkContext在用戶程序中初始化時，使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler,YarnClusterScheduler只是對TaskSchedulerImpl 的一個簡單包裝，增長對Executor的等待邏輯等。

而後根據Client傳遞過來的參數，SparkApplicationMaster經過Yarn  RM/NM的接口在集羣中啓動若干個Container用於運行CoarseGrainedExecutorBackend往CoarseGrainedSchedulerBackend註冊。以後的任務調度流程同上述其它Cluster模式

Yarn-client

Yarn-client模式中，SparkContext運行在本地，該模式適用於應用APP自己須要在本地進行交互的場合，好比Spark  Shell，Shark等

Yarn-client模式下，SparkContext在初始化過程當中啓動YarnClientSchedulerBackend（一樣拓展自CoarseGrainedSchedulerBackend），該Backend進一步調用org.apache.spark.deploy.yarn.Client在遠程啓動一個WorkerLauncher做爲Spark的Application  Master，相比Yarn-standalone模式，WorkerLauncher再也不負責用戶程序的啓動（已經在客戶端本地啓動），而只是啓動Container運行CoarseGrainedExecutorBackend與客戶端本地的Driver進行通信，後續任務調度流程相同

歸納

整體而言，各類運行模式就是經過各類手段啓動匹配的SchedulerBackend和ExecutorBackend。除了Local模式和細粒度的Mesos模式，其它模式最終都是經過基於Akka的CoarseGrainedSchedulerBackend和CoarseGrainedExecutorBackend完成任務調度

轉自：http://blog.csdn.net/colorant/article/details/18549027