在過去10 年中，隨着互聯網應用的高速發展，企業積累的數據量越來越大，越來越多。隨着Google MapReduce、Hadoop 等相關技術的出現，處理大規模數據變得簡單起來，但是這些數據處理技術都不是實時的系統，它們的設計目標也不是實時計算。畢竟實時的計算系統和基於批處理模型的系統（如Hadoop）有着本質的區別。
但是隨着大數據業務的快速增長，針對大規模數據處理的實時計算變成了一種業務上的需求，缺少“實時的Hadoop 系統”已經成為整個大數據生態系統中的一個巨大缺失。Storm 正是在這樣的需求背景下出現的，Storm 很好地滿足了這一需求。
在Storm 出現之前，對於需要實現計算的任務，開發者需要手動維護一個消息隊列和消息處理者所組成的實時處理網絡，消息處理者從消息隊列中取出消息進行處理，然后更新數據庫，發送消息給其他隊列。所有這些操作都需要開發者自己實現。這種編程實現的模式存在以下缺陷。
集群環境配置下的Storm存在兩類節點:主控節點和工作節點。此外，為了實現集群的狀態維護和配置管理，還需要一類特殊的節點:協調節點。整體架構如下圖:
一、組成原理:
1、
主控節點，即運行nimbus守護進程的節點。 nimbus負責在集群分發的代碼，將任務分配給其他機器，並負責故障監測。
2、
工作節點，即運行supervisor守護進程的節點。
supervisor監聽分配所在機器，根據nimbus的委派，在必要時啟動和關閉工作進程。(工作節點是實時數據處理作業運行的節點)
其中，計算在節點上的物理單元是worker,也即工作進程；計算的邏輯單元是executor,也即計算線程。(有點像spark哦) 然而計算的作業邏輯單元是topology,也稱拓撲；計算的任務邏輯單元是task(還是有點像spark哦).
每個worker執行特定topology的executor子集，每個executor執行一個或多個task。
一個topology主要有兩類組件(component):spout和bolt.分別是流失數據在topology中的起始單元和處理單元。
3、
協調節點，即運行Zookeeper服務端進程的節點。
Zookeeper是一種分布式的狀態協同服務，通過放松一致性的要求，為應用建立高層的協同原語(阻塞和更強一致性的要求)，當前分布式系統中，廣泛應用於狀態監控和配置管理。
二、Storm主要的編程概念:
spout、
blot和
topology。
1、
spout 是流式處理的源頭，是一個計算的起始單元，它封裝數據源中的數據為storm可以識別的數據項。 spout可以從消息中間件中(如kafka、kestrel等)中讀取數據產生流式元祖數據，也可以從其他接口如Twitter streaming API直接獲取流式數據。
2、
bolt 是處理過程單元，從輸入流中獲取一定數量的數據項處理后，將結果作為輸出流發送。流式數據處理的業務邏輯，大部分是在bolt中實現的，如各類函數、過濾器、連接操作、聚集操作、數據庫操作等。
3、
topology是由spout和bolt為點組成的網絡，網絡中的邊表示一個bolt訂閱了某個或某個其他bolt或spout的輸出流。topology可以是任意復雜多階段流計算的網絡，在Storm急群眾提交后立即運行。
storm拓撲topology:
三、流處理與批處理
1、系統的輸入包括兩類數據：
實時的流式數據和
靜態的離線數據。其中，流式數據是前端設備實時發送的識別數據、GPS數據等，是通過消息中間件實現的事件觸發，推送至系統的。離線數據是應用需要用到的基礎數據（提前梳理好的）等關系數據庫中的離線數據，是通過數據庫讀取接口獲取而批量處理的系統。
2、
系統的輸出也包括流式數據和離線數據。其中，流式數據是寫入消息中間件的指定數據隊列緩存，可以被異步推送至其他業務系統。離線數據是計算結果，直接通過接口寫入業務系統的關系型數據庫。
3、業務的
計算結果輸出方式是通過兩個條件決定的。一、
結果產生的頻率：若計算結果產生的頻率可能會較高，則結果以流式數據的形式寫入消息中間件。（比如要實時監控該客戶所擁有的標簽，也就是說要以極高的速度被返回，這類結果以流式數據形式被寫入消息中間件。） 這是因為數據庫的吞吐量很可能無法適應告訴數據的存取需求。 二、
結果需要寫入的數據庫表規模：若需要插入結果的數據表已經很龐大，則結果以流式數據的形式寫入消息中間件，待應用層程序實現相關隊列數據的定期或定量的批量數據庫轉儲。（比如寬表異常龐大，每次查詢數據庫就會有很高的延遲，那么就將結果信息暫時存入中間件層，晚些時候再定時或定量的進行批量數據庫轉儲） 。這是因為大數據表的讀取和寫入操作對毫秒級別的相應時間仍是無能為力。 若以上兩個條件均無要求，結果可以直接寫入數據庫的相應表中。