好程式設計師大資料學習筆記：Storm架構

　　好程式設計師分享大資料學習筆記： Storm 架構 ， Storm 架構 :master/slave

 

　　主節點 :Nimbus

 

　　負責在叢集上進行任務 (Topology) 的分發與資源的排程以及監控

 

　　工作節點 :Supervisor

 

　　接收到任務請求後，啟動一個或多個 Worker 程式來處理任務 ; 預設情況下，一個 Supervisor 最多啟動 4 個 Worker

 

　　工作程式 :Worker

 

　　在 Supervisor 中的子程式，存在著若干個 Spout 和 Bolt 執行緒，來負責 Spout 和 Bolt 元件處理任務 ( 實際是開啟的 executor 執行緒 )

 

　　作業 :Topologies( 死迴圈，不會結束 )

 

　　Spout: 獲取資料的元件

 

　　Bolt: 處理資料的元件

 

　　Stream:Spout 和 Bolt 之間資料流動的通道

 

　　Tuple:

 

　　1)Stream 的最小組成單位， Spout 向 Bolt 傳送一次資料叫一個 Tuple

 

　　2) 同一個 Stream 中 Tuple 的型別相同，不同的 Stream 中可能相同 / 不同

 

　　3) 一個 key-value 形式的 Map

 

　　資料流分發策略 (Stream groupings):

 

　　解決 Spout 和 Bolt 之間資料傳輸 ( 傳送 Tuple 元組 ) 的問題

 

　　1)shuffleGrouping:

 

　　隨機派發 Stream 中的 Tuple 到 Bolt 中

 

　　2)fieldsGrouping:

 

　　根據欄位的雜湊值與 Bolt 個數進行取模操作然後進行分組傳送，一個節點是一個 Worker ， 一個 Bolt 是一個 task ， 全部節點的 Spout 或 Bolt 的個數叫併發度。

 

　　Storm 併發度設定 :

 

　　1.Worker 併發度 :

 

　　首先按照叢集規模和叢集的物理位置來設定

 

　　一般會把 Worker 均分到每一個節點裡， 一個 supervisor 預設設定一個 Worker

 

　　2.Spout 數量設定 :

 

　　Spout 總數預設等於 Kafka( 訊息中介軟體 ) 對應 Topic 的分割槽數，提高吞吐速度

 

　　一般一個 Worker 設定一個 Spout

 

　　3.Bolt1 數量設定 :

 

　　首先根據資料量和處理資料的時間來設定

 

　　一般情況下， Bolt1 的數量是 Spout 數量的 2 倍 ( 根據專案進行修改 )

 

　　4.Bolt2 數量設定 :

 

　　首先根據資料量和處理資料的時間來設定，因為 Bolt1 傳過來的中間結果資料已經減少很多， Bolt2 的數量可以酌情減少。

 

　　容錯機制 : 異或方式 < 相同為 ，不同為 1>

 

　　tupleId - 產生新資料，會產生一個 tupleId;

 

　　整個過程中的 tupleId 按順序兩兩異或到最後

 

　　若結果為 ，則資料正確，否則錯誤

 

　　messageId - 代表整條資訊， API 中指定提供給程式設計師， long 型

 

　　rootId - 代表某條資訊，提供給 storm 框架

 

　　出現資料運算失敗的兩種情況 :

 

　　execute(){

 

　　1. 異常 ( 資料異常 )

 

　　2. 任務執行超時 -- 認為處理失敗

 

　　}

 

　　因為資料傳送時導致的資料重複傳送問題， 如何解決 ?

 

　　Ⅰ .

 

　　1. 比如對訂單資訊做處理， 處理成功後， 把訂單資訊 ID 儲存到 Redis(set)

 

　　2. 資訊傳送時， 判斷是否處理過此資訊

 

　　execute(){

 

　　if()

 

　　else()

 

　　}

 

　　Ⅱ .

 

　　不作處理 : 點選流日日誌分析 : pv ， uv

 

　　指標分析 : 訂單人數， 訂單金額

 

　　訊息的可靠性保障和 acker 機制 : open / nextTuple / ack / fail/ close

 

　　Ⅰ .Spout 類 :

 

　　在傳送 tuple 時， Spout 會提供一個 msgId ，用於在後續識別 tuple;Storm 會根據 msgId 跟蹤建立的 tuple 樹，直到某個 tuple 被完整處理，根據 msgId 呼叫最初傳送 tuple 的 Spout 中 ack() 方法，檢測到超時就呼叫 fail() 方法 -- 這兩個方法的呼叫必須由最初建立這個 tuple 的 Spout 執行 ; 當 Spout 從訊息佇列 (Kafka/RocketMQ) 中取出一條資料時，實際上沒有被取出，而是保持一個掛起狀態，等待訊息完成的訊號，掛起狀態的資訊不會被髮送到其它的消費者 ; 當該訊息被 " 取出 " 時，佇列會將訊息體資料和一個唯一的 msgId 提供給客戶端，當 Spout 的 ack()/fail() 方法被呼叫時， Spout 根據傳送的 id 向佇列請求將訊息從佇列中移除 / 重新放入佇列。

 

　　Ⅱ .acker 任務 :

 

　　高效的實現可靠性 -- 必須顯式的在 Bolt 中呼叫定義在 Spout 中的 ack() 和 fail() 方法， Storm 拓撲有一些特殊的稱為 "acker" 的任務，負責跟蹤 Spout 傳送的 tuple 的 DAG ，當一個 acker 發現 DAG 結束後，它就會給建立 Spout tuple 的 Spout 任務傳送一條訊息，讓這個任務來應答這個訊息。 acker 並不會直接的跟蹤 tuple 樹，在 acker 樹中儲存了一個表，用於將 Spout tuple 的 id 與一對值相對映， id 為建立這個 tuple 的任務 id ，第二個值為一個 64bit 的數字 (ack val) ，這個值是這棵樹中所有被建立的或者被應答的 tuple 的 tuple id 進行異或運算的結果值。

 

　　Ⅲ . 移除可靠性 :

 

　　1. 將 Config.TOPOLOGY_ACKERS 設定為

 

　　2. 在 SpoutOutputCollector.emit 方法中省略訊息 id 來關閉 spout tuple 的跟蹤功能

 

　　3. 在傳送 tuple 的時候選擇傳送“非錨定”的 (unanchored)tuple

 

　　各位大資料愛好者，雖然現在學習之路很辛苦，前方的道路還有很多攻堅戰要打，希望大家這段時間沉下心來，不管有多累，都要向著前方，不斷的奔跑 !