大數據處理框架之Strom：認識storm

Storm是分佈式實時計算系統，用於數據的實時分析、持續計算，分佈式RPC等。

（備註：5種常見的大數據處理框架：· 僅批處理框架：Apache Hadoop；· 僅流處理框架：Apache Storm 和 Apache Samza；· 混合框架：Apache Spark 和 Apache Flink）

水龍頭出來的是水滴 不是水流柱說明單個數據量小，可是接二連三的，後面水滴加閃電 表示處理迅速。

 

1、storm架構結構

2、Strom和Hadoop 分類對比

二者應用場景不一樣：
Storm：進程、線程常駐內存運行，數據不進入磁盤，數據經過網絡傳遞，所以處理的單個數據大小不能過大。
MapReduce：爲TB、PB級別數據設計的批處理計算框架。

3、Storm和Spark Streaming

Storm：純流式處理，專門爲流式處理設計，數據傳輸模式更爲簡單，不少地方也更爲高效，並非不能作批處理，它也能夠來作微批處理，來提升吞吐;
Spark Streaming：微批處理，將RDD作的很小來用小的批處理來接近流式處理，基於內存和DAG能夠把處理任務作的很快;

storm是一個獨立的框架，sparkstreaming是spark家族中一員，在大多數大數據應用場景下 使用sparkstreaming用的多一些；在獨立的應用場景下 使用strom便可

 

4、Storm計算模型

系統角色組件

　　Nimbus：即Storm的Master，負責資源分配和任務調度。一個Storm集羣只有一個Nimbus。
　　Supervisor：即Storm的Slave，負責接收Nimbus分配的任務，管理全部Worker，一個Supervisor節點中包含多個Worker進程。
　　Worker：工做進程，每一個工做進程中都有多個Task。
　　Task：任務，在 Storm 集羣中每一個 Spout 和 Bolt 都由若干個任務（tasks）來執行。每一個任務都與一個執行線程相對應。

 

應用名稱組件

　　Topology：計算拓撲，有向的工做流程圖（DAG），Storm 的拓撲是對實時計算應用邏輯的封裝，它的做用與 MapReduce 的任務（Job）很類似，區別在於 MapReduce 的一個 Job 在獲得結果以後總會結束，而拓撲會一直在集羣中運行，直到你手動去終止它。拓撲還能夠理解成由一系列經過數據流（Stream Grouping）相互關聯的 Spout 和 Bolt 組成的的拓撲結構。

組件接口

(1)Spout-數據源：

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

(2)Bolt-數據流處理組件：

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

 (3)tuple-元組：

storm使用tuple來做爲它的數據模型。每一個tuple是一堆值，每一個值有一個名字，而且每一個值能夠是任何類型， 在個人理解裏面一個tuple能夠看做一個沒有方法的java對象。整體來看，storm支持全部的基本類型、字符串以及字節數組做爲tuple的值類 型。你也可使用你本身定義的類型來做爲值類型， 只要你實現對應的序列化器(serializer)。

Tuple原本應該是一個Key-Value的Map，因爲各個組件間傳遞的tuple的字段名稱已經事先定義好了，因此Tuple只須要按序填入各個Value，因此就是一個Value List。

一個Tuple表明數據流中的一個基本的處理單元，例如一條cookie日誌，它能夠包含多個Field，每一個Field表示一個屬性。

 

(4)Stream：

數據流（Streams）是 Storm 中最核心的抽象概念。一個數據流指的是在分佈式環境中並行建立、處理的一組元組（tuple）的無界序列。數據流能夠由一種可以表述數據流中元組的域（fields）的模式來定義。一個沒有邊界的、源源不斷的、連續的Tuple序列就組成了Stream。

 

(5)Stream grouping-數據分發策略：

爲拓撲中的每一個 Bolt 的肯定輸入數據流是定義一個拓撲的重要環節。數據流分組定義了在 Bolt 的不一樣任務（tasks）中劃分數據流的方式。在 Storm 中有八種內置的數據流分組方式。

(5.1)Shuffle Grouping 
隨機分組，隨機派發stream裏面的tuple，保證每一個bolt task接收到的tuple數目大體相同。
輪詢，平均分配 
(5.2)Fields Grouping
按字段分組，好比，按"user-id"這個字段來分組，那麼具備一樣"user-id"的 tuple 會被分到相同的Bolt裏的一個task， 而不一樣的"user-id"則可能會被分配到不一樣的task。 
(5.3)All Grouping
廣播發送，對於每個tuple，全部的bolts都會收到 
(5.4)Global Grouping
全局分組，把tuple分配給task id最低的task 。
(5.5)None Grouping
不分組，這個分組的意思是說stream不關心到底怎樣分組。目前這種分組和Shuffle grouping是同樣的效果。 有一點不一樣的是storm會把使用none grouping的這個bolt放到這個bolt的訂閱者同一個線程裏面去執行（將來Storm若是可能的話會這樣設計）。 
(5.6)Direct Grouping
指向型分組， 這是一種比較特別的分組方法，用這種分組意味着消息（tuple）的發送者指定由消息接收者的哪一個task處理這個消息。只有被聲明爲 Direct Stream 的消息流能夠聲明這種分組方法。並且這種消息tuple必須使用 emitDirect 方法來發射。消息處理者能夠經過 TopologyContext 來獲取處理它的消息的task的id (OutputCollector.emit方法也會返回task的id)  
(5.7)Local or shuffle grouping
本地或隨機分組。若是目標bolt有一個或者多個task與源bolt的task在同一個工做進程中，tuple將會被隨機發送給這些同進程中的tasks。不然，和普通的Shuffle Grouping行爲一致
(5.8)customGrouping
自定義，至關於mapreduce那裏本身去實現一個partition同樣。

(6)Reliability：可靠性。Storm 能夠經過拓撲來確保每一個發送的元組都能獲得正確處理。經過跟蹤由 Spout 發出的每一個元組構成的元組樹能夠肯定元組是否已經完成處理。每一個拓撲都有一個「消息延時」參數，若是 Storm 在延時時間內沒有檢測到元組是否處理完成，就會將該元組標記爲處理失敗，並會在稍後從新發送該元組。

備註：在0.90版本之前默認使用zeroMQ作底層通訊，以後的版本默認適用Netty。

 

5、storm應用場景

一、異步處理

客戶端提交數據進行結算，並不會等待數據計算結果，好比逐條處理（ETL）、統計分析（計算PV、UV、訪問熱點 以及 某些數據的聚合、加和、平均等，客戶端提交數據以後，計算完成結果存儲到Redis、HBase、MySQL或者其餘MQ當中，客戶端並不關心最終結果是多少）

二、同步處理

客戶端提交數據請求以後，馬上取得計算結果並返回給客戶端，好比DRPC