什么是Storm，它可以用來做什么？
最近團隊中有分析的場景，用到了JStorm來做數據的實時分析，于是花時間對于一些概念做了了解。
什么是Storm?
這個的話出來應該有幾年時間了，阿里巴巴也重寫了一套JStorm，核心的類名都是服用的Storm的，他是一套實時數據處理系統，容錯行好，然后足夠穩定，目前很多數據實時分析的場景，選擇Storm的越來越多了。
核心概念介紹
Nimbus：負責在集群里面發送代碼，分配工作給機器，并且監控狀態。全局只有一個。相當于master的角色。
Supervisor：監聽分配給它那臺機器的工作，根據需要啟動/關閉工作進程Worker。每一個要運行Storm的機器上都要部署一個，并且，按照機器的配置設定上面分配的槽位數。
zookeeper：Storm重點依賴的外部資源。Nimbus和Supervisor甚至實際運行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根據Zookeerper上的心跳和任務運行狀況，進行調度和任務分配的。兩者之間的調度器。
Spout：在一個topology中產生源數據流的組件。通常情況下spout會從外部數據源中讀取數據，然后轉換為topology內部的源數 據。Spout是一個主動的角色，其接口中有個nextTuple()函數，storm框架會不停地調用此函數，用戶只要在其中生成源數據即可。
Bolt：在一個topology中接受數據然后執行處理的組件。Bolt可以執行過濾、函數操作、合并、寫數據庫等任何操作。Bolt是一個被動 的角色，其接口中有個execute(Tuple input)函數,在接受到消息后會調用此函數，用戶可以在其中執行自己想要的操作。
Topology：storm中運行的一個實時應用程序，因為各個組件間的消息流動形成邏輯上的一個拓撲結構。
Worker：具體處理組建邏輯的進程，
Task：不再與物理進程對應，是處理任務的線程，
Stream：源源不斷傳遞的tuple就組成了stream。
Tuple:一次消息傳遞的基本單元。本來應該是一個key-value的map，但是由于各個組件間傳遞的tuple的字段名稱已經事先定義好，所以tuple中只要按序填入各個value就行了，所以就是一個value list.
整體物理布局
放一張Nimbus和Supervisior的關系圖
數據處理的流程
Topology是一個完成的數據處理流程，在Nimbus提交jar，然后Nimbus分發到Supervisior中，Sport負責數據流的 讀入，是入口，然后Bolt是處理數據加工數據的節點，中間數據被封裝在Tuple中，然后Bolt節點可以產生新的Tuple。總體流程圖如下：
Storm如何保證消息被最終處理
總體的流程介紹，首先Spout發完tuple后發送一條Ack消息給Acker線程，告訴Acker自己發送了哪些tuple需要ack，每一個 Bolt 的 task 在執行完對tuple的處理之后，需要手動的ack一下，ack的時候發送一條Ack消息給Acker線程，告知自己要ack的tuple和需要下面的節 點ack的tuple，當Acker收到所有的ack的時候就向Spout發送一條ack消息，通知這棵樹上的tuple被完整的處理了。
每當一個Spout發送出一個tuple，就會在拓撲中產生了一棵由tuple構成的樹，Jstorm中為每棵樹設置了一個rootID來唯一的標示這棵樹。
Storm如何存儲數據
嚴格來講，Storm中設計的組建，沒有專門存儲數據的，一般情況下，會借助第三方的存儲，例如mysql、Nosql 等，Bolt的節點，可以用于存儲計算的中間結果或者最終結果。
從這里看，Storm在取舍上拿捏的恰到好處，發揮里實時處理數據的核心場景。
Spout和Bolt為啥需要實現序列化
這兩個核心的接口，都實現了序列化，在開發web類系統的時候，一般接口或者操作類，是沒有必要實現序列化接口的，這里為啥需要呢。
深入理解一些Storm的機制，一個topology程序提交到集群，是先提交到Nimbus的，然后由其進行分發，分發是跨進程的，到了另外一個進程中，是需要反序列化出來這個處理類的。
Storm中的grouping機制有那些
一個 Bolt 可以設置為多個 Task 并發執行數據處理任務，訂閱了一個 Spout 的 Stream，那么應該把 Spout 的數據發送給哪一個具體的Task執行，這個是由grouping的方式決定的。
1、隨機分組，偽隨機，按照一定的邏輯均勻的分發
2、特定字段分組
3、真正的隨機分組
4、廣播，每個都發一遍
5、直接制定那個任務接收
事務拓撲是怎么回事
事務拓撲，保證流入拓撲的數據能夠被完整的處理且處理一次；
Acker拓撲，保證流入拓撲的數據能夠被完整的處理，但不保證不重復；
普通拓撲，不保證流入拓撲的數據能夠被完整的處理；
如何測試這種編程模型的系統呢
簡單想了一些測試的思路，這種實時處理，數據是流動的，測試難度比較大
1、驗證數據，截取特定時間點的分析結果數據快照，然后利用這些時間在離線的分析集群里面對照寫分析邏輯，看結果是否一致；
2、驗證數據分析處理邏輯，中間的Bolt階段，涉及到數據的加工分析以及過濾，可以mock數據輸入，驗證計算邏輯是否準確；
3、測試環境下，模擬有可能異常的業務數據，流入系統，看系統的容錯機制如何；
Spout如何獲取數據
1、直接鏈接，Spout作為數據輸入的源頭，啟動線程直接鏈接對應的數據源，拉取特定條件的數據；
2、通過隊列過度，不是直接的方式，通過消息隊列來進行過度；
3、外部系統通知，消息系統通知到Spout，然后轉換為Tuple進行傳輸；
實時計算業務場景舉例
1、日志分析
例如應用系統產生大量的業務日志，這些例如網關系統的API調用情況日志，這些日志，不太適合馬上存入數據庫，需要進行加工，日志文件的量又非常大，所以沒法直接統計，這時候可以通過Storm來進行分析。
2、大數據實時統計
互聯網的數據量是海量的時候，沒有辦法在數據庫層面直接SQL來進行統計，需要對于產生的數據，進行二次加工，然后產出結果，正好把實時變化的數據流到storm中處理一遍。
3、管道傳輸
例如有數據需要從A系統流道B系統，這時候需要中間處理一下，場景是不是很切和。
參考文章：
http://storm.apache.org/documentation/Concepts.html
http://tech.uc.cn/?p=2159
http://xumingming.sinaapp.com/category/storm/
http://www.searchtb.com/2012/09/introduction-to-storm.html
End.