關於計算有很多名詞，比如實時計算、分布式計算，以及這裡提到流式計算等等。他們是從計算形勢的不同維度來描述，不必爭議孰優孰劣。流式計算主要從資料的形態來定義的一種計算方式，顧名思義，這種資料如流水一般，沒有終點。乙個有爭議的特徵的是，流式資料之間是否具有時序性，我贊同流式資料之間應該假定為具有時序性，並由此引申出，計算是有狀態的，具有上下文關係。雖然可以通過各種手段，將狀態依賴降到零，或者某些場景下，資料之間就沒有關聯絡；但假定流式資料是有狀態的，更具普適性，因為無狀態實際上可以視為狀態為零的一種特例。
和流式計算相對應的，是資料庫。我們將資料庫的處理流程分解一下，可以發現，每個資料庫連線持續傳送sql語句到dbms，dbms執行sql語句，再到儲存引擎，並最終持久化到硬碟。sql語句包含了增刪改和查詢。連線和連線之間可以沒有相關性，但乙個連線內部是有時序性，比如事務，甚至sql語句前後之間也是有依賴的。
流式計算和資料庫在流程上相似度很高，除了流式計算不要求最終如何儲存。但是追溯流式計算概念的提出，本身是為了解決大資料場景下，資料處理的實時性問題。換句話說，是為了解決資料庫無法達到的時效問題，因此，兩者之間有很高的相似度，也不足為奇。在發展之初，流式計算框架主要是在hadoop等大資料批處理系統的基礎上，通過縮短批處理的視窗，來提高響應速度。和批處理的大資料分析系統相比，響應速度是有提高，但還是離不開批處理的基因，應用場景還是在秒級範疇，但因為加上大資料分析的加持，比如推薦系統中，已經足夠好的。因此，流式計算的擁護者眾多。
如果我們重新審視下流式計算，我們會發現流式計算主要包含了四個部分，其一是流式資料本身；其二是計算邏輯；其三是計算過程中需要引用的資料；其四是計算結果，計算結果可能會成為乙個新的流式資料**。對流式計算實時性影響最大的是引用資料需要的時間，因為引用可能涉及到外部儲存，顯然這塊的速度是無法和直接在記憶體中計算相比的。在理想情況下，如果沒有引用資料，那麼就能夠大幅度提高響應速度。但畢竟是特殊場景，與業務有關，不具備普適性。在有些場景下，即使有引用資料，但是能夠被預處理，或者轉換為無引用資料，那也是乙個很好的解決方案。
對實時性還有乙個隱藏的影響因素，是流資料的時序性，他有計算結果的依賴性，也就是上下文相關。比如常用來作例子的存款餘額，以及每年都要挨罵的12306**的餘票問題。究其根本，是後續的計算結果依賴於前乙個資料的計算結果，不能並行處理，因此就增加了等待時間。
在乙個資料規模大，實時性要求高的業務場景下，光依賴於硬體條件是有上限的。而且我們上面也說到過，資料引用和時序依賴是計算時延的關鍵因素。因此，分而劃之，提高整體的計算並行度是乙個合理的策略，這樣將上下文關聯降到最低；同時，將需要引用的資料置於記憶體中，或者將計算所需要引用的資料和流資料預處理合併在一起，就不需要在計算時在去等待外部資料，降低引用資料所需要的時間。
資料親和架構 緣起
資料親和架構並沒有否定其他架構，尤其是微服務架構的合理性，而是從另外乙個視角來重新審視整個架構，做出補充。讓資料和業務邏輯具備更強的親和性，故命名為資料親和。微服務架構提出了乙個理念，每個服務劃分成更細粒度的服務單元。每個單元的職能更加單一，降低了服務單元的複雜度和耦合性，但它同時增加系統整體複雜度...
資料親和架構 資料同步
資料親和架構核心要解決資料和程式的繫結問題，那麼資料在程序間同步就尤為重要。因為效能的關係，增量同步是首選，全量同步只有在初始化或者出現異常的情況下，才會考慮。在流資料中，因為有時序，比較容易實現，而在靜態資料中，比如檔案或者資料庫中，通常沒有嚴格的時序，只有快照，要做增量比較困難。以物理時間流動為...
大資料架構中的流式架構和Kappa架構
1.流式架構 流式架構在大資料中應用十分廣泛，在傳統大資料架構的基礎上，流式架構非常激進，直接取消了批處理操作，資料全程以資料流的方式進行處理，所以在資料接入端沒有了etl操作，轉而替換為資料通道。而流式架構的優點十分明顯，流式架構的優點就是沒有十分麻煩的etl過程，資料的實效性非常高。當然，流式架...