Storm（一）分佈式實時大數據處理框架

Storm介紹

Storm是Twitter開源的分佈式實時大數據處理框架，最早開源於github，從0.9.1版本之後，歸於Apache社區，被業界稱爲實時版Hadoop。隨着越來越多的場景對Hadoop的MapReduce高延遲無法容忍，比如網站統計、推薦系統、預警系統、金融系統(高頻交易、股票)等等，大數據實時處理解決方案（流計算）的應用日趨廣泛，目前已是分佈式技術領域最新爆發點，而Storm更是流計算技術中的佼佼者和主流。

爲什麼用storm？

Apache Storm是一個免費的開源分佈式實時計算系統。Apache Storm使得可靠地處理無界數據流變得很容易，就像Hadoop處理批處理一樣，它可以進行實時處理。Apache Storm很簡單，可以與任何編程語言一起使用，而且使用起來很有趣!
Apache Storm有很多用例:實時分析、在線機器學習、連續計算、分佈式RPC、ETL等等。Apache Storm速度很快:一個基準測試將它的速度控制在每秒處理每個節點超過100萬個元組。它是可擴展的，容錯，保證喲。

Storm的核心組件

• Nimbus：即Storm的Master，負責資源分配和任務調度。一個Storm集羣只有一個Nimbus。
• Supervisor：即Storm的Slave，負責接收Nimbus分配的任務，管理所有Worker，一個Supervisor節點中包含多個Worker進程。
• Worker：工作進程，每個工作進程中都有多個Task。
• Task：任務，在 Storm 集羣中每個 Spout 和 Bolt 都由若干個任務（tasks）來執行。每個任務都與一個執行線程相對應。
• Topology：計算拓撲，Storm 的拓撲是對實時計算應用邏輯的封裝，它的作用與 MapReduce 的任務（Job）很相似，區別在於MapReduce 的一個 Job在得到結果之後總會結束，而拓撲會一直在集羣中運行，直到你手動去終止它。拓撲還可以理解成由一系列通過數據流（StreamGrouping）相互關聯的 Spout 和 Bolt 組成的的拓撲結構。
• Stream：數據流（Streams）是 Storm中最核心的抽象概念。一個數據流指的是在分佈式環境中並行創建、處理的一組元組（tuple）的無界序列。數據流可以由一種能夠表述數據流中元組的域（fields）的模式來定義。
• Spout：數據源（Spout）是拓撲中數據流的來源。一般 Spout會從一個外部的數據源讀取元組然後將他們發送到拓撲中。根據需求的不同，Spout既可以定義爲可靠的數據源，也可以定義爲不可靠的數據源。一個可靠的Spout能夠在它發送的元組處理失敗時重新發送該元組，以確保所有的元組都能得到正確的處理；相對應的，不可靠的 Spout就不會在元組發送之後對元組進行任何其他的處理。一個 Spout可以發送多個數據流。
• Bolt：拓撲中所有的數據處理均是由 Bolt完成的。通過數據過濾（filtering）、函數處理（functions）、聚合（aggregations）、聯結（joins）、數據庫交互等功能，Bolt幾乎能夠完成任何一種數據處理需求。一個 Bolt 可以實現簡單的數據流轉換，而更復雜的數據流變換通常需要使用多個 Bolt並通過多個步驟完成。 Stream grouping：爲拓撲中的每個 Bolt的確定輸入數據流是定義一個拓撲的重要環節。數據流分組定義了在 Bolt 的不同任務（tasks）中劃分數據流的方式。在 Storm中有八種內置的數據流分組方式。
• Reliability：可靠性。Storm 可以通過拓撲來確保每個發送的元組都能得到正確處理。通過跟蹤由 Spout發出的每個元組構成的元組樹可以確定元組是否已經完成處理。每個拓撲都有一個“消息延時”參數，如果 Storm在延時時間內沒有檢測到元組是否處理完成，就會將該元組標記爲處理失敗，並會在稍後重新發送該元組。

storm特徵

• 官網 http://storm.apache.org/
• Storm是個實時的、分佈式以及具備高容錯的計算系統
  • Storm進程常駐內存
  • Storm數據不經過磁盤，在內存中處理
    
• 架構
  • Nimbus
  • Supervisor
  • Worker
• 編程模型
  • DAG （Topology）
  • Spout
  • Bolt
• 數據傳輸
  • ZMQ（twitter早期產品）：ZeroMQ 開源的消息傳遞框架，並不是一個MessageQueue
  • Netty：Netty是基於NIO的網絡框架，更加高效。（之所以Storm 0.9版本之後使用Netty，是因爲ZMQ的license和Storm的license不兼容。）
• 高可靠性
  - 異常處理
  - 消息可靠性保障機制(ACK)
• 可維護性
  • StormUI 圖形化監控接口
• 流式處理
  • （異步 與 同步）客戶端提交數據進行結算，並不會等待數據計算結果
  • 逐條處理:例：ETL（數據清洗）extracted transform load
  • 統計分析:例：
    • 計算PV、UV、訪問熱點 以及 某些數據的聚合、加和、平均等.
    • 客戶端提交數據之後，計算完成結果存儲到Redis、HBase、MySQL或者其他MQ當中，客戶端並不關心最終結果是多少。
      
• 實時請求
  • 實時請求應答服務（同步）
  • Drpc
  • 實時請求處理
    例：圖片特徵提取
    

Storm 架構設計與Hadoop架構對比

storm與MapReduce區別

• Storm：進程、線程常駐內存運行，數據不進入磁盤，數據通過網絡傳遞。
• MapReduce：爲TB、PB級別數據設計的批處理計算框架。
  

storm與Spark Streaming區別

• Storm：純流式處理

  • 專門爲流式處理設計
  • 數據傳輸模式更爲簡單，很多地方也更爲高效
  • 並不是不能做批處理，它也可以來做微批處理，來提高吞

• Spark Streaming：微批處理

  • 將RDD做的很小來用小的批處理來接近流式處理
  • 基於內存和DAG可以把處理任務做的很快

Storm計算模式

Storm程序再Storm集羣中運行的示例圖如下:

Topology - DAG有向無環圖的實現

• 對於Storm實時計算邏輯的封裝
• 即，由一系列通過數據流相互關聯的Spout、Bolt所組成的拓撲結構
• 生命週期：此拓撲只要啓動就會一直在集羣中運行，直到手動將其kill，否則不會終止（區別於MapReduce當中的Job，MR當中的Job在計算執行完成就會終止）

具體流程是怎麼走，可以通過查看下面這張圖來進行了解。
示例圖:

圖片有三種模式，解釋如下:
第一種比較簡單，就是由一個Spout獲取數據，然後交給一個Bolt進行處理;
第二種稍微複雜點，由一個Spout獲取數據，然後交給一個Bolt進行處理一部分，然後在交給下一個Bolt進行處理其他部分。
第三種則比較複雜，一個Spout可以同時發送數據到多個Bolt，而一個Bolt也可以接受多個Spout或多個Bolt，最終形成多個數據流。但是這種數據流必須是有方向的，有起點和終點，不然會造成死循環，數據永遠也處理不完。就是Spout發給Bolt1，Bolt1發給Bolt2，Bolt2又發給了Bolt1,最終形成了一個環狀。

• Tuple – 元組

  • Stream中最小數據組成單元

• Stream – 數據流

  • 從Spout中源源不斷傳遞數據給Bolt、以及上一個Bolt傳遞數據給下一個Bolt，所形成的這些數據通道即叫做Stream
  • Stream聲明時需給其指定一個Id（默認爲Default）
  • 實際開發場景中，多使用單一數據流，此時不需要單獨指定StreamId
    

• Spout – 數據源

  • 拓撲中數據流的來源。一般會從指定外部的數據源讀取元組（Tuple）發送到拓撲（Topology）中
  • 一個Spout可以發送多個數據流（Stream）
  • 可先通過OutputFieldsDeclarer中的declare方法聲明定義的不同數據流，發送數據時通過SpoutOutputCollector中的emit方法指定數據流Id（streamId）參數將數據發送出去
  • Spout中最核心的方法是nextTuple，該方法會被Storm線程不斷調用、主動從數據源拉取數據，再通過emit方法將數據生成元組（Tuple）發送給之後的Bolt計算

• Bolt – 數據流處理組件

  • 拓撲中數據處理均有Bolt完成。對於簡單的任務或者數據流轉換，單個Bolt可以簡單實現；更加複雜場景往往需要多個Bolt分多個步驟完成
  • 一個Bolt可以發送多個數據流（Stream）
  • 可先通過OutputFieldsDeclarer中的declare方法聲明定義的不同數據流，發送數據時通過SpoutOutputCollector中的emit方法指定數據流Id（streamId）參數將數據發送出去
  • Bolt中最核心的方法是execute方法，該方法負責接收到一個元組（Tuple）數據、真正實現核心的業務邏輯

• Stream Grouping – 數據流分組（即數據分發策略）
  

Storm 任務提交流程

Storm 本地目錄樹

Storm Zookeeper目錄樹