透過案例對SparkStreaming透徹理解三板斧之二

 Spark Streaming執行時與其說是Spark Core上的一個流式處理框架，不如說是Spark Core上的一個最複雜的應用程式。如果可以掌握Spark streaming這個複雜的應用程式，那麼其他的再複雜的應用程式都不在話下了。

       我們知道Spark Core處理的每一步都是基於RDD的，RDD之間有依賴關係。上圖中的RDD的DAG顯示的是有3個Action，會觸發3個job，RDD自下向上依賴，RDD產生job就會具體的執行。從DSteam Graph中可以看到，DStream的邏輯與RDD基本一致，它就是在RDD的基礎上加上了時間的依賴。RDD的DAG又可以叫空間維度，也就是說整個Spark Streaming多了一個時間維度，也可以成為時空維度。

       從這個角度來講，可以將Spark Streaming放在座標系中。其中Y軸就是對RDD的操作，RDD的依賴關係構成了整個job的邏輯，而X軸就是時間。隨著時間的流逝，固定的時間間隔（Batch Interval）就會生成一個job例項，進而在叢集中執行。

       對於Spark Streaming來說，當不同的資料來源的資料流進來的時候，基於固定的時間間隔，會形成一系列固定不變的資料集或event集合（例如來自flume和kafka）。而這正好與RDD基於固定的資料集不謀而合，事實上，由DStream基於固定的時間間隔行程的RDD Graph正是基於某一個batch的資料集的。

從上圖中可以看出，在每一個batch上，空間維度的RDD依賴關係都是一樣的，不同的是這個五個batch流入的資料規模和內容不一樣，所以說生成的是不同的RDD依賴關係的例項，所以說RDD的Graph脫胎於DStream的Graph，也就是說DStream就是RDD的模版，不同的時間間隔，生成不同的RDD Graph例項。

從Spark Streaming本身出發：

1.需要RDD DAG的生成模版：DStream Graph

2需要基於Timeline的job控制器

3需要inputStreamings和outputStreamings，代表資料的輸入和輸出

4具體的job執行在Spark Cluster之上，由於streaming不管叢集是否可以消化掉，此時系統容錯就至關重要

5事務處理，我們希望流進來的資料一定會被處理，而且只處理一次。在處理出現崩潰的情況下如何保證Exactly once的事務語意。

從原始碼解讀DStream

從這裡可以看出，DStream就是Spark Streaming的核心，就想Spark Core的核心是RDD，它也有dependency和compute。更為關鍵的是下面的程式碼：

       這是一個HashMap，以時間為key，以RDD為value，這也正應證了隨著時間流逝，不斷的生成RDD，產生依賴關係的job，並透過jobScheduler在叢集上執行。再次驗證了DStream就是RDD的模版。

      DStream可以說是邏輯級別的，RDD就是物理級別的，DStream所表達的最終都是透過RDD的轉化實現的。前者是更高階別的抽象，後者是底層的實現。DStream實際上就是在時間維度上對RDD集合的封裝，DStream與RDD的關係就是隨著時間流逝不斷的產生RDD，對DStream的操作就是在固定時間上操作RDD。

總結：

在空間維度上的業務邏輯作用於DStream，隨著時間的流逝，每個Batch Interval形成了具體的資料集，產生了RDD，對RDD進行transform操作，進而形成了RDD的依賴關係RDD DAG，形成job。然後jobScheduler根據時間排程，基於RDD的依賴關係，把作業釋出到Spark Cluster上去執行，不斷的產生Spark作業。

備註：

資料來源於：DT_大資料夢工廠（Spark發行版本定製）

作者：陽光男孩spark
連結：