當前有許多分散式計算系統能夠實時處理大資料，這篇文章是對Apache的三個框架進行比較，試圖提供一個快速的高屋建瓴地異同性總結。

Apache Storm

　　在Storm中，你設計的實時計算圖稱為toplogy，將其以叢集方式執行，其主節點會在工作節點之間分發程式碼並執行，在一個topology中，資料是在spout之間傳遞，它發射資料流作為不可變的key-value匹配集合，這種key-value配對值稱為tuple，bolt是用來轉換這些流如count計數或filter過濾等，bolt它們自己也可選擇發射資料到其它流處理管道下游的bolt。

Apache Spark

Apache Samza

　　Samza 的目標是將流作為接受到的訊息處理，同時，Samza的流初始元素並不是一個tuple或一個DStream，而是一個訊息，流被劃分到分割槽，每個分割槽是一個只讀訊息的排序的序列，每個訊息有一個唯一的ID(offset)，系統也支援批處理，從同樣的流分割槽以順序消費幾個訊息，儘管Samza主要是依賴於Hadoop的Yarn和Apache Kafka，但是它的Execution & Streaming模組是可插拔的。

共同點

　　這三個實時計算系統都是開源的，低延遲的，分散式的，可擴充套件的和容錯的，他們都允許你在有錯誤恢復的叢集中通過並行任務執行流處理程式碼，他們也提供簡單的API抽象底層和複雜的實現。

這三個框架使用不同的詞彙表達相似的概念：

不同點

不同點總結如下表：

有三個delivery模式：

• At-most-once: 訊息也許丟失，這通常是最不理想的結果。
• At-least-once: 訊息可以被退回（沒有損失，但是會重複），這足夠支援很多用例場景了。
• Exactly-once: 每個訊息只傳遞一次，也只有一次(不會丟失，無重複)，這是一個理想功能，在所有情況下很難達到。

另外一個方面是狀態管理，有許多不同的策略來儲存狀態，Spark Streaming寫資料到分散式檔案系統如HDFS，而Samza使用一個嵌入的key-value儲存，Storm則或在應用層使用自己的狀態管理，或使用一個高層次抽象稱為：Trident.

使用場景

　　所有這三個框架都特別適合處理連續的大量的實時資料，那麼選擇哪一個呢？並沒有硬性規則，基本是通用的指南。

　　如果你想要一個高速事件流處理系統，能夠進行增量計算，那麼Storm將非常適合，如果你還需要按需執行分散式計算，而客戶端正在同步等待結果，那麼你得在其外面使用分散式RPC(DRPC)，最後但並非最不重要的是：因為Storm使用Apache Thrift，你能以任何語言編寫拓撲topology，如果你需要狀態持久或exactly-once傳遞，那麼你應當看看高級別的Trident API，它也提供微批處理(micro-batching)

　　使用Storm的公司有 Twitter, Yahoo!, Spotify, The Weather Channel...

　　談到微批處理，如果你必須有有態計算，exactly-once傳遞和不介意高延遲，你可以考慮Spark Streaming，特別如果計劃實現圖操作，機器學習或訪問SQL，Apache Spark能讓你通過結合Spark SQL, MLlib, GraphX幾個庫包實現，這些提供方便的統一的程式設計模型，特別是流演算法如流k-means允許Spark實時進行決策。

　　使用Spark有：Amazon, Yahoo!, NASA JPL, eBay Inc., Baidu

　　如果你有大量的狀態，比如每個分割槽有很多G位元組，Samza協同儲存和在同一機器處理的模型能讓你有效處理狀態，且不會塞滿記憶體。這個框架提供靈活的可插拔API：它的預設execution 訊息和儲存引擎能夠被你喜歡的選擇替代，更有甚者，如果你有很多流處理過程，它們分別來自於不同的程式碼庫不同的團隊，Samza細粒度的工作特點將特別適合，因為它們能最小的影響來進行加入和移除。

　　使用Samza公司有：LinkedIn, Intuit, Metamarkets, Quantiply, Fortscale…