傳統資料基礎架構
傳統單體資料架構最大的特點便是集中式資料儲存，大多數分為計算層和儲存層。

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

微服務架構
微服務將系統拆分成不同的獨立服務模組，每個模組有自己獨立的資料庫，不同的業務之間互相不干擾，微服務架構解決了業務系統拓展性的問題，但是隨之也帶來了新的問題。
就是業務資料過於分散在不同的系統中，很難將資料集中化管理。對於企業內部資料倉庫，資料探勘之類的應用，需要把各個業務系統資料庫資料抽取到資料倉庫之中，在資料倉庫中進行資料的抽取、轉換、載入（ETL），從而構建不同的資料集市應用，提供給業務系統用。

大資料資料架構
起初，資料是構建在關係型資料庫之上，但隨著企業資料量的暴增，關係型資料庫已經無法支撐起大規模資料集的儲存和分析，於是基於HADOOP構建企業級大資料平臺便成為了共識。
後來，離線的高延遲漸漸的無法滿足企業需求，例如一些時間要求比較高的應用，實時報表統計，需要非常低的延時展示結果。為此業界提出一套lambda架構方案來處理不同型別的資料。

包含了批量計算的 Batch Layer和實時計算的 Speed Layer，通過在一套平臺中，將批計算和流計算結合在一起。
lambda 架構是構建大資料應用程式的一種很有效的解決方案，但還不是最完美的方案

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

這種架構好處是，不需要從原始資料重新從外部儲存中拿出來，從而進行全量計算；另外使用者也無需協調各種批量計算工具，從資料倉庫中獲取統計結果，然後再落地儲存，這些操作全部都可以基於流式操作來完