Spark版本定製第2天:經過案例對SparkStreaming透徹理解之二微信
本期內容:架構
1 解密Spark Streaming運行機制框架
2 解密Spark Streaming架構大數據
一切不能進行實時流處理的數據都是無效的數據。在流處理時代,SparkStreaming有着強大吸引力,並且發展前景廣闊,加之Spark的生態系統,Streaming能夠方便調用其餘的諸如SQL,MLlib等強大框架,它必將一統天下。spa
Spark Streaming運行時與其說是Spark Core上的一個流式處理框架,不如說是Spark Core上的一個最複雜的應用程序。若是能夠掌握Spark streaming這個複雜的應用程序,那麼其餘的再複雜的應用程序都不在話下了。這裏選擇Spark Streaming做爲版本定製的切入點也是大勢所趨。3d
咱們知道Spark Core處理的每一步都是基於RDD的,RDD之間有依賴關係。上圖中的RDD的DAG顯示的是有3個Action,會觸發3個job,RDD自下向上依賴,RDD產生job就會具體的執行。從DSteam Graph中能夠看到,DStream的邏輯與RDD基本一致,它就是在RDD的基礎上加上了時間的依賴。RDD的DAG又能夠叫空間維度,也就是說整個Spark Streaming多了一個時間維度,也能夠成爲時空維度。orm
從這個角度來說,能夠將Spark Streaming放在座標系中。其中Y軸就是對RDD的操做,RDD的依賴關係構成了整個job的邏輯,而X軸就是時間。隨着時間的流逝,固定的時間間隔(Batch Interval)就會生成一個job實例,進而在集羣中運行。blog
對於Spark Streaming來講,當不一樣的數據來源的數據流進來的時候,基於固定的時間間隔,會造成一系列固定不變的數據集或event集合(例如來自flume和kafka)。而這正好與RDD基於固定的數據集不謀而合,事實上,由DStream基於固定的時間間隔行程的RDD Graph正是基於某一個batch的數據集的。事務
從上圖中能夠看出,在每個batch上,空間維度的RDD依賴關係都是同樣的,不一樣的是這個五個batch流入的數據規模和內容不同,因此說生成的是不一樣的RDD依賴關係的實例,因此說RDD的Graph脫胎於DStream的Graph,也就是說DStream就是RDD的模版,不一樣的時間間隔,生成不一樣的RDD Graph實例。kafka
從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發行版本定製)
更多私密內容,請關注微信公衆號:DT_Spark
若是您對大數據Spark感興趣,能夠免費聽由王家林老師天天晚上20:00開設的Spark永久免費公開課,地址YY房間號:68917580