推ter Storm 實時數據處理框架分析總結
Storm是推ter開源的一個類似于Hadoop的實時數據處理框架（原來是由BackType開發，后BackType被推ter收購，將Storm作為推ter的實時數據分析）。實時數據處理的應用場景很廣泛，如上篇文章介紹S4時所說的個性化搜索廣告的會話特征分析。而Yahoo當初創建S4項目的直接業務需求就是為了在搜索引擎的‘cost-per-click’廣告中，能根據當前情景上下文（用戶偏好，地理位置，已發生的查詢和點擊等）來估計用戶點擊的可能性并實時做出調整。
這種高可拓展性，能處理高頻數據和大規模數據的實時流計算解決方案將被應用于實時搜索，高頻交易和社交網絡上。而流計算并不是最近的熱點，金融機構的交易系統正是一個典型的流計算處理系統，它對系統的實時性和一致性有很高要求。
推ter列舉了storm的三大作用領域：
1） 信息流處理（Stream Processing）
Storm可以用來實時處理新數據和更新數據庫，兼具容錯性和可擴展性。
2） 連續計算（Continuous Computation）
Storm可以進行連續查詢并把結果即時反饋給客戶，比如將推ter上的熱門話題發送到客戶端。
3） 分布式遠程過程調用（Distributed RPC）
Storm可以用來并行處理密集查詢，Storm的拓撲結構（后文會介紹）是一個等待調用信息的分布函數，當它收到一條調用信息后，會對查
詢進行計算，并返回查詢結果。
Storm的設計思想
在Storm中也有對于流stream的抽象，流是一個不間斷的無界的連續tuple，注意Storm在建模事件流時，把流中的事件抽象為tuple即元組，后面會解釋storm中如何使用tuple。
Storm認為每個stream都有一個stream源，也就是原始元組的源頭，所以它將這個源頭抽象為spout，spout可能是連接推ter api并不斷發出tweets，也可能是從某個隊列中不斷讀取隊列元素并裝配為tuple發射。
有了源頭即spout也就是有了stream，那么該如何處理stream內的tuple呢，同樣的思想推ter將流的中間狀態轉換抽象為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集群內以快速回復任何失敗的一方。
網絡上 有一篇文章說道Storm這種topology結構的使用妙處，即可以進行stream grouping 從而實現多種處理需求，原文地址：http://blog.sina.com.cn/s/blog_406d9bb00100ui5p.html 下面是stream grouping的種類。
| stream grouping分類 1. Shuffle Grouping: 隨機分組， 隨機派發stream里面的tuple， 保證每個bolt接收到的tuple數目相同. |