隨著實時資料的增加，對實時資料流的需求也在增長。更不用說，流技術正在引領大資料世界。使用更新的實時流**平台，使用者選擇乙個平台變得很複雜。apache storm和spark是該列表中最流行的兩種實時技術。
讓我們根據它們的功能比較apache storm和spark，並幫助使用者做出選擇。本文的目的是apache storm vs與apache spark無關，不是要對兩者進行判斷，而是要研究兩者之間的異同。
要了解spark vs storm，讓我們首先了解兩者的基礎！
apache storm是乙個開源，容錯，可擴充套件的實時流處理計算系統。它是實時分布式資料處理的框架。它著重於事件處理或流處理。storm實現了一種容錯機制來執行計算或排程事件的多個計算。apache storm基於流和元組。
apache spark是用於集群計算的閃電般的快速大資料技術框架。它旨在對大型資料集進行快速計算。它是用於分布式處理的引擎，但沒有內建的分布式儲存系統和資源管理器。需要插入自己選擇的儲存系統和集群資源管理器。
apache yarn或mesos可用於群集管理器，而google cloud storage，microsoft azure，hdfs（hadoop分布式檔案系統）和amazon s3可用於資源管理器。
在這裡，我們將解釋實時處理工具（例如apache spark和apache storm）之間在功能方面的區別。讓我們逐一檢視每個功能，以比較apache storm與apache spark。這將幫助我們學習並決定根據該特定功能採用哪種更好的方法。
apache spark和apache storm框架在相同程度上具有容錯能力。
至少一次
最多一次
恰好一次
storm擅長於動態處理大量實時生產的小資料塊，概念上是將小資料量的資料源源不斷傳給過程；
spark擅長對現有的資料全集做處理，概念是將過程傳給大資料量的資料。
二者設計思路相反。storm側重於處理的實時性，spark側重處理龐大資料（類似於hadoop的mr）。
spark流模組(spark streaming)與storm類似，但有區別：
1.storm純實時，來一條資料，處理一條資料；sparkstreaming準實時，對乙個時間段內的資料收集起來，作為乙個rdd，再做處理。
2.storm響應時間毫秒級；spark streaming響應時間秒級
3.storm可以動態調整並行度；sparkstreaming不行
storm應用場景：
1、對於需要純實時，不能忍受1秒以上延遲的場景
2、要求可靠的事務機制和可靠性機制，即資料的處理完全精準
3、如果還需要針對高峰低峰時間段，動態調整實時計算程式的並行度，以最大限度利用集群資源
spark streaming應用場景：
1、spark streaming可以和spark core、spark sql無縫整合，如果乙個專案除了實時計算之外，還包括了離線批處理、互動式查詢等業務功能，考慮使用spark streaming。
關於apache storm vs和apache spark的研究得出的結論是，這兩者都提供了它們的應用程式母版和最佳解決方案，以解決轉換問題和流式傳輸。apache storm提供了解決實時資料流問題的快速解決方案。storm只能解決流處理問題。而且，由於資源有限，很難建立storm應用程式。
但是，行業中始終需要能夠解決與流處理，批處理，迭代處理以及互動處理相關的所有問題的通用解決方案。apache spark可以解決許多態別的問題。這就是為什麼技術專業人員和開發人員對spark有巨大需求的原因。
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...