Spark Streaming揭祕 Day30 集羣模式下SparkStreaming日誌分析

Spark Streaming揭祕 Day30

集羣模式下SparkStreaming日誌分析

今天經過集羣運行模式觀察、研究和透徹的刨析SparkStreaming的日誌和web監控臺。

Day28已經分析過local模式下的日誌，集羣模式會比較相似，此次主要是對集羣模式在的web監控臺，進行統一的深度刨析。

咱們從wordcount程序開始，代碼以下，爲了展現出SparkStreaming在集羣中的運行，Batch Duration設置爲5分鐘。

系統做業

爲了觀察持續運行的狀況，咱們運行了10分鐘，一共產生了6個Job，Job0和Job1是框架產生的系統Job。

首先咱們會看見一個Job0，這個是SparkStreaming啓動時進行自檢的dummy Job，前面課程曾經介紹過，目標是爲了資源的平衡和最大化。

Job1一直處於active狀態，其內部是一個Receiver，爲了啓動Receiver進行數據接收而產生的，咱們發現這個Job只運行在一臺機器上。

無數據處理做業

下面看下Streaming專有的控制檯。咱們進行了多個Batch的處理，其中第一個Batch沒有數據，而第二個Batch有數據，咱們發現就算沒有數據，由於也會執行一個action，因此也會有處理時間。

首先是Batch1，其中並無數據發生，這個Batch由Job2和Job3組成。

咱們進入Job2，裏面有2個Stage，裏面雖然觸發了一個action，可是由於沒數據，因此啥也沒幹，只是走了一個形式。

咱們會發現第一個Stage中沒有Task運行。

第二個Stage，是隻有一個Task在worker2運行，進行reduce操做。

有數據處理做業

從日誌看，發如今輸入讀入時，在2個worker上進行數據存入，有兩個是由於存儲級別默認爲MEMORY_AND_DISK_SER_2，有備份機制。

有數據輸入Batch2由Job4和Job5組成。

咱們看下Job4，第一個Stage再也不跳過，這個時候，就有具體的數據處理了

第一個Stage，運行在worker4的機器上，和receiver在一塊兒。並且數據是在內存中(NODE_LOCAL)。主要進行了Shuffle write，寫入了4條數據。

第二個Stage，在worker4上運行，shuffle read了3個record。

Job5中，也是運行在worker4上，shuffle read了1個record。

在這裏，咱們發現了一個現象：從web控制檯來看，一個Batch Duration產生2個Job，共同完成了這個Batch中所有record的處理，分了2個Job來shuffle read數據。

多Job機制再研究

從上述描述，咱們看到一個print函數會由多個Job協做完成，這個是否是偶發現象，咱們作個實驗。
把代碼中分區數調爲8，從新運行程序：

這個時候，咱們發現同時運行的Job變成了3個，3個Job一共運行了8個Task！！！

這個是spark1.6的新特性，框架在作做業調度的時候，爲了更大化的利用集羣的資源，把咱們的task分發成不一樣的Job，每一個Job負責一部分的Task。啓動多個Job，好處是能夠支持無限的自動重啓提升可靠性。
這個處理代價不是太大，緣由是在SparkStreaming角度講只是封裝了Runnable對象，是一種輕量級的處理。具體實現看，在JobGenerator中，在產生Jobset提交到JobScheduler的時候，會根據並行度等規則，把Job分紅了不一樣的子Job。這個子Job的拆分，咱們下節課來分析。

欲知後事如何，且聽下回分解!

DT大數據天天晚上20：00YY頻道現場授課頻道68917580