一、流式計算的背景
在日常生活中，我們通常會先把數據存儲在一張表中，然後再進行加工、分析，這裏就涉及到一個時效性的問題。如果我們處理以年、月爲單位的級別的數據，那麼多數據的實時性要求並不高；但如果我們處理的是以天、小時，甚至分鐘爲單位的數據，那麼對數據的時效性要求就比較高。在第二種場景下，如果我們仍舊採用傳統的數據處理方式，統一收集數據，存儲到數據庫中，之後在進行分析，就可能無法滿足時效性的要求。
二、流式計算與批量計算
大數據的計算模式主要分爲批量計算(batch computing)、流式計算(stream computing)、交互計算(interactive computing)、圖計算(graph computing)等。其中，流式計算和批量計算是兩種主要的大數據計算模式，分別適用於不同的大數據應用場景。
流數據（或數據流）是指在時間分佈和數量上無限的一系列動態數據集合體，數據的價值隨着時間的流逝而降低，因此必須實時計算給出秒級響應。流式計算，顧名思義，就是對數據流進行處理，是實時計算。批量計算則統一收集數據，存儲到數據庫中，然後對數據進行批量處理的數據計算方式。主要體現在以下幾個方面：
1、數據時效性不同：流式計算實時、低延遲， 批量計算非實時、高延遲。
2、數據特徵不同：流式計算的數據一般是動態的、沒有邊界的，而批處理的數據一般則是靜態數據。
3、應用場景不同：流式計算應用在實時場景，時效性要求比較高的場景，如實時推薦、業務監控...批量計算一般說批處理，應用在實時性要求不高、離線計算的場景下，數據分析、離線報表等。
4、運行方式不同，流式計算的任務持續進行的，批量計算的任務則一次性完成。
三、流式計算框架、平臺與相關產品
第一類，商業級流式計算平臺（IBM InfoSphere Streams、IBM StreamBase等）；
第二類，開源流式計算框架（Twitter Storm、S4等）；
第三類，公司爲支持自身業務開發的流式計算框架。
Strom：Twitter 開發的第一代流處理系統。
Heron：Twitter 開發的第二代流處理系統。
Spark streaming：是Spark核心API的一個擴展，可以實現高吞吐量的、具備容錯機制的實時流數據的處理。
Flink：是一個針對流數據和批數據的分佈式處理引擎。
Apache Kafka：由Scala寫成。該項目的目標是爲處理實時數據提供一個統一、高通量、低等待的平臺。
四、流式計算主要應用場景
流式處理可以用於兩種不同場景： 事件流和持續計算。
1、事件流
事件流具能夠持續產生大量的數據，這類數據最早出現與傳統的銀行和股票交易領域，也在互聯網監控、無線通信網等領域出現、需要以近實時的方式對更新數據流進行復雜分析如趨勢分析、預測、監控等。簡單來說，事件流採用的是查詢保持靜態，語句是固定的，數據不斷變化的方式。
2、持續計算
比如對於大型網站的流式數據：網站的訪問PV/UV、用戶訪問了什麼內容、搜索了什麼內容等，實時的數據計算和分析可以動態實時地刷新用戶訪問數據，展示網站實時流量的變化情況，分析每天各小時的流量和用戶分佈情況；
比如金融行業，毫秒級延遲的需求至關重要。一些需要實時處理數據的場景也可以應用Storm，比如根據用戶行爲產生的日誌文件進行實時分析，對用戶進行商品的實時推薦等。
五、流式計算的價值
通過大數據處理我們獲取了數據的價值，但是數據的價值是恆定不變的嗎？顯然不是，一些數據在事情發生後不久就有了更高的價值，而且這種價值會隨着時間的推移而迅速減少。流處理的關鍵優勢在於它能夠更快地提供洞察力，通常在毫秒到秒之間。
流式計算的價值在於業務方可在更短的時間內挖掘業務數據中的價值，並將這種低延遲轉化爲競爭優勢。比方說，在使用流式計算的推薦引擎中，用戶的行爲偏好可以在更短的時間內反映在推薦模型中，推薦模型能夠以更低的延遲捕捉用戶的行爲偏好以提供更精準、及時的推薦。
流式計算能做到這一點的原因在於，傳統的批量計算需要進行數據積累，在積累到一定量的數據後再進行批量處理；而流式計算能做到數據隨到隨處理，有效降低了處理延時。