Apache Storm是用於處理實時流數據的流處理引擎。而Apache Spark是通用計算引擎。它提供Spark Streaming 來處理流數據。它幾乎實時處理數據。讓我們瞭解在Spark與Storm的戰鬥中哪個更好。
因此，讓我們開始比較Apache Storm和Spark Streaming。
以下描述顯示了Apache Storm與Spark Streaming之間的詳細功能差異。這些差異將幫助您瞭解在Apache Storm和Spark之間使用哪種更好。讓我們一一看一下每個功能
1）處理模型
· Storm：它通過核心Storm層支持真正的流處理模型。
· Spark Streaming：Apache Spark Streaming是Spark批處理的包裝。
2）原語
· Storm： 它提供了非常豐富的原語集，可以按流間隔（過濾器，函數）執行元組級處理。通過按語義分組，可以對流中的消息進行聚合。它支持整個流中的左連接，右連接，內部連接（默認）。
· Spark Streaming：它提供2種類型的運算符。首先是 Stream轉換運算符 ，它將一個 DStream 轉換為另一個DStream。其次是 將信息寫入外部系統的輸出運算符。之前的對象包括無狀態運算符（過濾器，地圖，mapPartitions，聯合，不同於on）仍作為有狀態窗口運算符（countByWindow，reduceByWindow然後打開）。
3）狀態管理
· Storm：默認情況下，Core Storm不提供任何框架級別的支持來將任何中間過程輸出（用戶操作的結果）存儲為狀態。因此，任何應用程序都必須根據需要創建/更新自己的狀態。
· Spark Streaming： 默認情況下，基礎Spark將每個RDD操作（Transformations和Actions）的輸出視為中間狀態。它將其存儲為RDD。Spark Streaming允許通過updateStateByKey API 維護和更改狀態 。找不到可插入的方法來實現外部系統中的狀態。
4）消息傳遞保證（處理消息失敗級別）
· Storm： 它支持3種消息處理保證： 至少一次， 至多一次 和 恰好一次。Storm的可靠性機制是分佈式的，可伸縮的和容錯的。
· Spark Streaming： Apache Spark Streaming定義了其 容錯 語義，即接收方和輸出操作員提供的保證。按照 Apache Spark架構，傳入的數據在不同的Spark執行程序的節點中讀取和複製。這將生成接收到的故障場景數據，但可能不會反映出來。在工人故障和駕駛員故障的情況下，它對容錯能力的處理方式有所不同。
5）容錯（處理過程/節點級別的故障）
· Storm：Storm旨在以容錯為核心。Storm守護程序（Nimbus和Supervisor）被設置為快速失敗（這意味著該方法在遇到任何突發情況時都會自毀）和無狀態（在Zookeeper或磁盤中所有狀態都不會中斷）。
· Spark Streaming：驅動程序節點（等效於JT）是 SPOF。如果驅動程序節點發生故障，則所有執行程序都將丟失其接收和複製的內存中信息。因此，Spark Streaming使用 數據檢查點來克服驅動程序故障。
6）可調試性和監控
· Storm： 每種部署的Apache Storm UI支持圖像；與內部噴嘴和螺栓的整體破裂。UI還提供了有關任務中是否有任何錯誤的信息，以及正在運行的部署的每個部分的吞吐量和延遲的詳細統計信息。它有助於高級別調試問題。 基於指標的監視： Storm的內置指標功能支持應用程序框架級別以發出任何指標，這些指標可以簡單地與外部指標/監視系統集成。
· Spark Streaming： Spark Web UI顯示一個額外的Streaming選項卡，該選項卡顯示正在運行的接收器（接收器是否處於活動狀態，接收到的記錄的種類，接收器錯誤等）和完成的批處理（批處理時間，排隊延遲等）的統計信息上）。觀察應用程序的執行很有用。Spark Web UI中的以下2條信息對於批量大小的標準化非常必要：
1處理時間 –處理每批數據的時間。
2計劃延遲 –批處理在隊列中等待先前批處理完成的時間。
7）自動擴展
· Storm： 它可以在每個部署的各個級別上配置初始並行性-各種工作進程，執行器，任務。此外，它支持動態重新平衡，從而允許增加或減少不需重新啟動集群或部署的工作進程和執行程序的數量。但是，許多設計的初始任務在部署的整個生命週期中保持不變。
一旦所有主管節點完全滿足工作程序流程的需求，並且需要進行擴展，則只需啟動一個替換主管節點並將其通知集群範圍內的Zookeeper。
可以改變監視非常Storm群集中每個節點上當前資源消耗的邏輯，並動態添加大量資源。STORM-594描述了採用反饋系統的這種自動縮放機制。
· Spark Streaming：社區正在開發動態擴展到流媒體應用程序。目前，不支持Spark Streaming應用程序的彈性擴展。
本質上，動態分配並不意味著立即（1.4或更早版本）在Spark Streaming中使用。原因是當前接收部署是靜態的。接收器的數量是固定的。每個DStream實例化後，一個接收者就會分配，它將在集群中使用一個核心。一旦StreamingContext啟動，此部署就無法修改。殺死接收器會導致停止部署。
8）Yarn集成
· Storm： 建議通過Apache Slider將Storm與YARN集成 。滑塊是YARN應用程序，可在YARN群集上部署非YARN分佈式應用程序。它與YARN RM交互以生成用於分佈式應用程序的容器，然後管理這些容器的生命週期。Slider為Storm提供了開箱即用的應用程序包。
· Spark Streaming： Spark框架與YARN一起提供本機集成。Spark Streaming作為Spark之上的一層僅利用了集成。每個Spark Streaming媒體應用程序都將複製為單獨的Yarn應用程序。該ApplicationMaster 容器運行星火驅動器和初始化SparkContext。每個執行器 和接收器都在ApplicationMaster管理的容器中運行。然後，ApplicationMaster會定期在YARN容器上的每個微批提交一項作業。
9）隔離
· Storm：每個員工流程都為特定部署運行執行程序。混合各種部署任務不允許在工作進程級別進行，而該工作進程支持部署級別的運行時隔離。此外，每個執行程序線程都運行一個相同元素（噴嘴或螺栓）的一個或多個任務，這不是跨元素的任務混合。
· Spark Streaming： Spark應用程序是在YARN群集上運行的不同應用程序，無論每個執行程序在不同的YARN容器中運行。因此，Yarn提供了JVM級別的隔離，因為2個完全不同的部署無法在同一JVM中執行。此外，YARN提供資源級別隔離，以便可以組織容器級別的資源約束（CPU，內存限制）。
10）Apache開源社區
· Storm： 在許多使用案例中，正在生產環境中運行Storm的公司的Apache Storm技術支持頁健康列表。其中許多是大規模的Web部署，它們正在推動性能和規模的界限。例如，Yahoo閱讀由兩個300個運行Storm的節點組成，用於近實時事件處理，最大的部署跨越400個節點。
· Spark Streaming： Apache Spark Streaming仍在上升，並且在生產集群中的專業知識受到限制。但是，一般的傘形Apache Spark社區是目前最大的，因此也是最活躍的開放供應社區之一。鑑於龐大的開發人員基礎，一般章程在不斷髮展。這可能會導致Spark Streaming在不久的將來成熟。
11）易於發展
· Storm： 它提供了非常簡單，豐富和直觀的API，它們僅描述了流程（部署）的DAG性質。動態編寫了Storm元組，該元組給出了DAG中節點之間的數據流的抽象。這樣做的動機是為了簡化使用而更改API。註冊其Kryo序列化程序後，可以插入任何新的自定義元組。開發人員將從編寫部署開始，然後以本機集群模式運行它們。在本地模式下，線程用於模擬工作程序節點，允許開發人員設置斷點，暫停執行，檢查變量和配置文件，然後再將其部署到分佈式集群中，而這通常在所有這些方面都比較困難。
· Spark Streaming： 它提供 具有大量實際編程（數據轉換）的Scala 和Java API，部署代碼的方式很多。 市場上為開發人員提供了一套高檔的API文檔和說明性示例。
12）易於操作
Storm：通過許多工具（puppets等）部署/安裝Storm並部署集群，這並不是一件容易的事。Apache Storm包含對Zookeeper集群的依賴。 這樣它就可以滿足群集上的協調，存儲狀態和統計信息。它實現CLI支持以安裝諸如提交，激活，停用，列出，終止部署之類的操作。強大的容錯能力表明任何守護程序時間段都不會影響正在執行的部署。
在獨立模式下，Storm守護程序被強制在監督模式下運行。在YARN群集模式下，Storm守護程序作為容器出現，並由Application Master（Slider）驅動。
· Spark Streaming： 它使用Spark作為基本執行框架。 在YARN上填充Spark集群應該很容易 。有許多部署要求。通常，我們啟用檢查點以提高應用程序驅動程序的容錯能力。這可能會導致對容錯存儲（HDFS）的依賴。
13）語言選項
· Storm：我們可以使用Java，Clojure和Scala創建Storm應用程序。
· Spark Streaming：我們可以使用Java，Scala，Python和R創建Spark應用。
閱讀更多 發家致富全靠它 的文章
