storm集羣架構

1、storm何許人也？

Storm 是Twitter的一個開源框架。Storm一個分佈式的、容錯的實時計算系統，它被託管在GitHub上，遵循 Eclipse Public License 1.0。Storm是由BackType開發的實時處理系統，BackType如今已在Twitter麾下。GitHub上的最新版本是Storm 0.9.0.1，基本是用Clojure寫的。

Twitter Storm集羣表面上相似於Hadoop集羣，Hadoop上運行的是MapReduce Jobs，而Storm運行topologies；可是其自己有很大的區別，最主要的區別在於，Hadoop MapReduce Job運行最終會完結，而Storm topologies處理數據進程理論上是永久存活的，除非你將其Kill掉。

Storm集羣中包含兩類節點：主控節點（Master Node）和工做節點（Work Node）。

2、其分別對應的角色以下：

1. 主控節點（Master Node）上運行一個被稱爲Nimbus的後臺程序，它負責在Storm集羣內分發代碼，分配任務給工做機器，而且負責監控集羣運行狀態。Nimbus的做用相似於Hadoop中JobTracker的角色。
2. 每一個工做節點（Work Node）上運行一個被稱爲Supervisor的後臺程序。Supervisor負責監遵從Nimbus分配給它執行的任務，據此啓動或中止執行任務的工做進程。每個工做進程執行一個Topology的子集；一個運行中的Topology由分佈在不一樣工做節點上的多個工做進程組成。

Nimbus和Supervisor節點之間全部的協調工做是經過Zookeeper集羣來實現的。此外，Nimbus和Supervisor進程都是快速失敗（fail-fast)和無狀態（stateless）的；Storm集羣全部的狀態要麼在Zookeeper集羣中，要麼存儲在本地磁盤上。這意味着你能夠用kill -9來殺死Nimbus和Supervisor進程，它們在重啓後能夠繼續工做。這個設計使得Storm集羣擁有難以想象的穩定性。

在Storm集羣上要實現實時計算，須要建立Topologies。一個Topology是一個計算的曲線圖。Topology中的每一個節點包含處理邏輯，而且節點之間的鏈路表示數據如何應圍繞節點之間傳遞。
運行一個Topology比較簡單，首先，你打包全部的代碼和依賴關係的包打成一個jar包。而後，您運行以下命令：

storm jar all-my-code.jar backtype.storm.MyTopology arg1 arg2
這裏運行一個包含arg1和arg2兩個參數的backtype.storm.MyTopology類。main方法定義Topology以及提交到Nimbus，storm jar部分鏈接Nimbus以及上傳jar包到集羣。

因爲Topology的定義是Thirf結構，而且Nimbus是一個Thirf 服務，因此你可使用任何語言建立以及提交Topology。
Storm是一個實時流處理框架，那麼它的抽象核心固然就是流。 Storm也可被用於「連續計算」（continuous computation），對數據流作連續查詢，在計算時就將結果以流的形式輸出給用戶。它還可被用於「分佈式RPC」，以並行的方式運行昂貴的運算。

Storm的主工程師Nathan Marz表示：

Storm能夠方便地在一個計算機集羣中編寫與擴展複雜的實時計算，Storm之於實時處理，就比如 Hadoop之於批處理。Storm保證每一個消息都會獲得處理，並且它很快——在一個小集羣中，每秒能夠處理數以百萬計的消息。更棒的是你可使用任意編程語言來作開發。

Storm的主要特色以下：

1) 簡單的編程模型。相似於Mapreduce下降了並行批處理複雜性，Storm下降了進行實時處理的複雜性。

2）可使用各類編程語言:你能夠在Storm之上使用各類編程語言。默認支持Clojure、Java、Ruby和Python。要增長對其餘語言的支持，只需實現一個簡單的Storm通訊協議便可。

3）容錯性:Storm會管理工做進程和節點的故障。

4）水平擴展:計算是在多個線程、進程和服務器之間並行進行的。

5）可靠的消息處理:Storm保證每一個消息至少能獲得一次完整處理。任務失敗時，它會負責從消息源重試消息。

6）快速:系統的設計保證了消息能獲得快速的處理，使用ZeroMQ做爲其用底層消息隊列。

7）本地模式:Storm有一個「本地模式」，能夠在處理過程當中徹底模擬Storm集羣。這讓你能夠快速進行開發和單元測試。

Storm集羣架構

Storm集羣採用主從架構方式，主節點是Nimbus，從節點是Supervisor，有關調度相關的信息存儲到ZooKeeper集羣中，架構以下圖所示：

具體描述，以下所示：

Nimbus
Storm集羣的Master節點，負責分發用戶代碼，指派給具體的Supervisor節點上的Worker節點，去運行Topology對應的組件（Spout/Bolt）的Task。

Supervisor
Storm集羣的從節點，負責管理運行在Supervisor節點上的每個Worker進程的啓動和終止。經過Storm的配置文件中的supervisor.slots.ports配置項，能夠指定在一個Supervisor上最大容許多少個Slot，每一個Slot經過端口號來惟一標識，一個端口號對應一個Worker進程（若是該Worker進程被啓動）。

ZooKeeper
用來協調Nimbus和Supervisor，若是Supervisor因故障出現問題而沒法運行Topology，Nimbus會第一時間感知到，並從新分配Topology到其它可用的Supervisor上運行。

Stream Groupings
Storm中最重要的抽象，應該就是Stream grouping了，它可以控制Spot/Bolt對應的Task以什麼樣的方式來分發Tuple，將Tuple發射到目的Spot/Bolt對應的Task，以下圖所示：

目前，Storm Streaming Grouping支持以下幾種類型：
Shuffle Grouping：隨機分組，跨多個Bolt的Task，可以隨機使得每一個Bolt的Task接收到大體相同數目的Tuple，可是Tuple不重複

Fields Grouping：根據指定的Field進行分組 ，同一個Field的值必定會被髮射到同一個Task上

Partial Key Grouping：與Fields grouping 相似，根據指定的Field的一部分進行分組分發，可以很好地實現Load balance，將Tuple發送給下游的Bolt對應的Task，特別是在存在數據傾斜的場景，使用 Partial Key grouping可以更好地提升資源利用率

All Grouping：全部Bolt的Task都接收同一個Tuple（這裏有複製的含義）

Global Grouping：全部的流都指向一個Bolt的同一個Task（也就是Task ID最小的）

None Grouping：不須要關心Stream如何分組，等價於Shuffle grouping

Direct Grouping：由Tupe的生產者來決定發送給下游的哪個Bolt的Task ，這個要在實際開發編寫Bolt代碼的邏輯中進行精確控制

Local or Shuffle Grouping：若是目標Bolt有1個或多個Task都在同一個Worker進程對應的JVM實例中，則Tuple只發送給這些Task

另外，Storm還提供了用戶自定義Streaming Grouping接口，若是上述Streaming Grouping都沒法知足實際業務需求，也能夠本身實現，只須要實現backtype.storm.grouping.CustomStreamGrouping接口，該接口定義了以下方法：

List<Integer> chooseTasks(int taskId, List<Object> values)

上面幾種Streaming Group的內置實現中，最經常使用的應該是Shuffle Grouping、Fields Grouping、Direct Grouping這三種，使用其它的也能知足特定的應用需求。

感謝您閱讀本文章，更多內容或支持推薦您點擊 上海大數據培訓 轉載請說明出處！