Spark記錄-spark與storm比對與選型(轉載)

大數據實時處理平臺市場上產品衆多,本文着重討論spark與storm的比對,最後結合適用場景進行選型。

1、spark與storm的比較框架

比較點post

Storm大數據

Spark Streamingspa

實時計算模型orm

純實時,來一條數據,處理一條數據事務

準實時,對一個時間段內的數據收集起來,做爲一個RDD,再處理ci

實時計算延遲度資源

毫秒級開發

秒級產品

吞吐量

事務機制

支持完善

支持,但不夠完善

健壯性 / 容錯性

ZooKeeper,Acker,很是強

Checkpoint,WAL,通常

動態調整並行度

支持

不支持

 

2、Spark Streaming與Storm的應用場景 

適用Storm的場景:

一、須要純實時,不能忍受1秒以上延遲的場景下使用,好比實時金融系統,要求純實時進行金融交易和分析

二、對於實時計算的功能中,要求可靠的事務機制和可靠性機制,即數據的處理徹底精準,一條也不能多,一條也不能少,也能夠考慮使用Storm

三、若還須要針對高峯低峯時間段,動態調整實時計算程序的並行度,以最大限度利用集羣資源(一般是在小型公司,集羣資源緊張的狀況),也能夠考慮用Storm

四、若是一個大數據應用系統,它就是純粹的實時計算,不須要在中間執行SQL交互式查詢、複雜的transformation算子等,那麼用Storm是比較好的選擇

適用Spark Streaming的場景:

一、若是對上述適用於Storm的三點,一條都不知足的實時場景,即:不要求純實時,不要求強大可靠的事務機制,不要求動態調整並行度,那麼能夠考慮使用Spark Streaming

二、考慮使用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的優點和功能。

相關文章
相關標籤/搜索