對spark、storm以及spark streaming引擎的簡明扼要、深入淺出的比較，原文發表於踏得網。
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基於這樣的理念，當資料龐大時，把計算過程傳遞給資料要比把資料傳遞給計算過程要更富效率。每個節點儲存 或快取 它的資料集，然後任務被提交給節點。所以這是把過程傳遞給資料。這和hadoop map reduce非常相似，除了積極使用記憶體來避免 i o操作，以使得迭代演算法 前一步計算輸...
平行計算效能分析
第乙個效能當然是速度，還有兩個 延時 完成指定工作所需要的時間 吞吐率 單位時間內完成的工作量 開發並行性通常能改進吞吐率。開發並行可以隱藏延時，當然並沒有真正的減少延時，只是隱藏了延時的代價，因為它 與其等待，不如去計算其餘部分 平行計算比序列計算要建立更多執行緒而帶來額外開銷，建立程序的開銷遠大...
平行計算和MapReduce
參考 現在mapreduce hadoop以及相關的資料處理技術非常熱，因此我想在這裡將mapreduce的優勢彙總一下，將mapreduce與傳統基於hpc集群的平行計算模型做乙個簡要比較，也算是對前一陣子所學的mapreduce知識做乙個總結和梳理。隨著網際網路資料量的不斷增長，對處理資料能力的...