實時計算數據架構的演變

傳統數據基礎架構
傳統單體數據架構最大的特色即是集中式數據存儲，大多數分爲計算層和存儲層。

存儲層，主要是負責存儲企業各類系統產生的數據，如 Web 業務系統、訂單系統、CRM 系統，ERP 系統、監控系統，數據好比系統的訂單交易量，網站的活躍用戶數，每一個用戶的交易額。
全部的操做均須要藉助於同一套數據庫實現。
單體架構初期效率很高，可是隨着時間的推移，業務愈來愈多，上線迭代很快。
但隨着後期業務愈來愈多，系統逐漸變的臃腫。數據庫變成了惟一準確的數據源，每一個應用都須要訪問數據庫來獲取對應的數據，若是數據庫發生改變或者出現問題，整個業務系統都會受到影響。

微服務架構
微服務將系統拆分紅不一樣的獨立服務模塊，每一個模塊有本身獨立的數據庫，不一樣的業務之間互相不干擾，微服務架構解決了業務系統拓展性的問題，可是隨之也帶來了新的問題。
就是業務數據過於分散在不一樣的系統中，很難將數據集中化管理。對於企業內部數據倉庫，數據挖掘之類的應用，須要把各個業務系統數據庫數據抽取到數據倉庫之中，在數據倉庫中進行數據的抽取、轉換、加載（ETL），從而構建不一樣的數據集市應用，提供給業務系統用。

大數據數據架構
起初，數據是構建在關係型數據庫之上，但隨着企業數據量的暴增，關係型數據庫已經沒法支撐起大規模數據集的存儲和分析，因而基於HADOOP構建企業級大數據平臺便成爲了共識。
後來，離線的高延遲漸漸的沒法知足企業需求，例如一些時間要求比較高的應用，實時報表統計，須要很是低的延時展現結果。爲此業界提出一套lambda架構方案來處理不一樣類型的數據。

包含了批量計算的 Batch Layer和實時計算的 Speed Layer，經過在一套平臺中，將批計算和流計算結合在一塊兒。
lambda 架構是構建大數據應用程序的一種頗有效的解決方案，但還不是最完美的方案

有狀態流式架構
數據產生的本質，實際上是一條條真實存在的事件，而前面講的不一樣的架構所用到的技術，如hadoop，spark，多少都在必定程度上違背了這種本質，須要在必定延時的狀況下對業務數據進行處理。
而有狀態的流計算架構，基於實時的流式數據，維護全部計算過程的狀態，所謂狀態就是計算過程當中產生的全部中間計算結果，每次計算新的數據進入到流式系統中都是基於中間狀態結果的基礎上進行計算，最終產生正確的統計結果。

這種架構好處是，不須要從原始數據從新從外部存儲中拿出來，從而進行全量計算；另外用戶也無需協調各類批量計算工具，從數據倉庫中獲取統計結果，而後再落地存儲，這些操做所有均可以基於流式操做來完成