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