在傳統的數據處理流程中，總是先收集數據，然後將數據放到DB中。當人們需要的時候通過DB對數據做query，得到答案或進行相關的處理。這樣看起來雖然非常合理，但是結果卻非常的緊湊，尤其是在一些實時搜尋套用環境中的某些具體問題，類似於MapReduce方式的離線處理並不能很好地解決問題。這就引出了一種新的數據計算結構---流計算方式。它可以很好地對大規模流動數據在不斷變化的運動過程中實時地進行分析，捕捉到可能有用的信息，並把結果傳送到下一計算節點。
基本介紹
- 中文名：流式計算
- 技術：stream computing
- 早期代表系統：IBM的System S
- 類別：系統
內容,套用,
內容
比較早期代表系統有IBM的System S，它是一個完整的計算架構，通過“stream computing”技術，可以對stream形式的數據進行real-time的分析。“最初的系統擁有大約800個微處理器，但IBM稱，根據需求，這個數字也有可能上萬。研究者講到，其中最關鍵的部分是System S軟體，它可以將任務分開，比如分為圖像識別和文本識別，然後將處理後的結果碎片組成完整的答案。IBM實驗室高性能流運算項目的負責人Nagui Halim談到：System S是一個全新的運算模式，它的靈活性和速度頗具優勢。而與傳統系統相比，它的方式更加智慧型化，可以適當轉變，以適用其需要解決的問題。
商用搜尋引擎，像Google、Bing和Yahoo!等，通常在用戶查詢回響中提供結構化的Web結果，同時也插入基於流量的點擊付費模式的文本廣告。為了在頁面上最佳位置展現最相關的廣告，通過一些算法來動態估算給定上下文中一個廣告被點擊的可能性。上下文可能包括用戶偏好、地理位置、歷史查詢、歷史點擊等信息。一個主搜尋引擎可能每秒鐘處理成千上萬次查詢，每個頁面都可能會包含多個廣告。為了及時處理用戶反饋，需要一個低延遲、可擴展、高可靠的處理引擎。然而，對於這些實時性要求很高的套用，儘管MapReduce作了實時性改進，但仍很難穩定地滿足套用需求。因為Hadoop為批處理作了高度最佳化，MapReduce系統典型地通過調度批量任務來操作靜態數據；而流式計算的典型範式之一是不確定數據速率的事件流流入系統，系統處理能力必須與事件流量匹配，或者通過近似算法等方法優雅降級，通常稱為負載分流（load-shedding）。當然，除了負載分流，流式計算的容錯處理等機制也和批處理計算不盡相同。
有人會說，MR也有自己的實時計算方案，比如說HOP。
但是，這類基於MapReduce進行流式處理的方案有三個主要缺點。
- 將輸入數據分隔成固定大小的片段，再由MapReduce平台處理，缺點在於處理延遲與數據片段的長度、初始化處理任務的開銷成正比。小的分段會降低延遲，增加附加開銷，並且分段之間的依賴管理更加複雜（例如一個分段可能會需要前一個分段的信息）；反之，大的分段會增加延遲。最優的分段大小取決於具體套用。
- 為了支持流式處理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接輸出；考慮到效率，中間結果最好只保存在記憶體中等。這些改動使得原有的MapReduce框架的複雜度大大增加，不利於系統的維護和擴展。
- 用戶被迫使用MapReduce的接口來定義流式作業，這使得用戶程式的可伸縮性降低。
綜上所述，流式處理的模式決定了要和批處理使用非常不同的架構，試圖搭建一個既適合流式計算又適合批處理計算的通用平台，結果可能會是一個高度複雜的系統，並且最終系統可能對兩種計算都不理想。
目前流式計算是業界研究的一個熱點，最近Twitter、LinkedIn等公司相繼開源了流式計算系統Storm、Kafka等，加上Yahoo!之前開源的S4，流式計算研究在網際網路領域持續升溫。不過流式計算並非最近幾年才開始研究，傳統行業像金融領域等很早就已經在使用流式計算系統，比較知名的有StreamBase、Borealis等。
套用
流運算在內容方面，主要面向以下幾種套用：對金融與科學計算當中的數據進行更快運算和分析的需求；對存在於社交網站、部落格、電子郵件、視頻、新聞、電話記錄、傳輸數據、電子感應器之中的數字格式的信息流進行快速處理並反饋的需求。
