是Twitter開源的一個類似于Hadoop的實時資料處理架構（原來是由BackType開發，後BackType被Twitter收購，将Storm作為Twitter的實時資料分析）。實時資料處理的應用場景很廣泛，如上篇文章介紹S4時所說的個性化搜尋廣告的會話特征分析。而Yahoo當初建立S4項目的直接業務需求就是為了在搜尋引擎的‘cost-per-click’廣告中，能根據目前情景上下文（使用者偏好，地理位置，已發生的查詢和點選等）來估計使用者點選的可能性并實時做出調整。
這種高可拓展性，能處理高頻資料和大規模資料的實時流計算解決方案将被應用于實時搜尋，高頻交易和社交網絡上。而流計算并不是最近的熱點，金融機構的交易系統正是一個典型的流計算處理系統，它對系統的實時性和一緻性有很高要求。
twitter列舉了storm的三大作用領域：
1） 資訊流處理（Stream Processing）
Storm可以用來實時處理新資料和更新資料庫，兼具容錯性和可擴充性。
2） 連續計算（Continuous Computation）
Storm可以進行連續查詢并把結果即時回報給客戶，比如将Twitter上的熱門話題發送到用戶端。
3） 分布式遠端過程調用（Distributed RPC）
Storm可以用來并行處理密集查詢，Storm的拓撲結構（後文會介紹）是一個等待調用資訊的分布函數，當它收到一條調用資訊後，會對查
詢進行計算，并傳回查詢結果。
Storm的設計思想
在Storm中也有對于流stream的抽象，流是一個不間斷的無界的連續tuple，注意Storm在模組化事件流時，把流中的事件抽象為tuple即元組，後面會解釋storm中如何使用tuple。
Storm認為每個stream都有一個stream源，也就是原始元組的源頭，是以它将這個源頭抽象為spout，spout可能是連接配接twitter api并不斷發出tweets，也可能是從某個隊列中不斷讀取隊列元素并裝配為tuple發射。
有了源頭即spout也就是有了stream，那麼該如何處理stream内的tuple呢，同樣的思想twitter将流的中間狀态轉換抽象為Bolt，bolt可以消費任意數量的輸入流，隻要将流方向導向該bolt，同時它也可以發送新的流給其他bolt使用，這樣一來，隻要打開特定的spout（管口）再将spout中流出的tuple導向特定的bolt，又bolt對導入的流做處理後再導向其他bolt或者目的地。
我們可以認為spout就是一個一個的水龍頭，并且每個水龍頭裡流出的水是不同的，我們想拿到哪種水就擰開哪個水龍頭，然後使用管道将水龍頭的水導向到一個水處理器（bolt），水處理器處理後再使用管道導向另一個處理器或者存入容器中。
為了增大水處理效率，我們很自然就想到在同個水源處接上多個水龍頭并使用多個水處理器，這樣就可以提高效率。沒錯Storm就是這樣設計的，看到下圖我們就明白了。
對應上文的介紹，我們可以很容易的了解這幅圖，這是一張有向無環圖，Storm将這個圖抽象為Topology即拓撲（的确，拓撲結構是有向無環的），拓撲是storm中最高層次的一個抽象概念，它可以被送出到storm叢集執行，一個拓撲就是一個流轉換圖，圖中每個節點是一個spout或者bolt，圖中的邊表示bolt訂閱了哪些流，當spout或者bolt發送元組到流時，它就發送元組到每個訂閱了該流的bolt（這就意味着不需要我們手工拉管道，隻要預先訂閱，spout就會将流發到适當bolt上）。
插個位置說下storm的topology實作，為了做實時計算，我們需要設計一個拓撲圖，并實作其中的Bolt處理細節，Storm中拓撲定義僅僅是一些Thrift結構體（請google一下Thrift），這樣一來我們就可以使用其他語言來建立和送出拓撲。
上篇文章說過S4中PE間的事件傳遞是以一種(K,A)的元素傳遞，Storm則将流中元素抽象為tuple，一個tuple就是一個值清單value list，list中的每個value都有一個name，并且該value可以是基本類型，字元類型，位元組數組等，當然也可以是其他可序列化的類型。
拓撲的每個節點都要說明它所發射出的元組的字段的name，其他節點隻需要訂閱該name就可以接收處理。
說到這裡，Storm的核心實時處理思想就說完了，不過既然Storm要能發揮實時處理的能力就必須要由良好的架構設計和部署設計，接下來是Storm的叢集部署設計，這裡Storm的官方介紹得很清楚了，我就直接copy過來，再做一點分析。
Storm叢集表面類似Hadoop叢集。但在Hadoop上你運作的是”MapReduce jobs”，在Storm上你運作的是”topologies”。”Jobs”和”topologies”是大不同的，一個關鍵不同是一個MapReduce的Job最終會結束，而一個topology永遠處理消息（或直到你kill它）。
Storm叢集有兩種節點：控制（master）節點和工作者（worker）節點。
控制節點運作一個稱之為”nimbus”的背景程式，它類似于Haddop的”JobTracker”。Nimbus負責在叢集範圍内分發代碼、為worker配置設定任務和故障監測。
每個工作者節點運作一個稱之”Supervisor”的背景程式。Supervisor監聽配置設定給它所在機器的工作，基于Nimbus配置設定給它的事情來決定啟動或停止工作者程序。每個工作者程序執行一個topology的子集（也就是一個子拓撲結構）；一個運作中的topology由許多跨多個機器的工作者程序組成。
一個Zookeeper叢集負責Nimbus和多個Supervisor之間的所有協調工作（一個完整的拓撲可能被分為多個子拓撲并由多個supervisor完成）。
此外，Nimbus背景程式和Supervisor背景程式都是快速失敗（fail-fast）和無狀态的；所有狀态維持在Zookeeper或本地磁盤。這意味着你可以kill -9殺掉nimbus程序和supervisor程序，然後重新開機，它們将恢複狀态并繼續工作，就像什麼也沒發生。這種設計使storm極其穩定。這種設計中Master并沒有直接和worker通信，而是借助一個中介Zookeeper，這樣一來可以分離master和worker的依賴，将狀态資訊存放在zookeeper叢集内以快速回複任何失敗的一方。
grouping的種類。
stream grouping分類
1. Shuffle Grouping: 随機分組， 随機派發stream裡面的tuple， 保證每個bolt接收到的tuple數目相同.
2. Fields Grouping：按字段分組， 比如按userid來分組， 具有同樣userid的tuple會被分到相同的Bolts， 而不同的userid則會被配置設定到不同的Bolts.
3. All Grouping： 廣播發送， 對于每一個tuple， 所有的Bolts都會收到.
4. Global Grouping: 全局分組，這個tuple被配置設定到storm中的一個bolt的其中一個task.再具體一點就是配置設定給id值最低的那個task.
5. Non Grouping: 不分組，意思是說stream不關心到底誰會收到它的tuple.目前他和Shuffle grouping是一樣的效果,有點不同的是storm會把這個bolt放到這個bolt的訂閱者同一個線程去執行.
6. Direct Grouping: 直接分組,這是一種比較特别的分組方法，用這種分組意味着消息的發送者舉鼎由消息接收者的哪個task處理這個消息.隻有被聲明為Direct Stream的消息流可以聲明這種分組方法.而且這種消息tuple必須使用emitDirect方法來發射.消息處理者可以通過TopologyContext來或者處理它的消息的taskid (OutputCollector.emit方法也會傳回taskid)