內容
比較早期代表系統有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等。
套用
流運算在內容方面，主要面向以下幾種套用：對金融與科學計算當中的數據進行更快運算和分析的需求；對存在於社交網站、部落格、電子郵件、視頻、新聞、電話記錄、傳輸數據、電子感應器之中的數字格式的信息流進行快速處理並反饋的需求。
