分布式流式處理框架：Storm
Storm是一個免費開源、分布式、高容錯的實時計算系統。它與其他大數據解決方案的不同之處在于它的處理方式。Hadoop 在本質上是一個批處理系統，數據被引入 Hadoop 文件系統 (HDFS) 并分發到各個節點進行處理。當處理完成時，結果數據返回到 HDFS 供始發者使用。Hadoop的高吞吐，海量數據處理的能力使得人們可以方便地處理海量數據。但是，Hadoop的缺點也和它的優點同樣鮮明——延遲大，響 應緩慢，運維復雜。Storm就是為了彌補Hadoop的實時性為目標而被創造出來。Storm 支持創建拓撲結構來轉換沒有終點的數據流。不同于 Hadoop 作業，這些轉換從不停止，它們會持續處理到達的數據。Storm經常用于在實時分析、在線機器學習、持續計算、分布式遠程調用和ETL等領域。Storm 的部署管理非常簡單，而且，在同類的流式計算工具，Storm的性能也是非常出眾的。
Strom的優點：
- 簡單的編程模型。類似于MapReduce降低了并行批處理復雜性，Storm降低了進行實時處理的復雜性。
- 可以使用各種編程語言。你可以在Storm之上使用各種編程語言。默認支持Clojure、Java、Ruby和Python。要增加對其他語言的支持，只需實現一個簡單的Storm通信協議即可。
- 容錯性。Storm會管理工作進程和節點的故障。模塊都是無狀態的，隨時宕機重啟。由于是分布式，一個節點掛了不能影響系統的正常運行。
- 水平擴展。計算是在多個線程、進程和服務器之間并行進行的。
- 可靠的消息處理。Storm保證每個消息至少能得到一次完整處理。任務失敗時，它會負責從消息源重試消息。
- 快速。系統的設計保證了消息能得到快速的處理，使用ZeroMQ（新的消息機制使用netty代替ZeroMQ）作為其底層消息隊列。
- 本地模式。Storm有一個“本地模式”，可以在處理過程中完全模擬Storm集群。這讓你可以快速進行開發和單元測試。 </ul>
- Nimbus：負責資源分配和任務調度。集群里面發送代碼，分配工作給機器，并且監控狀態。全局只有一個。
- Supervisor：負責接受nimbus分配的任務，啟動和停止屬于自己管理的worker進程。會監聽分配給它那臺機器的工作，根據需要啟動/關閉工作進程Worker。每一個要運行Storm的機器上都要部署一個，并且，按照機器的配置設定上面分配的槽位數。
- Worker：運行具體處理組件邏輯的進程。
- Task：worker中每一個spout/bolt的線程稱為一個task. 在storm0.8之后，task不再與物理線程對應，同一個spout/bolt的task可能會共享一個物理線程，該線程稱為executor。
- Zookeeper：Storm重點依賴的外部資源。Nimbus和Supervisor甚至實際運行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根據Zookeerper上的心跳和任務運行狀況，進行調度和任務分配的。
- Topology：storm中運行的一個實時應用程序，因為各個組件間的消息流動形成邏輯上的一個拓撲結構。Topology處理的最小的消息單位是一個Tuple，也就是一個任意對象的數組。Topology由Spout和Bolt構成。
- Spout：在一個topology中產生源數據流的組件。通常情況下spout會從外部數據源（如Message Queue、RDBMS、NoSQL、Realtime Log）中讀取數據，然后轉換為topology內部的源數據。Spout是一個主動的角色，其接口中有個nextTuple()函數，storm框架會 不停地調用此函數，用戶只要在其中生成源數據即可。
- Bolt：在一個topology中接受數據然后執行處理的組件。Bolt可以執行過濾、函數操作、合并、寫數據庫等任何操作。Bolt是一個被 動的角色，其接口中有個execute(Tuple input)函數,在接受到消息后會調用此函數，用戶可以在其中執行自己想要的操作。
- Tuple：一次消息傳遞的基本單元。本來應該是一個key-value的map，但是由于各個組件間傳遞的tuple的字段名稱已經事先定義好，所以tuple中只要按序填入各個value就行了，所以就是一個value list。
- Stream：源源不斷傳遞的tuple就組成了stream。是Storm中對數據進行的抽象，它是時間上無界的tuple元組序列。在 Topology中，Spout是Stream的源頭，負責為Topology從特定數據源發射Stream；Bolt可以接收任意多個Stream作為 輸入，然后進行數據的加工處理過程，如果需要，Bolt還可以發射出新的Stream給下級Bolt進行處理。
- Stream Grouping即消息的partition方法。目前Storm中提供了以下7種Stream Grouping策略：Shuffle Grouping、Fields Grouping、All Grouping、Global Grouping、Non Grouping、Direct Grouping、Local or shuffle grouping，具體策略可以參考這里。 </ul>
- 流數據處理。Storm可以用來處理源源不斷流進來的消息，處理之后將結果寫入到某個存儲中去。
- 分布式rpc。由于storm的處理組件是分布式的，而且處理延遲極低，所以可以作為一個通用的分布式rpc框架來使用。 </ul>
- 一淘-實時分析系統pora：實時分析用戶的屬性，并反饋給搜索引擎。最初，用戶屬性分析是通過每天在云梯上定時運行的MR job來完成的。為了滿足實時性的要求，希望能夠實時分析用戶的行為日志，將最新的用戶屬性反饋給搜索引擎，能夠為用戶展現最貼近其當前需求的結果。
- 攜程-網站性能監控：實時分析系統監控攜程網的網站性能。利用HTML5提供的performance標準獲得可用的指標，并記錄日志。Storm集群實時分析日志和入庫。使用DRPC聚合成報表，通過歷史數據對比等判斷規則，觸發預警事件。 </ul>
Storm的組成：
在介紹Storm前我們先來看下它與Hadoop的對比：
Storm主要分為兩種組件Nimbus和Supervisor。這兩種組件都是快速失敗的，沒有狀態。任務狀態和心跳信息等都保存在Zookeeper上的，提交的代碼資源都在本地機器的硬盤上。Storm中的一些概念：
下圖描述了Nimbus、Supervisor、Worker、Task、Zookeeper這幾個角色之間的關系：
在Storm中，一個實時應用的計算任務被打包作為Topology發布，這同Hadoop的MapReduce任務相似。但是有一點不同的是：在Hadoop中，MapReduce任務最終會執行完成后結束；而在Storm中，Topology任務一旦提交后永遠不會結束，除非你顯示去停止任務。計算任務Topology是由不同的Spouts和Bolts，通過數據流（Stream）連接起來的圖。下面是一個Topology的結構示意圖：
Topology中每一個計算組件（Spout和Bolt）都有一個并行執行度，在創建Topology時可以進行指定，Storm會在集群內分配 對應并行度個數的線程來同時執行這一組件。既然對于一個Spout或Bolt，都會有多個task線程來運行，那么如何在兩個組件（Spout和 Bolt）之間發送tuple元組呢？Storm提供了若干種數據流分發（Stream Grouping）策略用來解決這一問題。在Topology定義時，需要為每個Bolt指定接收什么樣的Stream作為其輸入（注：Spout并不需 要接收Stream，只會發射Stream）。
下圖是Topology的提交流程圖：
Storm 的一個最有趣的地方是它注重容錯和管理。Storm 實現了有保障的消息處理，所以每個元組都會通過該拓撲結構進行全面處理；如果發現 一個元組還未處理，它會自動從噴嘴處重放。Storm 還實現了任務級的故障檢測，在一個任務發生故障時，消息會自動重新分配以快速重新開始處理。 Storm 包含比 Hadoop 更智能的處理管理，流程會由監管員來進行管理，以確保資源得到充分使用。
下圖是Storm的數據交互圖。可以看出兩個模塊Nimbus和Supervisor之間沒有直接交互。狀態都是保存在Zookeeper上。Worker之間通過ZeroMQ（新的消息機制使用netty代替ZeroMQ）傳送數據。
Storm 使用 ZeroMQ 傳送消息，這就消除了中間的排隊過程，使得消息能夠直接在任務自身之間流動。在消息的背后，是一種用于序列化和反序列化 Storm 的原語類型的自動化且高效的機制。
Storm的應用：
Storm被廣泛應用于實時分析，在線機器學習，持續計算、分布式遠程調用等領域。如果，業務場景中需要低延遲的響應，希望在秒級或者毫秒級完成分析、并得到響應，而且希望能夠隨著數據量的增大而拓展。那就可以考慮使用Storm。Storm的適用場景：
來看一些實際的應用:
參考資料：