好程序員大數據學習筆記：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的數量能夠酌情減小。

　　容錯機制:異或方式<相同爲0，不一樣爲1>

tupleId - 產生新數據，會產生一個tupleId;

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

　　若結果爲0，則數據正確，不然錯誤

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 設置爲0

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

3.在發送 tuple 的時候選擇發送「非錨定」的(unanchored)tuple

　　各位大數據愛好者，雖然如今學習之路很辛苦，前方的道路還有不少攻堅戰要打，但願你們這段時間沉下心來，無論有多累，都要向着前方，不斷的奔跑!