1 Storm介紹
Storm是由Twitter開源的分布式、高容錯的實時處理系統(tǒng)，它的出現令持續(xù)不斷的流計算變得容易，彌補了Hadoop批處理所不能滿足的實時要求。Storm常用于在實時分析、在線機器學習、持續(xù)計算、分布式遠程調用和ETL等領域。
在Storm的集群里面有兩種節(jié)點：控制節(jié)點(Master Node)和工作節(jié)點(Worker Node)?？刂乒?jié)點上面運行一個名為Nimbus的進程,它用于資源分配和狀態(tài)監(jiān)控；每個工作節(jié)點上面運行一個Supervisor的進程，它會監(jiān)聽分配給它所在機器的工作，根據需要啟動/關閉工作進程。Storm集群架構如下圖所示：
圖 1 Storm集群架構
Storm集群中每個組件具體描述如下：
l Nimbus：負責在集群里面發(fā)送代碼，分配工作給機器并且監(jiān)控狀態(tài)，在集群中只有一個，作用類似Hadoop里面的JobTracker。
l ZooKeeper：Storm重點依賴的外部資源，Nimbus、Supervisor和Worker等都是把心跳數據保存在ZooKeeper上，Nimbus也是根據ZooKeeper上的心跳和任務運行狀況進行調度和任務分配的。
l Supervisor：在運行節(jié)點上，監(jiān)聽分配的任務，根據需要啟動或關閉工作進程Worker。每一個要運行Storm的機器上都運行一個Supervisor，并且按照機器的配置設定上面分配的槽位數。
l Worker：在Supervisor上創(chuàng)建的一個JVM實例，Worker中運行Executor，而Executor作為Task運行的容器。
l Executor：運行時Task所在的直接容器，在Executor中執(zhí)行Task的處理邏輯。一個或多個Executor實例可以運行在同一個Worker進程中，一個或多個Task可以運行于同一個Executor中；在Worker進程并行的基礎上，Executor可以并行，進而Task也能夠基于Executor實現并行計算
l Task：Spout/Bolt在運行時所表現出來的實體，都稱為Task，一個Spout/Bolt在運行時可能對應一個或多個Spout Task或Bolt Task，與實際在編寫Topology時進行配置有關。在Storm0.8之后，Task不再與物理線程對應，同一個Spout Task或Bolt Task可能會共享一個物理線程，該線程稱為Executor。
Storm提交運行的程序稱為Topology，它處理的最小的消息單位是一個Tuple，也就是一個任意對象的數組。Topology由Spout和Bolt構成，Spout是發(fā)出Tuple的結點，Bolt可以隨意訂閱某個Spout或者Bolt發(fā)出的Tuple。下圖是一個Topology設計的邏輯圖的例子:
圖 2 Topology設計的邏輯圖
l Topology： Topology概念類似于Hadoop中的MapReduce作業(yè)，是一個用來編排、容納一組計算邏輯組件（Spout、Bolt）的對象（Hadoop MapReduce中一個作業(yè)包含一組Map任務、Reduce任務），這一組計算組件可以按照DAG圖的方式編排起來（通過選擇Stream Groupings來控制數據流分發(fā)流向），從而組合成一個計算邏輯更加負責的對象，那就是Topology。一個Topology運行以后就不能停止，它會無限地運行下去，除非手動干預（顯式執(zhí)行bin/storm kill）或意外故障（如停機、整個Storm集群掛掉）讓它終止。
l Spout： Spout是一個Topology的消息生產的源頭，Spout是一個持續(xù)不斷生產消息的組件，例如，它可以是一個Socket Server在監(jiān)聽外部Client連接并發(fā)送消息、可以是一個消息隊列（MQ）的消費者、可以是用來接收Flume Agent的Sink所發(fā)送消息的服務，等等。Spout生產的消息在Storm中被抽象為Tuple，在整個Topology的多個計算組件之間都是根據需要抽象構建的Tuple消息來進行連接，從而形成流。
l Bolt：Storm中消息的處理邏輯被封裝到Bolt組件中，任何處理邏輯都可以在Bolt里面執(zhí)行，處理過程和普通計算應用程序沒什么區(qū)別，只是需要根據Storm的計算語義來合理設置一下組件之間消息流的聲明、分發(fā)和連接即可。Bolt可以接收來自一個或多個Spout的Tuple消息，也可以來自多個其它Bolt的Tuple消息，也可能是Spout和其它Bolt組合發(fā)送的Tuple消息。
l Stream Grouping：Storm中用來定義各個計算組件（Spout和Bolt）之間流的連接、分組和分發(fā)關系。Storm定義了如下7種分發(fā)策略：Shuffle Grouping（隨機分組）、Fields Grouping（按字段分組）、All Grouping（廣播分組）、Global Grouping（全局分組）、Non Grouping（不分組）、Direct Grouping（直接分組）、Local or Shuffle Grouping（本地/隨機分組），各種策略的具體含義可以參考Storm官方文檔、比較容易理解。
在Storm中可以通過組件簡單串行或者組合多種流操作處理數據：
l Storm組件簡單串行
這種方式是最簡單最直觀的，只要我們將Storm的組件（Spout或Bolt）串行起來即可實現，只需要了解編寫這些組件的基本方法即可。在實際應用中，如果我們需要從某一個數據源連續(xù)地接收消息，然后順序地處理每一個請求，就可以使用這種串行方式來處理。如果說處理單元的邏輯非常復雜，那么就需要處理邏輯進行分離，屬于同一類操作的邏輯封裝到一個處理組件中，做到各個組件之間弱耦合。
圖 3 Storm組件簡單串行
l Storm組合多種流操作
Storm支持流聚合操作，將多個組件的數據匯聚到同一個處理組件來統(tǒng)一處理，可以實現對多個Spout組件通過流聚合到一個Bolt組件（Sout到Bolt的多對一、多對多操作），也可以實現對多個Bolt通過流聚合到另一個Bolt組件（Bolt到Bolt的多對一、多對多操作）。
圖 4 Storm組合多種流操作
下圖是Topology的提交流程圖：
圖 5 Topology的提交流程圖
1. 客戶端通過Nimbus的接口上傳程序jar包到Nimbus的Inbox目錄中，上傳結束后，通過提交方法向Nimbus提交一個Topology。
2. Nimbus接收到提交Topology的命令后，對接收到的程序jar包進行序列化，把序列化的結果放到Nimbus節(jié)點的stormdist目錄中，同時把當前Storm運行的配置生成一個stormconf.ser文件也放到該目錄中。靜態(tài)的信息設置完成后，通過心跳信息分配任務到機器節(jié)點。在設定Topology所關聯的Spouts和Bolts時，可以同時設置當前Spout和Bolt的Executor數目和Task數目，默認情況下，一個Topology的Task的總和與Executor的總和一致。之后，系統(tǒng)根據Worker的數目，盡量平均的分配這些Task的執(zhí)行。其中Worker在哪個Supervisor節(jié)點上運行是由Storm本身決定的。
3. 任務分配好之后，Nimbus節(jié)點會將任務的信息提交到ZooKeeper集群，同時在ZooKeeper集群中會有Worker分派節(jié)點，這里存儲了當前Topology的所有Worker進程的心跳信息。
4. Supervisor節(jié)點會不斷的輪詢ZooKeeper集群，在ZooKeeper的分派節(jié)點中保存了所有Topology的任務分配信息、代碼存儲目錄和任務之間的關聯關系等，Supervisor通過輪詢此節(jié)點的內容，來領取自己的任務，啟動Worker進程運行。
5. 一個Topology運行之后，就會不斷的通過Spout來發(fā)送Stream流，通過Bolt來不斷的處理接收到的數據流。
2 Spark Streaming與Storm比較
Storm和Spark Streaming都是分布式流處理的開源框架，但是它們之間還是有一些區(qū)別的，這里將進行比較并指出它們的重要的區(qū)別。
1. 處理模型以及延遲
雖然這兩個框架都提供可擴展性(Scalability)和可容錯性(Fault Tolerance),但是它們的處理模型從根本上說是不一樣的。Storm處理的是每次傳入的一個事件，而Spark Streaming是處理某個時間段窗口內的事件流。因此，Storm處理一個事件可以達到亞秒級的延遲，而Spark Streaming則有秒級的延遲。
2. 容錯和數據保證
在容錯數據保證方面的權衡方面，Spark Streaming提供了更好的支持容錯狀態(tài)計算。在Storm中，當每條單獨的記錄通過系統(tǒng)時必須被跟蹤，所以Storm能夠至少保證每條記錄將被處理一次，但是在從錯誤中恢復過來時候允許出現重復記錄，這意味著可變狀態(tài)可能不正確地被更新兩次。而Spark Streaming只需要在批處理級別對記錄進行跟蹤處理，因此可以有效地保證每條記錄將完全被處理一次，即便一個節(jié)點發(fā)生故障。雖然Storm的Trident library庫也提供了完全一次處理的功能。但是它依賴于事務更新狀態(tài)，而這個過程是很慢的，并且通常必須由用戶實現。
簡而言之,如果你需要亞秒級的延遲，Storm是一個不錯的選擇，而且沒有數據丟失。如果你需要有狀態(tài)的計算，而且要完全保證每個事件只被處理一次，Spark Streaming則更好。Spark Streaming編程邏輯也可能更容易，因為它類似于批處理程序，特別是在你使用批次(盡管是很小的)時。
3. 實現和編程API
Storm主要是由Clojure語言實現，Spark Streaming是由Scala實現。如果你想看看這兩個框架是如何實現的或者你想自定義一些東西你就得記住這一點。Storm是由BackType和 Twitter開發(fā)，而Spark Streaming是在UC Berkeley開發(fā)的。
Storm提供了Java API，同時也支持其他語言的API。 Spark Streaming支持Scala和Java語言(其實也支持Python)。另外Spark Streaming的一個很棒的特性就是它是在Spark框架上運行的。這樣你就可以想使用其他批處理代碼一樣來寫Spark Streaming程序，或者是在Spark中交互查詢。這就減少了單獨編寫流批量處理程序和歷史數據處理程序。
4. 生產支持
Storm已經出現好多年了，而且自從2011年開始就在Twitter內部生產環(huán)境中使用，還有其他一些公司。而Spark Streaming是一個新的項目，并且在2013年僅僅被Sharethrough使用(據作者了解)。
Storm是 Hortonworks Hadoop數據平臺中流處理的解決方案，而Spark Streaming出現在 MapR的分布式平臺和Cloudera的企業(yè)數據平臺中。除此之外，Databricks是為Spark提供技術支持的公司，包括了Spark Streaming。
5. 集群管理集成
盡管兩個系統(tǒng)都運行在它們自己的集群上，Storm也能運行在Mesos，而Spark Streaming能運行在YARN 和Mesos上。
