關於計算有很多名詞，比如實時計算、分散式計算，以及這裡提到流式計算等等。他們是從計算形勢的不同維度來描述，不必爭議孰優孰劣。流式計算主要從資料的形態來定義的一種計算方式，顧名思義，這種資料如流水一般，沒有終點。一個有爭議的特徵的是，流式資料之間是否具有時序性，我贊同流式資料之間應該假定為具有時序性，並由此引申出，計算是有狀態的，具有上下文關係。雖然可以通過各種手段，將狀態依賴降到零，或者某些場景下，資料之間就沒有關聯絡；但假定流式資料是有狀態的，更具普適性，因為無狀態實際上可以視為狀態為零的一種特例。

        和流式計算相對應的，是資料庫。我們將資料庫的處理流程分解一下，可以發現，每個資料庫連線持續傳送SQL語句到DBMS，DBMS執行SQL語句，再到儲存引擎，並最終持久化到硬碟。SQL語句包含了增刪改和查詢。連線和連線之間可以沒有相關性，但一個連線內部是有時序性，比如事務，甚至SQL語句前後之間也是有依賴的。

        流式計算和資料庫在流程上相似度很高，除了流式計算不要求最終如何儲存。但是追溯流式計算概念的提出，本身是為了解決大資料場景下，資料處理的實時性問題。換句話說，是為了解決資料庫無法達到的時效問題，因此，兩者之間有很高的相似度，也不足為奇。在發展之初，流式計算框架主要是在Hadoop等大資料批處理系統的基礎上，通過縮短批處理的視窗，來提高響應速度。和批處理的大資料分析系統相比，響應速度是有提高，但還是離不開批處理的基因，應用場景還是在秒級範疇，但因為加上大資料分析的加持，比如推薦系統中，已經足夠好的。因此，流式計算的擁護者眾多。

        如果我們重新審視下流式計算，我們會發現流式計算主要包含了四個部分，其一是流式資料本身；其二是計算邏輯；其三是計算過程中需要引用的資料；其四是計算結果，計算結果可能會成為一個新的流式資料來源。對流式計算實時性影響最大的是引用資料需要的時間，因為引用可能涉及到外部儲存，顯然這塊的速度是無法和直接在記憶體中計算相比的。在理想情況下，如果沒有引用資料，那麼就能夠大幅度提高響應速度。但畢竟是特殊場景，與業務有關，不具備普適性。在有些場景下，即使有引用資料，但是能夠被預處理，或者轉換為無引用資料，那也是一個很好的解決方案。

        對實時性還有一個隱藏的影響因素，是流資料的時序性，他有計算結果的依賴性，也就是上下文相關。比如常用來作例子的存款餘額，以及每年都要捱罵的12306網站的餘票問題。究其根本，是後續的計算結果依賴於前一個數據的計算結果，不能並行處理，因此就增加了等待時間。

        在一個數據規模大，實時性要求高的業務場景下，光依賴於硬體條件是有上限的。而且我們上面也說到過，資料引用和時序依賴是計算時延的關鍵因素。因此，分而劃之，提高整體的計算並行度是一個合理的策略，這樣將上下文關聯降到最低；同時，將需要引用的資料置於記憶體中，或者將計算所需要引用的資料和流資料預處理合並在一起，就不需要在計算時在去等待外部資料，降低引用資料所需要的時間。