處理實時的大數據流最常用的就是分布式計算系統，下面分別介紹Apache中處理大數據流的三大框架:
- Apache Storm
這是一個分布式實時大數據處理系統。Storm設計用於在容錯和水平可擴展方法中處理大量數據。他是一個流數據框架，具有最高的社區率。雖然Storm是無狀態的，它通過ApacheZooKeeper管理分布式環境和雞群狀態。使用起來非常簡單，並且還支持並行地對實時數據執行各種操作。
Apache Storm繼續成為實時數據分析的領導者是因為它的易於操作和設置，並且它保證每個消息將通過拓撲至少處理一次。使用storm時常常會設計一個用於實時計算的土狀結構，稱之為拓撲（topplogy）。將這個拓撲提交給集群之后，集群中的主控節點（master node）將分發代碼，將任務分配給工作節點（worker node）。拓撲結構中履行職能的角色有兩種：spout和bolt，其中spout發送消息，負責將數據流以tuple元組（不可變數組，固定的鍵值對）的形式發送出去；bolt則負責轉換這些數據流，在bolt中可以完成計算、過濾等操作，bolt之間也可以隨機互相發送消息。
下面是Storm的集群設計和其內部架構。
Twitter使用Storm框架處理流式大數據的應用場景：
Twitter分析的輸入來自Twitter Streaming API。Spout將使用Twitter Streaming API讀取用戶的tweets，並作為元組流輸出。來自spout的單個元組將具有twitter用戶名和單個tweet作為逗號分隔值。然后，這個元組的蒸汽將被轉發到Bolt，並且Bolt將tweet拆分成單個字，計算字數，並將信息保存到配置的數據源。現在，我們可以通過查詢數據源輕松獲得結果。
Apache Storm vs Hadoop
基本上Hadoop和Storm框架用於分析大數據。兩者互補，在某些方面有所不同。Apache Storm執行除持久性之外的所有操作，而Hadoop在所有方面都很好，但滯后於實時計算。下表比較了Storm和Hadoop的屬性。
| Storm | Hadoop |
|---|---|
| 實時流處理 | 批量處理 |
| 無狀態 | 有狀態 |
| 主/從架構與基於ZooKeeper的協調。主節點稱為nimbus，從屬節點是主管。 | 具有/不具有基於ZooKeeper的協調的主 - 從結構。主節點是作業跟蹤器，從節點是任務跟蹤器。 |
| Storm流過程在集群上每秒可以訪問數萬條消息。 | Hadoop分布式文件系統（HDFS）使用MapReduce框架來處理大量的數據，需要幾分鍾或幾小時。 |
| Storm拓撲運行直到用戶關閉或意外的不可恢復故障。 | MapReduce作業按順序執行並最終完成。 |
| 兩者都是分布式和容錯的 | |
| 如果nimbus / supervisor死機，重新啟動使它從它停止的地方繼續，因此沒有什么受到影響。 | 如果JobTracker死機，所有正在運行的作業都會丟失。 |
使用Apache Storm的例子
Apache Storm對於實時大數據流處理非常有名。因此，大多數公司都將Storm用作其系統的一個組成部分。一些值得注意的例子如下 -
Twitter - Twitter正在使用Apache Storm作為其“發布商分析產品”。 “發布商分析產品”處理Twitter平台中的每個tweets和點擊。 Apache Storm與Twitter基礎架構深度集成。
NaviSite - NaviSite正在使用Storm進行事件日志監控/審計系統。系統中生成的每個日志都將通過Storm。Storm將根據配置的正則表達式集檢查消息，如果存在匹配，那么該特定消息將保存到數據庫。
Wego - Wego是位於新加坡的旅行元搜索引擎。旅行相關數據來自世界各地的許多來源，時間不同。Storm幫助Wego搜索實時數據，解決並發問題，並為最終用戶找到最佳匹配。
Apache Storm優勢
Storm優勢就在於Storm是實時的連續性的分布式計算框架，一旦運行起來，除非你將它殺掉，否則將一直Strom一直處於處理計算或者等
待計算的狀態，這一點Spark和hadoop都做不到。但是這些框架各有各的優點，每種框架都有自己的最佳應用場景。Storm是最佳的流式計算框架，Storm由Java和Clojure寫成，Storm的優點是全內存計算，所以它的定位是分布式實時計算系統，按照Storm作者的說法，Storm對於實時計算的意義類似於Hadoop對於批處理的意義。
Storm的適用場景：
1）流數據處理
Storm可以用來處理源源不斷流進來的消息，處理之后將結果寫入到某個存儲中去。
2）分布式RPC。由於Storm的處理組件是分布式的，而且處理延遲極低，所以可以作為一個通用的分布式RPC框架來使用。
1）流數據處理
Storm可以用來處理源源不斷流進來的消息，處理之后將結果寫入到某個存儲中去。
2）分布式RPC。由於Storm的處理組件是分布式的，而且處理延遲極低，所以可以作為一個通用的分布式RPC框架來使用。
- Apache Spark
Spark Streaming是核心Spark API的一個擴展，它並不會像Storm那樣一次一個地處理數據流，而是在處理前按時間間隔預先將其切分為一段一段的批處理作業。Spark針對持續性數據流的抽象稱為DStream（DiscretizedStream），一個DStream是一個微批處理（micro-batching）的RDD（彈性分布式數據集）；而RDD則是一種分布式數據集，能夠以兩種方式並行運作，分別是任意函數和滑動窗口數據的轉換。
Spark提交作業的方式有兩種：
- Apache Samza
Samza處理數據流時，會分別按次處理每條收到的消息。Samza的流單位既不是元組，也不是Dstream，而是一條條消息。在Samza中，數據流被切分開來，每個部分都由一組只讀消息的有序數列構成，而這些消息每條都有一個特定的ID（offset）。該系統還支持批處理，即逐次處理同一個數據流分區的多條消息。Samza的執行與數據流模塊都是可插拔式的，盡管Samza的特色是依賴Hadoop的Yarn（另一種資源調度器）和Apache Kafka。
- 三種框架的比較：
共同之處：
以上三種實時計算系統都是開源的分布式系統，具有低延遲、可擴展和容錯性諸多優點，它們的共同特色在於：允許你在運行數據流代碼時，將任務分配到一系列具有容錯能力的計算機上並行運行。此外，它們都提供了簡單的API來簡化底層實現的復雜程度。
不同之處:
從應用的角度來分析,:
如果你想要的是一個允許增量計算的高速事件處理系統，Storm會是最佳選擇。它可以應對你在客戶端等待結果的同時，進一步進行分布式計算的需求，使用開箱即用的分布式RPC（DRPC）就可以了。最后但同樣重要的原因：Storm使用Apache Thrift，你可以用任何編程語言來編寫拓撲結構。
如果你需要狀態持續，同時/或者達到恰好一次的傳遞效果，應當看看更高層面的Trdent API，它同時也提供了微批處理的方式。