一、 Storm簡介
Storm是由Nathan Marz開發的，一個免費並開源的分散式實時計算系統。
Storm是基於資料流的實時處理系統，提供了大吞吐量的實時計算能力。通過資料入口獲取每條到來的資料，在一條資料到達系統的時候，立即會在記憶體中進行相應的計算；Storm適合要求實時性較高的資料分析場景。
Storm 不處理靜態資料,但它處理連續的流資料。

二、 Storm的特點
Storm實現的一些特徵決定了它的效能和可靠性的，Storm使用 Netty 傳送訊息,消除了中間的排隊過程,使得訊息能夠直接在任務自身之間流動，在訊息的背後,是一種用於序列化和反序列化 Storm的原語型別的自動化且高效的機制。
Storm注重容錯和管理，Storm 實現了有保障的訊息處理,所以每個元組(Turple)都會通過拓撲(Topology)結構進行全面處理;如果發現一個元組還未處理,它會自動從Spout處重發，Storm 還實現了任務級的故障檢測，在一個任務發生故障時，訊息會自動重新分配以快速重新開始處理。Storm 包含比 Hadoop 更智慧的處理管理,流程會由zookeeper來進行管理,以確保資源得到充分使用。

Storm有如下優點：
1、 程式設計簡單：開發人員只需要關注應用邏輯，跟Hadoop相似，Storm提供的程式設計原語也很簡單，降低了開發並行實時處理的任務的複雜性。
2、 高效能，低延遲：可以應用於廣告搜尋引擎這種要求對廣告主的操作進行實時響應的場景。
3、 分散式：可以輕鬆應對資料量大，單機搞不定的場景
4、 可水平擴充套件： 隨著業務發展，資料量和計算量越來越大，系統可水平擴充套件。在Storm叢集中真正執行topology的主要有三個實體：工作程序、執行緒和任務。Storm叢集中的每臺機器上都可以執行多個工作程序，每個工作程序又可建立多個執行緒,每個執行緒可以執行多個任務,任務是真正進行資料處理的實體，我們開發的spout、bolt就是作為一個或者多個任務的方式執行的。因此，計算任務在多個執行緒，程序和伺服器之間並行進行,支援靈活的水平擴充套件。
5、 容錯性強：如果在訊息處理過程中出了一些異常，Storm會重新安排這個出問題的處理單元，Storm保證一個處理單元永遠執行(除非你顯式殺掉這個處理單元)。即單個節點掛了不影響應用。
6、 可靠性的訊息保證：Storm可以保證spout發出的每條訊息都能被“完全處理”。
7、 多語言支援，除了用java實現spout和bolt，根據Storm的多語言協議，可以使用任何你熟悉的程式語言來完成這項工作。多語言協議是Storm內部的一種特殊協議,允許spout或者bolt使用標準輸入和標準輸出來進行訊息傳遞，傳遞的訊息為單行文字或者是json編碼的多行。
8、 快速的訊息處理，用Netty作為底層訊息佇列, 保證訊息能快速被處理。
9、 本地模式，支援快速程式設計測試。

三、 storm與傳統資料庫
傳統關係型資料庫是先存後計算，而storm則是先算後存，甚至不存 。
傳統關係型資料庫很難部署實時計算，只能部署定時任務統計分析視窗資料 。 而storm是進行實時資料流處理的。

四、 storm與傳統大資料
storm 與其他大資料解決方案的不同之處在於它的處理方式。
Hadoop 在本質上是一個批處理系統｡資料被引入 Hadoop 檔案系統 (HDFS) 並分發到各個節點進行處理｡當處理完成時,結果資料返回到 HDFS 供始發者使用。storm 支援建立拓撲結構來轉換沒有終點的資料流。不同於 Hadoop 作業,這些轉換從不停止,它們會持續處理到達的資料。
Hadoop 的核心是使用 Java™ 語言編寫的,但支援使用各種語言編寫的資料分析應用程式。而 Twitter Storm 是使用 Clojure語言實現的。

五、 storm架構與原理
1、 Storm採用Master/Slave的主從體系結構,分散式計算由Nimbus和Supervisor兩類服務程序實現,Nimbus程序執行在叢集的主節點,負責任務的指派和分發,Supervisor執行在叢集的從節點,負責執行任務的具體部分。

如圖所示：
Nimbus:負責資源分配和任務排程。
Supervisor:負責接受nimbus分配的任務,啟動和停止屬於自己管理的worker程序。
Worker:執行具體處理元件邏輯的程序。
Task:worker中每一個spout/bolt的執行緒稱為一個task｡同一個spout/bolt的task可能會共享一個物理執行緒,該執行緒稱為executor。
Storm叢集和Hadoop叢集表面上看很類似。但是Hadoop上執行的是MapReduce jobs,而在Storm上執行的是拓撲(topology),這兩者之間是非常不一樣的，一個關鍵的區別是: 一個MapReduce job最終會結束, 而一個topology永遠會執行(除非你手動kill掉)。
storm架構中使用Spout/Bolt程式設計模型來對訊息進行流式處理｡訊息流是storm中對資料的基本抽象,一個訊息流是對一條輸入資料的封裝,源源不斷輸入的訊息流以分散式的方式被處理，Spout元件是訊息生產者，是storm架構中的資料輸入源頭，它可以從多種異構資料來源讀取資料，併發射訊息流，Bolt元件負責接收Spout元件發射的資訊流，並完成具體的處理邏輯｡在複雜的業務邏輯中可以串聯多個Bolt元件，在每個Bolt元件中編寫各自不同的功能，從而實現整體的處理邏輯。

• 在Storm的叢集裡面有兩種節點: 控制節點(master node)和工作節點(worker node)。控制節點上面執行一個叫Nimbus後臺程式,它的作用類似Hadoop裡面的JobTracker，Nimbus負責在叢集裡面分發程式碼，分配計算任務給機器，並且監控狀態。每一個工作節點上面執行一個叫做Supervisor的程序。Supervisor會監聽分配給它那臺機器的工作，根據需要啟動/關閉工作程序worker。每一個工作程序執行一個topology的一個子集；一個執行的topology由執行在很多機器上的很多工作程序worker組成。(一個supervisor裡面有多個workder，一個worker是一個JVM。可以配置worker的數量，對應的是conf/storm.yaml中的supervisor.slot的數量）
• Nimbus和Supervisor之間的所有協調工作都是通過Zookeeper叢集完成。另外，Nimbus程序和Supervisor程序都是快速失敗(fail-fast)和無狀態的｡所有的狀態要麼在zookeeper裡面, 要麼在本地磁碟上。這也就意味著你可以用kill -9來殺死Nimbus和Supervisor程序,然後再重啟它們，就好像什麼都沒有發生過，這個設計使得Storm異常的穩定。
2、 Topology
在Storm中,一個實時應用的計算任務被打包作為Topology釋出，這同Hadoop的MapReduce任務相似。但是有一點不同的是:在Hadoop中，MapReduce任務最終會執行完成後結束；而在Storm中，Topology任務一旦提交後永遠不會結束，除非你顯示去停止任務。計算任務Topology是由不同的Spouts和Bolts，通過資料流（Stream）連線起來的圖｡下面是一個Topology的結構示意圖：

• Spout：Storm中的訊息源,用於為Topology生產訊息(資料),一般是從外部資料來源(如Message Queue、RDBMS、NoSQL、Realtime Log ）不間斷地讀取資料併發送給Topology訊息(tuple元組)。
• Bolt：Storm中的訊息處理者，用於為Topology進行訊息的處理，Bolt可以執行過濾，聚合， 查詢資料庫等操作，而且可以一級一級的進行處理。

3、 分組機制
Stream Grouping定義了一個流在Bolt任務間該如何被切分。這裡有Storm提供的6個Stream Grouping型別：
1、 隨機分組
隨機分發tuple到Bolt的任務，保證每個任務獲得相等數量的tuple。

2、 欄位分組
根據指定欄位分割資料流，並分組。例如，根據“user-id”欄位，相同“user-id”的元組總是分發到同一個任務，不同“user-id”的元組可能分發到不同的任務。

3、 全部分組
tuple被複制到bolt的所有任務。這種型別需要謹慎使用。

4、 全域性分組
全部流都分配到bolt的同一個任務。明確地說，是分配給ID最小的那個task。

5、 無分組
你不需要關心流是如何分組。目前，無分組等效於隨機分組。但最終，Storm將把無分組的Bolts放到Bolts或Spouts訂閱它們的同一執行緒去執行（如果可能）。

6、 直接分組
這是一個特別的分組型別。元組生產者決定tuple由哪個元組處理者任務接收。

7、 通過實現CustomStreamGrouping定義自己的分組模式
4、

六、 storm和Hadoop的架構對比
他們的總體架構相似。

在Hadoop架構中,主從節點分別執行JobTracker和TaskTracker程序,在storm架構中,主從節點分別執行Nimbus和Supervisor程序。在Hadoop架構中,應用程式的名稱是Job,Hadoop將一個Job解析為若干Map和Reduce任務,每個Map或Reduce任務都由一個Child程序來執行,該Child程序是由TaskTracker在子節點上產生的子程序。
在Storm架構中,應用程式的名稱是Topology,Storm將一個Topology劃分為若干個部分,每部分由一個Worker程序來執行,該Worker程序是Supervisor在子節點上產生的子程序,在每個Worker程序中存在著若干Spout和Bolt執行緒,分別負責Spout和Bolt元件的資料處理過程。
從應用程式的比較中可以看明顯地看到Hadoop和Storm架構的主要不同之處｡在Hadoop架構中,應用程式Job代表著這樣的作業:輸入是確定的,作業可以在有限時間內完成,當作業完成時Job的生命週期走到終點,輸出確定的計算結果；而在Storm架構中,Topology代表的並不是確定的作業,而是持續的計算過程，在確定的業務邏輯處理框架下,輸入資料來源源不斷地進入系統，經過流式處理後以較低的延遲產生輸出。如果不主動結束這個Topology或者關閉Storm叢集,那麼資料處理的過程就會持續地進行下去。
通過以上的分析，我們可以看到，storm架構是如何解決Hadoop架構瓶頸的：
Storm的Topology只需初始化一次。在將Topology提交到Storm叢集的時候,叢集會針對該Topology做一次初始化的工作，此後,在Topology執行過程中,對於輸入資料而言,是沒有計算框架初始化耗時的,有效避免了計算框架初始化的時間損耗。
Storm使用Netty作為底層的訊息佇列來傳遞訊息,保證訊息能夠得到快速的處理，同時Storm採用記憶體計算模式,無需藉助檔案儲存,直接通過網路直傳中間計算結果,避免了元件之間傳輸資料的大量時間損耗。

七、 Storm的操作模式
本地模式：
在本地模式下，Storm拓撲結構執行在本地計算機的單一JVM程序上。這個模式用於開發、測試以及除錯，因為這是觀察所有元件如何協同工作的最簡單方法。在這種模式下，我們可以調整引數，觀察我們的拓撲結構如何在不同的Storm配置環境下執行。要在本地模式下執行，我們要下載Storm開發依賴，以便用來開發並測試我們的拓撲結構。我們建立了第一個Storm工程以後，很快就會明白如何使用本地模式了。
NOTE: 在本地模式下，跟在叢集環境執行很像。不過很有必要確認一下所有元件都是執行緒安全的，因為當把它們部署到遠端模式時它們可能會執行在不同的JVM程序甚至不同的物理機上，這個時候它們之間沒有直接的通訊或共享記憶體。
遠端模式：
在遠端模式下，我們向Storm叢集提交拓撲，它通常由許多執行在不同機器上的流程組成。遠端模式不會出現除錯資訊， 因此它也稱作生產模式。不過在單一開發機上建立一個Storm叢集是一個好主意，可以在部署到生產環境之前，用來確認拓撲在叢集環境下沒有任何問題。

八、 Storm的使用場景
Storm的流式處理計算模式保證了任務能夠只進行一次初始化,就能夠持續計算,同時使用了ZeroMQ（Netty）作為底層訊息佇列,有效地提高了整體架構的資料處理效率,避免了Hadoop的瓶頸。以下是一些適合Storm工作的場景。
1、 流聚合
基於一些tuple欄位，將兩個或以上的資料流聚合成一個數據流。
2、 批處理
提高效率、效能
3、 BasicBolt

1. 讀一個輸入tuple
2. 根據這個輸入tuple發射一個或者多個tuple
3. 在execute的方法的最後ack那個輸入tuple

遵循這類模式的bolt一般是函式或者是過濾器, 這種模式太常見，storm為這類模式單獨封裝了一個介面: IbasicBolt

4、 記憶體內快取+fileds grouping
在bolt的記憶體裡面快取一些東西非常常見。快取在和fields grouping結合起來之後就更有用了。

5、 計算top N
6、 使用TimeCacheMap來高效地儲存一個最近被更新的物件的快取
有時候你想在記憶體裡面儲存一些最近活躍的物件，以及那些不再活躍的物件。 TimeCacheMap 是一個非常高效的資料結構，提供了一些callback函式使得我們在物件不再活躍的時候我們可以做一些事情
九、 分散式RPC:CoordinatedBolt和KeyedFairBolt
用storm做分散式RPC應用的時候有兩種比較常見的模式:它們被封裝在CoordinatedBolt和KeyedFairBolt裡面. CoordinatedBolt包裝你的bolt,並且確定什麼時候你的bolt已經接收到所有的tuple,它主要使用Direct Stream來做這個.
KeyedFairBolt同樣包裝你的bolt並且保證你的topology同時處理多個DRPC呼叫，而不是序列地一次只執行一個。