storm 初識

Storm是什麼？

Storm是一個分佈式的實時流處理框架。

“實時”怎麼理解？

“實時”一般指的是near real-time（近實時），即系統對特定事件處理的響應時間對終端用戶沒有明顯的延遲，通常響應時間爲毫秒級別。對於Storm來說，實時（sub-second time，亞秒級）和近實時（幾秒或幾分鐘，具體取決於使用的場景）都是可能的。

什麼是流處理？它和批處理的區別是什麼？

流處理指的是將數據看做流，持續不斷的數據形成了數據流，當最新的數據到來時，就立刻處理並返回處理結果。它的處理過程都是在內存中進行的，通常不會對數據做持久化存儲。

它和批處理的區別在於批處理是先存儲再處理，而流處理則直接處理。

詳見這篇文章http://blog.csdn.net/qiruiduni/article/details/50481031的“大數據的處理模式部分”。

相關概念

• Topology
  Topology可以把它看做一棵樹，樹的每個節點爲一個task，也可以看做是Spout或Bolt，圖中節點之間連接線可以看做爲流（Stream）。Topology和Hadoop中的Job很類似，都可以看做一個業務作業。
  
• Tuple
  在Topology中，節點之間傳輸數據以Tuple（元組）的形式發送的，它是Storm的主要數據結構，可以把它看做一個有序的值列表，每個value都有相應的名稱，像這樣的結構：[name1="value1", name="value2"]，value的類型是動態的，不需要聲明指定，但是Storm需要知道怎麼序列化這些value值，默認，Storm知道怎麼序列化一些基本的數據類型，如String、byte array等。如果要使用其他的類型，需要實現序列化，併爲該類型註冊一個序列化器。
• Stream
  Topology中，節點之間的連線就可看做爲Stream，它是一個無限的Tuple序列。
• Spout
  Spout是Topology中的源，它負責從一個外部的數據源讀取數據併發送Tuple給下一個節點。它可以監聽一個消息隊列、監聽一個數據庫的變化等，它不對數據做任何處理，僅是讀取併發送。
• Bolt
   Bolt是Topology中的工作節點，它接收Tuple作爲輸入，並對Tuple做一些計算或轉換（過濾、聚合、合併），然後把處理結果以一個Tuple發出（也可以不發出）。
• Stream Grouping
  Stream grouping定義了Tuple是如何在Spout和Bolt之間傳輸分發的，分發的形式主要有以下幾種：
  • Shuffle Grouping
    Shuffle Grouping將Tuple隨機（random）分發給Bolts，這種分發方式可以保證每個bolt能夠接收到大致相等的Tuple數量，但並保證是絕對完全相等的。通常適用於不須關心數據是怎麼分發給Bolt的情景。
  • Fields Grouping
    Fields grouping保證對於特定的field name的值總是能夠被髮送到同一個Bolt實例。
  • All Grouping
  • Global Grouping
  • Custom Grouping
  • ....

Storm 的可靠性

Storm的可靠性是指Storm有能力能夠保證一個Message（Tuple）能夠被Topology中的節點完全處理。

那麼，“完全處理”該怎麼理解？

一個Tuple從Spout發出，會導致下游多個bolt的Tuple發出，就形成了一個Tuple Tree，從Spout發出的Tuple稱爲樹根root，Tuple每經過一個節點都會被打上一個“已處理”的標記，直到最後一個葉子節點成功完成處理，然後會調用一個ack()回執方法，通知Storm該Tuple已完全處理。如果在某個節點處理時發生錯誤或異常，將會調用fail()方法，通知該Tuple處理失敗，然後Storm會重放（replay）該Tuple，以確保該Tuple被完全處理。整個過程無論是成功處理，還是失敗重新處理，都被理解爲完全處理。

實際是怎麼工作的？

實際Storm通過一個Acker（錨定）組件，來追蹤Tuple Tree 中Tuple的狀況。每一個從Spout流出的Tuple都會被打上一個錨定（Anchoring），如果成功處理，就會調用ack()方法向Storm報告已完全處理，如果出現異常，就會調用fail()方法，通知Storm重新（replay）處理。然後Tuple流入到下游的bolt，也是按同樣的方式來處理Tuple。

對於Bolt中的Tuple的可靠性有兩種形式：隱式（implicit）和顯示（explicit），這兩種形式主要和bolt的實現有關，如果bolt使用的是BaseBasicBolt實現，那麼Storm會自動爲Tuple打上Anchoring，並且自動通知Storm對Tuple的處理情況。對於BaseBasicBolt的實現通常適用於比較簡單的情況，對於較複雜的（如：聚合、流入多個Stream），通常要用BaseRichBolt實現來顯示打上Anchoring，如：outputCollector.emit(tuple, new Values(order))，如果沒有顯示指定，該Tuple不會被加入Tuple tree，在該Tuple失敗時，也不會通知Storm。同樣ack/fail時也要顯示指定。

對於Spout來說，每一個發出的Tuple都有一個對應的messageId，如果沒有設定messageId，Storm將不會對Tuple進行追蹤。同樣，一個可靠的（reliable）數據源也是至關重要的，因爲對一個不可靠的數據源來說，它發送的消息是不可replay的。

可靠性程度級別：

• At-most-once processing
• At-least-once processing
• Exactly-once processing

總的來說，Storm的可靠性需要滿足以下四個方面：

1. 可靠的數據來源。
2. 一個帶有Anchoring的Tuple Stream。
3. 在Tuple處理成功或失敗時，Topology能夠得到通知（ack）。
4. 一個具有容錯性（fault-tolerant）的Storm集羣。

Storm的容錯性

Storm 集羣

一個Storm集羣包含兩種類型的節點：master node和worker node，master node只有一個，它運行一個稱之爲Nimbus的守護進程。剩下的其它節點就是worker node節點了，每個worker節點都運行着一個稱之爲Supervisor的守護進程。

Master 節點主要負責分發代碼、給worker 節點分配task、監控失敗節點以及運行Storm UI等。

Worker 節點主要負責監聽分配的任務、啓動/停止worker進程等。

下圖爲Storm集羣中各個組件及各個組件的相應職責：

       

Storm集羣依賴於ZooKeeper，通過ZooKeeper來協調Nimbus和各個Supervisor的交互，並保存每個Nimbus和Supervisor的交互狀態。如下圖：

1、An executor is a thread of execution within a JVM. A task is an instance of a spout or bolt running within that thread of execution

2、replaying always starts at the spout

Storm調優

對系統優化，向來都是一個比較艱鉅的任務，但Storm提供了一個能夠快速找出應用瓶頸的工具：Storm UI，通過它可以看到Storm的運行狀況，包括每個Topology運行狀態的統計、Topology的配置信息、每個Spout、Bolt的運行狀況的統計以及相關的錯誤信息等。

對於Storm的調優，通常主要從兩個方面來調整：並行和延遲。

並行

對Bolt來說，主要觀察Storm UI的Bolt欄的“Capacity”列，該列顯示了每個Bolt在特定時間窗口內處理Tuple所花費的時間百分比，如果某些列值接近於1，表明該Bolt在“滿負荷”工作，就可以把它認爲一個瓶頸，解決這個瓶頸的方式就是增加這個Bolt的並行度。

對Spout來說，主要控制數據流入Topology的流速，即控制Spout的並行度。可從兩個方面設置：1）、spout的數量  2）、每個Spout允許保留Tuple的最大數量，即未確認（unacked）的Tuple數量。對於第2點，是通過Spout的一個概念max spout pending來設置的，它允許我們控制Spout的攝取率，當在有大量數據涌入Topology時，可以保證Topology不會崩潰，它就像在Topology前面築起了一座大壩。當然不設置它，數據仍是會繼續流入Topology的。

延遲

對於延遲，分爲外部和內部原因造成的延遲，外部原因主要體現在網絡的延遲、GC造成的延遲、低效查詢數據庫的延遲、讀取磁盤尋道造成的延遲等幾方面。內部原因主要體現在和數據相關引起的延遲，比如對某個失敗的Tuple反覆的重試等。對於外部原因，可以考慮增加網絡的吞吐量、優化JVM設置，降低GC的次數等，對於內部原因，可以對一些壞數據、錯誤異常等做相關處理。