實時大數據頂級分析工具Storm圖文解析

前言

許多分散式計算系統都可以實時或者接近實時地處理大數據流。今天，我們將為大家介紹一個非常有效的開源實時計算工具——Storm

Storm 與Hadoop的區別

Storm 與Hadoop最大的不同之處在於它的處理方式。Hadoop 在本質上是一個批處理系統。數據被引入Hadoop 文件系統(HDFS) 並分發到各個節點進行處理。當處理完成時，結果數據返回到 HDFS 供始發者使用。Storm 支持創建拓撲結構來轉換沒有終點的數據流。不同於 Hadoop 作業，這些轉換從不停止，它們會持續處理到達的數據。

你也可以將它們形象地理解為桶裝水與自來水的區別。Hadoop需要一份一份地進行打包、處理、搬運，通常來說，從「水源水」到「飲用水」需要等待比較長的一段時間。Storm則建立了一套管網系統，管網系統中可以任意地添加「水」處理環節，或者安裝「水龍頭」進行數據輸入和輸出，從而整個處理過程變得更加流暢、快捷。

Storm相關基礎概念

在Storm的集群裡面有兩種節點：控制節點(master node)和工作節點(worker node)。控制節點上面運行一個後台程序：Nimbus，它的作用類似Hadoop裡面的JobTracker。Nimbus負責在集群裡面分布代碼，分配工作給機器，並且監控狀態。

每一個工作節點上面運行一個叫做Supervisor的節點（類似 TaskTracker）。Supervisor會監聽分配給它那台機器的工作，根據需要啟動/關閉工作進程。每一個工作進程執行一個Topology（類似 Job）的一個子集；一個運行的Topology由運行在很多機器上的很多工作進程Worker（類似Child）組成。

storm topology結構

（一）Topologies

為了在storm上面做實時計算，需要建立一些圖狀結構，我們稱之為（topologies）。一個topology是spouts和bolts組成的圖，其中spout負責發送消息，負責將數據流以tuple元組的形式發送出去；而bolt則負責轉換這些數據流，在bolt中可以完成計算、過濾等操作，bolt自身也可以隨機將數據發送給其他bolt。

Spouts和bolts通過stream groupings（定義一個流在Bolt任務間該如何被切分）連接起來，我們也可以將它理解為一個由無限制的處理節點組成的圖狀結構。Topology裡面的每個處理節點都包含處理邏輯，而節點之間的連接則表示數據流動的方向。

（二）Stream groupings

定義一個topology的其中一步是定義每個bolt接收什麼樣的流作為輸入。stream grouping就是用來定義一個stream應該如果分配數據給bolts上面的多個tasks。

（三）Streams

消息流stream是storm里的關鍵抽象。一個消息流是一個沒有邊界的tuple序列（ tuple是一個類似於列表的東西，存儲的每個元素叫做field），而這些tuple序列會以一種分散式的方式並行地創建和處理。通過對stream中tuple序列中每個欄位命名來定義stream。

（四）Spouts

消息源spout是Storm裡面一個topology裡面的消息生產者。一般來說消息源會從一個外部源讀取數據並且向topology裡面發出消息：tuple。Spout可以是可靠的也可以是不可靠的。如果這個tuple沒有被storm成功處理，可靠的消息源spouts可以重新發射一個tuple，但是不可靠的消息源spouts一旦發出一個tuple就不能重發了。

（五）Bolts

所有的消息處理邏輯被封裝在bolts裡面。Bolts可以做很多事情：過濾，聚合，查詢資料庫等等。

Bolts可以簡單的做消息流的傳遞。複雜的消息流處理往往需要很多步驟，從而也就需要經過很多bolts。比如算出一堆圖片裡面被轉發最多的圖片就至少需要兩步：第一步算出每個圖片的轉發數量。第二步找出轉發最多的前10個圖片。（如果要把這個過程做得更具有擴展性那麼可能需要更多的步驟）。

Storm應用優勢

（一）易擴展

在 Storm集群中真正運行topology的主要有三個實體：工作進程、線程和任務。Storm集群中的每台機器上都可以運行多個工作進程，每個工作進程又可創建多個線程，每個線程可以執行多個任務，任務是真正進行數據處理的實體，spout、bolt就是作為一個或者多個任務的方式執行的。

因此，計算任務在多個線程、進程和伺服器之間並行進行，支持靈活的水平擴展，用戶通過追加機器就能提供並發數進而提高處理能力。

（二）高性能，低延遲

Storm採用內存計算模式，無需藉助文件存儲，直接通過網路直傳中間計算結果,避免了組件之間傳輸數據的大量時間損耗?數據從產生到最終能看到結果，也就是秒，甚至是毫秒的延遲。

當計算模型比較適合流式時，storm的流式處理，省去了批處理的收集數據的時間；

在將Topology提交到Storm集群的時候,集群會針對該Topology做一次初始化的工作?此後,在Topology運行過程中,對於輸入數據而言,是沒有計算框架初始化耗時的,有效避免了計算框架初始化的時間損耗?

（三）高容錯

流處理系統的容錯性比批處理系統更難實現。當批處理系統中出現錯誤時，只需要把失敗的部分簡單重啟即可；但對於流處理系統，出現錯誤就很難恢復，因為線上許多作業都是7 x 24小時運行的，數據在源源不斷地輸入。另外，流處理系統面臨的另外一個挑戰是狀態一致性，因為重啟後會出現重複數據，並且不是所有的狀態操作是冪等的，所以容錯性很難實現。

Storm採用了上游數據備份和消息確認的機制，來保障消息在失敗之後能夠重新處理。Storm的消息確認原理是，每個操作都會把前一次操作處理消息的確認信息返回，同時，Topology的數據源還會備份它生成的所有數據記錄。當所有數據記錄的處理確認信息收到，備份即會被安全拆除；失敗後，如果不是所有的消息處理確認信息被收到，那數據記錄會被數據源數據替換。此舉能夠保障不會發生數據丟失事件，但是，也會帶來數據結果重複的問題，這就是at-least once傳輸機制。

Storm可以說是採用了取巧的辦法完成容錯性。它對每個源數據記錄僅僅要求幾個位元組存儲空間來跟蹤確認消息，通過純數據記錄消息確認架構。這樣做，儘管性能不錯，但不能保證exactly once消息傳輸機制，所有應用開發者都需要處理重複數據。Storm存在低吞吐量和流控問題，因為消息確認機制在反壓下經常誤認為失敗。

消息傳輸保障一般有三種：at most once，at least once和exactly once。At most once的消息傳輸機制是每條消息傳輸零次或者一次，即消息可能會丟失；At least once意味著每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重複但不會丟失；Exactlyonce的消息傳輸機制是每條消息有且只有一次，即消息傳輸既不會丟失也不會重複。

Storm的高容錯機制還體現在它能夠自動處理進程、機器、網路等異常。

當一個worker死掉，那麼supervisor會重新啟動這個worker。如果它總是啟動失敗將不能發送心跳到nimbus，那麼nimbus將把這個worker分配到另一台機器上。

當一個節點死掉，或者與節點間連接的網路出現故障時，分配給這台機器的任務將會超時，那麼nimbus將會把任務重新分配到其他機器。

Nimbus和Supervisor被設計成快速失敗的（當發生任何意外情況時進程將自己結束）和無狀態的（所有的狀態都存在zookeeper里或者磁碟上）。當啟動一個storm群集時，Nimbus和Supervisor進程將使用進程工具或監視工具來運行一個守護進程。因此，當Nimbus和Supervisor進程死掉時，守護進程會重啟它們就像什麼都沒發生過。

如果丟失了nimbus節點，worker將會繼續運行程序，另外，supervisors 將會繼續重啟失敗的worker。但是，如果一直沒有nimbus，當需要的時候worker將不能被分配給其他機器（例如有一台worker機器丟失的情況）。

因此，nimbus近乎是一個單點故障，在實踐中，這並不是一個大問題，當nimbus節點丟失時，並不會有什麼災難發生。Storm也有計劃在未來提高nimbus的高可用性。

Storm的三大類應用

（一）信息流處理

Storm可用來實時處理新數據和更新資料庫，兼具容錯性和可擴展性。即Storm可以用來處理源源不斷流進來的消息，處理之後將結果寫入到某個存儲中去。

（二）連續計算

Storm可進行連續查詢並把結果即時反饋給客戶端。比如把Twitter上的熱門話題發送到瀏覽器中。

（三）分散式遠程程序調用

Storm可用來並行處理密集查詢。Storm的拓撲結構是一個等待調用信息的分布函數，當它收到一條調用信息後，會對查詢進行計算，並返回查詢結果。舉個例子Distributed RPC可以做並行搜索或者處理大集合的數據。

版權申明：本文由智慧思特編輯整理，如需轉載，可申請授權。部分圖片來自網路，侵刪。

http://weixin.qq.com/r/bzizq0vE7haRrQ-I9219 (二維碼自動識別)

》》》更多精彩文章

• 天了嚕！這些巨頭都成了Docker粉

• Spark：取代MapReduce的大數據處理平台

• 由淺入深理解MapReduce

• DevOps的前世今生

• 【深度長文】Hadoop生態圈介紹及入門

• 技術大咖解析兩款頂級大數據分析引擎：Flink與Spark有何異同

• 科普：2分鐘讀懂大數據框架Hadoop和Spark的異同

推薦閱讀：