spark 與storm的對比及適用場景

2021-08-25 05:24:19 字數 2444 閱讀 8271

學習大資料有一段時間了,學完spark 和storm 後,就希望這兩個實時處理系統做個對比,以便於在以後的技術選型方面有很好的把握。

對比點storm

spark streaming

實時計算模型

純實時,來一條資料,處理一條資料

準實時,對乙個時間段內的資料收集起來,作為乙個rdd,再處理

實時計算延遲度

毫秒級秒級

吞吐量低

高事務機制

支援完善

支援,但不夠完善

健壯性 / 容錯性

zookeeper,acker,非常強

checkpoint,wal,一般

動態調整並行度

支援不支援

spark streaming與storm的應用場景

對於storm來說:

1、建議在那種需要純實時,不能忍受1秒以上延遲的場景下使用,比如實時金融系統,要求純實時進行金融交易和分析

2、此外,如果對於實時計算的功能中,要求可靠的事務機制和可靠性機制,即資料的處理完全精準,一條也不能多,一條也不能少,也可以考慮使用storm

3、如果還需要針對高峰低峰時間段,動態調整實時計算程式的並行度,以最大限度利用集群資源(通常是在小型公司,集群資源緊張的情況),也可以考慮用storm

4、如果乙個大資料應用系統,它就是純粹的實時計算,不需要在中間執行sql互動式查詢、複雜的transformation運算元等,那麼用storm是比較好的選擇

對於spark streaming來說:

1、如果對上述適用於storm的三點,一條都不滿足的實時場景,即,不要求純實時,不要求強大可靠的事務機制,不要求動態調整並行度,那麼可以考慮使用spark streaming

2、考慮使用spark streaming最主要的乙個因素,應該是針對整個專案進行巨集觀的考慮,即,如果乙個專案除了實時計算之外,還包括了離線批處理、互動式查詢等業務功能,而且實時計算中,可能還會牽扯到高延遲批處理、互動式查詢等功能,那麼就應該首選spark生態,用spark core開發離線批處理,用spark sql開發互動式查詢,用spark streaming開發實時計算,三者可以無縫整合,給系統提供非常高的可擴充套件性

spark streaming與storm的優劣分析

事實上,spark streaming絕對談不上比storm優秀。這兩個框架在實時計算領域中,都很優秀,只是擅長的細分場景並不相同。

spark streaming僅僅在吞吐量上比storm要優秀,而吞吐量這一點,也是歷來挺spark streaming,貶storm的人著重強調的。但是問題是,是不是在所有的實時計算場景下,都那麼注重吞吐量?不盡然。因此,通過吞吐量說spark streaming強於storm,不靠譜。

事實上,storm在實時延遲度上,比spark streaming就好多了,前者是純實時,後者是準實時。而且,storm的事務機制、健壯性 / 容錯性、動態調整並行度等特性,都要比spark streaming更加優秀。

spark streaming,有一點是storm絕對比不上的,就是:它位於spark生態技術棧中,因此spark streaming可以和spark core、spark sql無縫整合,也就意味著,我們可以對實時處理出來的中間資料,立即在程式中無縫進行延遲批處理、互動式查詢等操作。這個特點大大增強了spark streaming的優勢和功能。

spark基於這樣的理念,當資料龐大時,把計算過程傳遞給資料要比把資料傳遞給計算過程要更富效率。每個節點儲存(或快取)它的資料集,然後任務被提交給節點。

所以這是把過程傳遞給資料。這和hadoop map/reduce非常相似,除了積極使用記憶體來避免i/o操作,以使得迭代演算法(前一步計算輸出是下一步計算的輸入)效能更高。

shark只是乙個基於spark的查詢引擎(支援ad-hoc臨時性的分析查詢)

而storm的架構和spark截然相反。storm是乙個分布式流計算引擎。每個節點實現乙個基本的計算過程,而資料項在互相連線的網路節點中流進流出。和spark相反,這個是把資料傳遞給過程。

兩個框架都用於處理大量資料的平行計算。

storm在動態處理大量生成的「小資料塊」上要更好(比如在twitter資料流上實時計算一些匯聚功能或分析)。

spark工作於現有的資料全集(如hadoop資料)已經被匯入spark集群,spark基於in-memory管理可以進行快訊掃瞄,並最小化迭代演算法的全域性i/o操作。

不過spark流模組(streaming module)倒是和storm相類似(都是流計算引擎),儘管並非完全一樣。

spark流模組先匯聚批量資料然後進行資料塊分發(視作不可變資料進行處理),而storm是只要接收到資料就實時處理並分發。

不確定哪種方式在資料吞吐量上要具優勢,不過storm計算時間延遲要小。

總結下,spark和storm設計相反,而spark steaming才和storm類似,前者有資料平滑視窗(sliding window),而後者需要自己去維護這個視窗。

spark與storm的對比

對比點 storm spark streaming 實時計算模型 純實時,來一條資料,處理一條資料 準實時,對乙個時間段內的資料收集起來,作為乙個rdd,再處理 實時計算延遲度 毫秒級 秒級 吞吐量 低 高 事務機制 支援完善 支援,但不夠完善 健壯性 容錯性 zookeeper,acker,非常強...

spark與storm的對比

對比點 storm spark streaming 實時計算模型 純實時,來一條資料,處理一條資料 準實時,對乙個時間段內的資料收集起來,作為乙個rdd,再處理 實時計算延遲度 毫秒級 秒級 吞吐量 低 高事務機制 支援完善 支援,但不夠完善 健壯性 容錯性 zookeeper,acker,非常強 ...

spark與storm的對比

對比點storm spark streaming 實時計算模型 純實時,來一條資料,處理一條資料 準實時,對乙個時間段內的資料收集起來,作為乙個rdd,再處理 實時計算延遲度 毫秒級秒級 吞吐量低 高事務機制 支援完善 支援,但不夠完善 健壯性 容錯性 zookeeper,acker,非常強 che...