storn是實時流式計算，Hadoop是做離線的數據分析
Storm簡介
Storm是 Twitter開源的一個分佈式的實時計算系統，可以簡單、可靠的處理大量的數據流；
用於數據的實時分析，持續計算，分佈式RPC等等；
Storm支持水平擴展，具有高容錯性，保證每個消息都會得到處理，而且處理速度很快（在一個小集羣中，每個結點每秒可以處理數以百萬計的消息）。Storm的部署和運維都很便捷，而且更爲重要的是可以使用任意編程詢言來開發應用。
Storm實時計算應用場景
1.實時推薦系統；2.實時告警系統；3.股票系統；4.實時分析，在線機器學習，持續計算，分佈式RPC，ETL等等
Storm實時計算系統特點
低延遲：都說了是實時計算系統了，延遲是一定要低的。
高性能：可以使用幾臺普通的服務器建立環境，結餘成本
分佈式：Stom非常適合於分佈式場景，大數據的實時計算
可擴展：伴隨着業務的發展，我們的數據量、計算量可能會越來越大，所以希望這個系統是可擴展的。
容錯：這是分佈式系統中通用問題，一個節點掛了不能影響我的應用，Storm可以輕鬆做到在節點掛了的時候實現任務轉移
可靠性：可靠的消息處理。Storm保證每個消息至少能得到一次完整處理。任務失敗時，它會負責從消息源重試消息。
快速：系統的設計保證了消息能得到快速的處理，使用 ZeroMQ作爲其底層消息隊列。
本地模式：Storm有一個“本地模式”，可以在處理過程中完全模擬stom集羣。這讓你可以快速進行開發和單元測試
Storm體系結構
Nimbus主節點：
主節點通常運行一個後臺程序—Nimbus，用於響應分佈在集羣中的節點，分配任務和監測故障。這個很類似亍 Hadoop中的 Job Tracker.
Supervisor工作節點：
工作節點同樣會運行一個後臺程序—supervisor，用於收聽工作指派並基於要求運行工作進程。每個工作節點都是 topology中一個子集的實現。而Nimbus和 Supervisor之間的協調則通過 Zookeeper系統戒者集羣。
Zookeeper
Zookeeper是完成 Supervisor和 Nimbus之間協調的服務。而應用程序實現實時的邏輯則被封裝到stom中的“topology”.topology則是一組由 Spouts（數據源）和Bots（數據操作）通過 Stream Groupings運行連接的圖。下面對出現的術語進行更深刻的解析。
Topology（拓撲）
storm中運行的一個實時應用程序，因爲各個組件間的消息流動形成邏輯上的一個拓撲結構。一個 topology是 spouts和bos組成的圖，通過 stream groupings將圖中的 spouts和bots連接起來
Storm demo
首先編寫我們的數據源類：Spout。可以使用倆種方式：
繼承 BaseRichSpout類
實現 IRichSpout接口
重點需要幾個方法進行重寫或實現：open、nextTuple、declareOutputFields
繼續編寫我們的數據處理類：Bolt。可以使用倆種方式：
繼承 BaseBasicBolt類
實現 IRichBolt接口
重點需要幾個方法進行重寫或實現：execute、declareOutputFields
最後我們編寫主函數（Topology）去進行提交一個任務。
在使用 Topology的時候，Storm框架爲我們提供了倆種模式：本地模式和集羣模式
本地模式：（無需stom集羣，直接在jaa中即可運行，一般用於測試和開發階段）執行運行main函數即可。
集羣模式：（需要Stom集羣，把實現的java程序打包，然後 Topology進行提交）需要把應用打成jar，使用stom命令把 Topology提交到集羣中去
提交topology命令：storm jar storm01.jar bhz.topology.PWTopology1
查看任務命令：storm list
Storm APl
Topology（拓撲）
Stream grouping（流分組、數據的分發方式）
Spout（噴口、消息源）
Bolt（螺栓、處理器）
Worker（工作進程）
Executor（執行器、Task的線程）
Task（具體的執行任務）
Configuration（配置）
Storm拓撲配置
工作進程、並行度、任務數設置：
我們首先設置了2個工作進程（也就是2個jvm）
然後我們設置了 spout的並行度爲2（產生2個執行器和2個任務）
第一個bolt的並行度爲2並且指定任務數爲4（產生2個執行器和4個任務）
第二個bolt的並行度爲6（產生6個執行器和6個任務）
因此：該拓撲程序共有倆個工作進程（worker），2+2+6=10個執行器
（executor），2+4+6=12個任務（task）。每個工作進程可以領取到12/2=6個任務。默認情況下一個執行器執行一個任務，但如果指定了任務的數目。則任務會平均分配到執行器中。
什麼是Storm拓撲？
我們在使用storm進行流式計算的時候，都必須要在Main函數裏面建立所謂的“拓撲”，拓撲是什麼？
拓撲是一個有向圖的計算。（也就是說在計算的過程中是有流向的去處理業務邏輯，節點之間的連接顯示數據該如何進入下一個節點，他們是進行連接傳遞的）
拓撲運行很簡單，只需要使用 storm命令，把一個jar提交給 nimbus節點，numbus就會把任務分配給具體的子節點（supervisor）去工作。
我們創建拓撲非常簡單：
第一，構建 TopologyBuilder對象
第二，設置 Spout（噴口）數據源對象（可以設置多個）
第三，設置Bolt（螺栓）數據處理對象（可以設置多個）
第四，構建 Config對象
第五，提交拓撲
Storm流分組
Stream Grouping：爲每個bolt指定應該接受哪個流作爲輸入，流分組定義瞭如何在bolt的任務直接進行分發。
Shuffle Grouping隨機分組：保證每個bot接收到的 tuple數目相同Fields Grouping按字段分組：比如按 userid來分組，具有同樣 userid的 tuple會被分到相同的Bots，而不同的 userid則會被分配到不同的Bolts。All Grouping廣播發送：對於每一個 tuple，所有的Bots都會收到。Global Grouping：全局分組：這個 tuple被分配到stom中的一個bolt的其中一個task。再具體一點就是分配給id值最低的那個task。Non Grouping無分組：假設你不關心流式如何分組的煤科院使用這種方式，目前這種分組和隨機分組是一樣的效果，不同的是Stom會把這個Bolt放到Bolt的訂閱者的同一個線程中執行。
Direct Grouping直接分組：這種分組意味着消息的發送者指定由消息接收者的哪個task處理這個消息。只有被聲明爲 Direct stream的消息流可以聲明這種分組方法而且這種消息tupe必須使用 emitDirect方法來發射。消息處理者可以通過TopologyContext來獲取處理它的消息的 taskid（Outputcollector.emit，方法也會返回 taskid）
本地分組：如果目標bo在同一工作進程存在一個或多個任務，元祖會隨機分配給執行任務，否則該分組方式與隨機分組方式是一樣的。
Storm Spout的可靠性
Spout是 Storm數據流的入口，在設計拓撲時，一件很重要的事情就是需要考慮消息的可靠性，如果消息不能被處理而丟失是很嚴重的問題。
我們繼續作實驗，以一個傳遞消息並且實時處理的例子，來說明這個問題。
新建 maven項目（storm03）
通過示例我們知道，如果在第一個bolt處理的時候出現異常，我們可以讓整個數據進行重發，但是如果在第二個bolt處理的時候出現了異常，那麼我們也會讓對應的整個spout裏的數據重發，這樣就會出現事務的問題，我們就需要進行判斷或者是進行記錄
如果是數據入庫的話，可以與原ID進行比對。
將一批數據定義唯一的ID入庫（冪等性判斷事物）
如果是事務的話在編寫代碼時，儘量就不要進行拆分 tuple
或者使用 storm的 Trident框架
下圖是 spout處理可靠性的示意圖：當 spout發送一個消息時，分配給倆個bolt分別處理，那麼在最後一個bolt接受的時候會做異或運算
RPC介紹
調用客戶端句柄；執行傳送參數
調用本地系統內核發送網絡
消息消息傳送到遠程主機
服務器句柄得到消息並取得參數
執行遠程過程
執行的過程將結果返回服務器句柄
服務器句柄返回結果，調用遠程系統內核
消息傳回本地主機
客戶句柄由內核接收消息
客戶接收句柄返回的數據
Storm DRPC
分佈式RPC（distributed RPC，DRPC）
Storm裏面引入DRPC主要是利用 storm的實時計算能力來並行化CPU密集型（CPU intensive）的計算任務。DRPC的 storm topology以函數的參數流作爲輸入，而把這些函數調用的返回值作爲 topology的輸出流。
DRPc其實不能算是 storm本身的一個特性，它是通過組合stom的原語stream、spout、bolt、topology而成的一種模式（pattern）。本來應該把DRPC單獨打成一個包的，但是DRPC實在是太有用了，所以我們把它和storm捆綁在一起。
Distributed RPC是通過一個”DRPC Server”來實現
DRPC Server的整體工作過程如下：
1接收一個RPC請求
2）發送請求到 storm topology
3）從 storm topology接收結果。
4）把結果發回給等待的客戶端。
Storm Trident介紹
Trident是在stom基礎上，一個以實時計算爲目標的高度抽象。它在提供處理大吞吐量數據能力（每秒百萬次消息）的同時，也提供了低延時分佈式查詢和有狀態流式處理的能力。如果你對Pig和 Cascading這種高級批處理工具很瞭解的話，那麼應該很容易理解 Trident，因爲他們之間很多的概念和思想都是類似的。Trident提供了 joins，aggregations，grouping，functions，以及 filters等能力。除此之外，Trident還提供了一些與門的原語，從而在基於數據庫戒者其他存儲的前提下來應付有狀態的遞增式處理。Trident也提供致性（consistent）、有且僅有一次（exactly-once）等語義，這使得我們在使用 trident toplogy時變得容易。
我們首先熟悉下 Trident的概念：
"Stream"是 Trident中的核心數據模型，它被當做一系列的 batch來處理。在Storm集羣的節點之間，一個 stream被劃分成很多 partition（分區），對流的操作（operation）是在每個 partition上並行執行的。
state Query、partition Persist.、poe（filter、partitionAggregate、
對每個 partition的局部操作包括：function
新建 maven工程（storm05）
Storm Trident Function
Storm Trident Filter
Storm Trident projection
Storm Trident operation
Storm Trident aggregate
Batch和 Spout與 Transactiona
Trident提供了下面的語義來實現有且有一次被處理的目標
1、Tuples是被分成小的集合（一組 tuple被稱爲一個 batch）被批量處理的。
2、每一批 tuples被給定一個唯1D作爲事務ID（txid），當這一個 batch被重發時，tid不變。
3、batch和 batch之間的狀態更新時嚴格順序的。比如說 batch3的狀態的更新必須要等到 batch2的狀態更新成功之後纔可以進行。
有了這些定義，你的狀態實現可以檢測到當前 batch是否以前處理過，並根據不同的情況進行不同的處理，這個處理取決於你的輸入 spout。有三種不同類型的可以容錯的 sqout：
1、non-transactional（無事務支持的 spout）
2、transactional（事務支持的 spout）
3、opaque transactional（不透明事務支持的 spout）
transactional spout實現
1、重發操作：
2、重發結果：
opaque transactional spout實現
實現ITridentspout接口
最通用的AP可以支持 transactional or opaque transactional語義
實現IBatchSpou接口：
一個 non-transactional spout
實現IPArtitioned Tridentspout接口：
一個 transactional spout
實現IOpaquePartitioned Tridentspout接口：
一個opaque transactional spout