Spark2.1.0模型設計與基本架構（下）

閱讀提示：讀者若是對Spark的背景知識不是很瞭解的話，建議首先閱讀《SPARK2.1.0模型設計與基本架構（上）》一文。

Spark模型設計

1. Spark編程模型

正如Hadoop在介紹MapReduce編程模型時選擇word count的例子，而且使用圖形來講明同樣，筆者對於Spark編程模型也選擇用圖形展示。

Spark 應用程序從編寫到提交、執行、輸出的整個過程如圖5所示。

 

圖5   代碼執行過程

圖5中描述了Spark編程模型的關鍵環節的步驟以下。

1）用戶使用SparkContext提供的API（經常使用的有textFile、sequenceFile、runJob、stop等）編寫Driver application程序。此外，SparkSession、DataFrame、SQLContext、HiveContext及StreamingContext都對SparkContext進行了封裝，並提供了DataFrame、SQL、Hive及流式計算相關的API。

2）使用SparkContext提交的用戶應用程序，首先會經過RpcEnv向集羣管理器（Cluster Manager）註冊應用（Application）而且告知集羣管理器須要的資源數量。集羣管理器根據Application的需求，給Application分配Executor資源，並在Worker上啓動CoarseGrainedExecutorBackend進程（CoarseGrainedExecutorBackend進程內部將建立Executor）。Executor所在的CoarseGrainedExecutorBackend進程在啓動的過程當中將經過RpcEnv直接向Driver註冊Executor的資源信息，TaskScheduler將保存已經分配給應用的Executor資源的地址、大小等相關信息。而後，SparkContext根據各類轉換API，構建RDD之間的血緣關係（lineage）和DAG，RDD構成的DAG將最終提交給DAGScheduler。DAGScheduler給提交的DAG建立Job並根據RDD的依賴性質將DAG劃分爲不一樣的Stage。DAGScheduler根據Stage內RDD的Partition數量建立多個Task並批量提交給TaskScheduler。TaskScheduler對批量的Task按照FIFO或FAIR調度算法進行調度，而後給Task分配Executor資源，最後將Task發送給Executor由Executor執行。此外，SparkContext還會在RDD轉換開始以前使用BlockManager和BroadcastManager將任務的Hadoop配置進行廣播。

3）集羣管理器（Cluster Manager）會根據應用的需求，給應用分配資源，即將具體任務分配到不一樣Worker節點上的多個Executor來處理任務的運行。Standalone、YARN、Mesos、EC2等均可以做爲Spark的集羣管理器。

4）Task在運行的過程當中須要對一些數據（例如中間結果、檢查點等）進行持久化，Spark支持選擇HDFS 、Amazon S三、Alluxio（原名叫Tachyon）等做爲存儲。

2.RDD計算模型

RDD能夠看作是對各類數據計算模型的統一抽象，Spark的計算過程主要是RDD的迭代計算過程，如圖6所示。RDD的迭代計算過程很是相似於管道。分區數量取決於Partition數量的設定，每一個分區的數據只會在一個Task中計算。全部分區能夠在多個機器節點的Executor上並行執行。

 

圖6   RDD計算模型

圖6只是簡單的從分區的角度將RDD的計算看做是管道，若是從RDD的血緣關係、Stage劃分的角度來看，由RDD構成的DAG通過DAGScheduler調度後，將變成圖7所示的樣子。

 

圖7  DAGScheduler對由RDD構成的DAG進行調度

圖7中共展現了A、B、C、D、E、F、G一共7個RDD。每一個RDD中的小方塊表明一個分區，將會有一個Task處理此分區的數據。RDD A通過groupByKey轉換後獲得RDD B。RDD C通過map轉換後獲得RDD D。RDD D和RDD E通過union轉換後獲得RDD F。RDD B和RDD F通過join轉換後獲得RDD G。從圖中能夠看到map和union生成的RDD與其上游RDD之間的依賴是NarrowDependency，而groupByKey和join生成的RDD與其上游的RDD之間的依賴是ShuffleDependency。因爲DAGScheduler按照ShuffleDependency做爲Stage的劃分的依據，所以A被劃入了ShuffleMapStage 1；C、D、E、F被劃入了ShuffleMapStage 2；B和G被劃入了ResultStage 3。

Spark基本架構

從集羣部署的角度來看，Spark集羣由集羣管理器（Cluster Manager）、工做節點（Worker）、執行器（Executor）、驅動器（Driver）、應用程序（Application）等部分組成，它們之間的總體關係如圖8所示。

 

圖8   Spark基本架構圖

下面結合圖8對這些組成部分以及它們之間的關係進行介紹。

（1）Cluster Manager

Spark的集羣管理器，主要負責對整個集羣資源的分配與管理。Cluster Manager在Yarn部署模式下爲ResourceManager；在Mesos部署模式下爲Mesos master；在Standalone部署模式下爲Master。Cluster Manager分配的資源屬於一級分配，它將各個Worker上的內存、CPU等資源分配給Application，可是並不負責對Executor的資源分配。Standalone部署模式下的Master會直接給Application分配內存、CPU以及Executor等資源。目前，Standalone、YARN、Mesos、EC2等均可以做爲Spark的集羣管理器。

注意：這裏提到了部署模式中的Standalone、Yarn、Mesos等模式，讀者暫時知道這些內容便可，本書將在第9章對它們詳細介紹。

（2）Worker

Spark的工做節點。在Yarn部署模式下實際由NodeManager替代。Worker節點主要負責如下工做：將本身的內存、CPU等資源經過註冊機制告知Cluster Manager；建立Executor；將資源和任務進一步分配給Executor；同步資源信息、Executor狀態信息給Cluster Manager等。在Standalone部署模式下，Master將Worker上的內存、CPU以及Executor等資源分配給Application後，將命令Worker啓動CoarseGrainedExecutorBackend進程（此進程會建立Executor實例）。

（3）Executor

執行計算任務的一線組件。主要負責任務的執行以及與Worker、Driver的信息同步。

（4）Driver

Application的驅動程序，Application經過Driver與Cluster Manager、Executor進行通訊。Driver能夠運行在Application中，也能夠由Application提交給Cluster Manager並由Cluster Manager安排Worker運行。

（4）Application

用戶使用Spark提供的API編寫的應用程序，Application經過Spark API將進行RDD的轉換和DAG的構建，並經過Driver將Application註冊到Cluster Manager。Cluster Manager將會根據Application的資源需求，經過一級分配將Executor、內存、CPU等資源分配給Application。Driver經過二級分配將Executor等資源分配給每個任務，Application最後經過Driver告訴Executor運行任務。

小結

每項技術的誕生都會由某種社會需求所驅動，Spark正是在實時計算的大量需求下誕生的。Spark藉助其優秀的處理能力，可用性高，豐富的數據源支持等特色，在當前大數據領域變得火熱，參與的開發者也愈來愈多。Spark通過幾年的迭代發展，現在已經提供了豐富的功能。筆者相信，Spark在將來必將產生更耀眼的火花。

 

關於《Spark內核設計的藝術 架構設計與實現》

通過近一年的準備，基於Spark2.1.0版本的《Spark內核設計的藝術 架構設計與實現》一書現已出版發行，圖書如圖：

​

 

紙質版售賣連接以下：

京東：https://item.jd.com/12302500.html