來自
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），而後者需要自己去維護這個視窗。
高效能平行計算引擎Storm和Spark比較
對spark storm以及spark streaming引擎的簡明扼要 深入淺出的比較，原文發表於踏得網。spark基於這樣的理念，當資料龐大時，把計算過程傳遞給資料要比把資料傳遞給計算過程要更富效率。每個節點儲存 或快取 它的資料集，然後任務被提交給節點。所以這是把過程傳遞給資料。這和hadoo...
平行計算效能分析
第乙個效能當然是速度，還有兩個 延時 完成指定工作所需要的時間 吞吐率 單位時間內完成的工作量 開發並行性通常能改進吞吐率。開發並行可以隱藏延時，當然並沒有真正的減少延時，只是隱藏了延時的代價，因為它 與其等待，不如去計算其餘部分 平行計算比序列計算要建立更多執行緒而帶來額外開銷，建立程序的開銷遠大...
平行計算的效能指標
定義序列程式執行時間為t序列，並行程式執行時間為t並行，則加速比 speedup 是 s t並行 t序列。當加速比 s 等於平行計算的核數 p，則稱該並行程式具有線性加速比 linear speedup 實際上，我們不可能獲得線性加速比，因為多個執行緒 程序總是會引入一些代價。此外，定義 e s p...