大數據——spark streaming 與 storm 的對比

最近一段時間由于公司項目的需要，調研了一下storm和Spark Streaming，并進行了一個簡單的對比，下面從以下幾個方面給大家做個簡單分享

前言

storm 集群架構圖

storm 集群相關術語介紹

spark 集群架構圖

spark 相關術語的介紹

storm 和 Spark Streaming 在實時性，吞吐量等方面的對比

storm 和 spark streaming 的使用建議（只是建議，不做參考）

前言

由于公司的業務增長及大數據在互聯網金融風控的普及，公司開始使用大數據進行相關風控規則的計算及模型訓練，在此背景下，數據平臺組這邊進行了一次大數據實時計算相關技術的調研及試運行，在此把其中的storm和spark streaming的相關對比分享給大家，希望給大家帶來幫助

storm 集群架構圖

storm 集群相關術語介紹

集群的物理機可以分為master節點和Supervisor節點，master，Supervisor說的是集群節點的角色，Worker是在集群節點上面運行的進程，executor是worker上的物理線程，Task是執行計算邏輯的線程，這個前提先搞清楚，下面是各組件作用

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

Supervisor:Storm集群的從節點，負責管理運行在Supervisor節點上的Worker進程的啟動和終止；通過Storm的配置文件中的supervisor.slots.ports配置項可以指定一個Supervisor節點上最大允許多少個Slot(所謂slot就是可用的worker進程)，每個Slot（槽）就是一個JVM，就是一個Worker進程。

Worker:運行executor，executor是一個物理線程，一個Worker可以運行一個或者多個executor。

Task：每一個spout/bolt的線程稱為一個Task，在storm0.8之后，task不再與物理線程（executor）對應，不同的spout/bolt可能共享一個物理線程（executor）。

Zookeeper:用來協調Nimbus和Supervisor，如果Supervisor因故障出現問題而無法運行Topology中的組件，Nimbus會第一時間感知到，并重新分配組件到其他可用的Supervisor上運行

在上面的組件中，worker，executor，task（spout/bolt）的關系容易混，通過下圖可以清楚的看懂（圖是storm0.8之前的圖，storm0.8以后是不同的（spout/bolt）task實例可以共享一個物理線程（executor））

spark 集群架構圖

spark 相關術語的介紹

Application：用戶編寫的Spark應用程序

Driver：運行上述Application的main()函數創建SparkContext，由架構圖也可以看出在Spark中由Driver創建的SparkContext負責和ClusterManager進行通信，進行資源的申請，任務的分配，任務的監控等，當Executor運行完畢后，Driver負責將SparkContext關閉。由于大部分功能都是有Driver創建的SparkContext完成，所以通常用SparkContext代表Driver；

Worker：相當于集群的計算節點，在Worker節點上可以運行一個或者多個Executor進程

Executor：運行在Worker 節點上的一個進程，該進程負責執行Task，并且負責將數據存在內存或者磁盤上，一個Worker默認情況下分配一個Executor，根據需要也可以在worker上運行多個Executor。一個節點，如果配置了多個Executor，那么就會涉及到性能調優。

Task：邏輯計算單元，一個executor里面可以運行很多Task線程

注意：這個spark的Executor是進程，在storm中，同樣的名字（executor）是個物理線程

storm 和 spark streaming 在實時性，吞吐量等方面的對比

1、實時性：一般Storm的時延性比spark streaming要低，原因是Spark Streaming是小的批處理，通過間隔時長生成批次，一個批次觸發一次計算，比如我在程序里面設置間隔時長為5秒，那就是五秒接收到的數據觸發一次計算，Storm是實時處理，來一條數據，觸發一次計算，所以可以稱spark streaming為流式計算，Storm 為實時計算，阿里的JStorm通過實現Trident,也支持小的批處理計算

2、吞吐量 ：Storm的吞吐量要略差于Spark Streaming，原因一是Storm從spout組件接收源數據，通過發射器發送到bolt，bolt對接收到的數據進行處理，處理完以后，寫入到外部存儲系統中或者發送到下個bolt進行再處理，所以storm是移動數據，不是移動計算；Spark Streaming獲取Task要計算的數據在哪個節點上，然后TaskScheduler把task發送到對應節點上進行數據處理，所以Spark Streaming是移動計算不是移動數據，移動計算也是當前計算引擎的主流設計思想;原因二大家很容易看出來，一個是批處理，一個是實時計算，批處### 理的吞吐量一般要高于實時觸發的計算

3、容錯機制：storm是acker（ack/fail消息確認機制）確認機制確保一個tuple被完全處理，Spark Streaming是通過存儲RDD轉化邏輯進行容錯，也就是如果數據從A數據集到B數據集計算錯誤了，由于存儲的有A到B的計算邏輯，所以可以從A重新計算生成B，容錯機制不一樣，暫時無所謂好壞

storm 和 spark streaming 的使用建議（只是建議，不做參考）

1、在那種需要純實時的場景下使用Storm

2、由于Storm可以動態調整實時計算程序的并行度，所以在需要針對高峰低峰時間段，動態調整實時計算程序的并行度，以最大限度利用集群資源（通常是在小型公司，集群資源緊張的情況）的情況下，考慮用Storm，比如用命令行動態調整并行度

storm rebalance mytopology -w 10 -n 2 -e spout=2 -e bolt=2

表示 10秒之后對mytopology進行并行度調整。把worker調整為兩個，spout調整為2個executor，把bolt調整為2個executor

3、復雜的實時計算邏輯選用Spark Streaming

4、Spark Streaming有一點是Storm絕對比不上的，那就是spark提供了一個統一的解決方案，在一個集群里面可以進行離線計算，流式計算，圖計算，機器學習等，而storm集群只能單純的進行實時計算

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。