兩款高效能並行計算引擎Storm和Spark簡單比較

Spark基於這樣的理念，當資料龐大時，把計算過程傳遞給資料要比把資料傳遞給計算過程要更富效率。每個節點儲存（或緩衝）它的資料集，然後任務被提交給節點。所以這是把過程傳遞給資料。這和Hadoop map/reduce非常相似，除了積極使用記憶體來避免I/O操作，以使得迭代演算法（前一步計算輸出是下一步計算的輸入）效能更高。Shark只是一個基於Spark的查詢引擎（支援ad-hoc臨時性的分析查詢）而Storm的架構和Spark截然相反。Storm是一個分布式StreamCompute引擎。每個節點實現一個基本的計算過程，而資料項目在互相串連的網路節點中流進流出。和Spark相反，這個是把資料傳遞給過程。兩個架構都用於處理大量資料的並行計算。Storm在動態處理大量產生的“小資料區塊”上要更好（比如在Twitter資料流上即時計算一些匯聚功能或分析）。Spark工作於現有的資料全集（如hadoop資料）已經被匯入Spark叢集，Spark基於in-memory管理可以進行快訊掃描，並最小化迭代演算法的全域I/O操作。不過Spark流模組（Streaming Module）倒是和Storm相類似（都是StreamCompute引擎），儘管並非完全一樣。Spark流模組先匯聚批量資料然後進行資料區塊分發（視作不可變資料進行處理），而Storm是只要接收到資料就即時處理並分發。不確定哪種方式在資料輸送量上要具優勢，不過Storm計算時間延遲要小。總結下，Spark和Storm設計相反，而Spark Steaming才和Storm類似，前者有資料平滑視窗（sliding window），而後者需要自己去維護這個視窗。

    另外，也可以從不同方面進行對比：

Spark streaming和Storm作為當今流行的即時資料流計算架構，已經在即時計算方案應用的非常廣泛了，其中spark streaming是基於spark的一個擴充，比storm的出現要晚一些。本章節從以下幾個角度對兩者進行了闡述，可以作為選型方面的一個參考。

A、 資料處理方式

Spark streaming是構建在spark上的即時資料流計算架構，利用時間批量視窗產生spark的計算輸入源RDD，後對該RDD產生Job，進行排隊調度到spark計算架構中執行，底層是基於spark資源調度和任務計算架構的；Spark streaming是基於資料的批處理方式，針對資料形成任務進行計算，是移動計算而不移動資料，而Storm恰恰相反，storm在處理架構上是資料流入到計算節點，移動的是資料而不是計算，對於時間視窗的批量資料處理，需要使用者自己來實現，這個在之前的storm系列的相關章節中有介紹。

B、 生態體系

Spark streaming是基於spark的，可以和spark其他的組件結合，實現互動查詢adhoc，機器學習MLib等。Storm相對來講，只是作為一個流式計算架構，缺乏現有的Hadoop生態體系的融合。

C、 延遲以及輸送量

Spark streaming基於對批量資料的處理，依賴spark的調度和計算架構，在延遲方面比storm要高，一般最小的延遲在2s左右，而storm可以達到100ms以內。正因為spark streaming是批處理的方式處理資料，整體的輸送量比較高。

D、 容錯性

Spark streaming通過lineage以及在記憶體維護兩份資料備份進行容錯，通過lineage記錄之前對RDD的操作，若某節點在運行時候出現故障，則可以通過備份資料在其他節點重新計算得到。

Storm通過ack組件進行資料流的跟蹤，開銷比sparking streaming要大。

E、  事務性

Spark streaming保證資料只被處理一次，並且是在批處理的層次層級。

Storm通過跟蹤機制能保證每個記錄至少被處理一次，如果需要保證狀態只更新一次的話，需要由使用者自己來實現。

所以對於statefull的計算，對事務性比較高的話，spark streaming要更好一些。