目錄：
一. 實時計算初期
二. 實時數倉建設
三. Lambda架構的實時數倉
四. Kappa架構的實時數倉
五. 流批結合的實時數倉
實時計算初期
雖然實時計算在最近幾年才火起來，但是在早期也有部分公司有實時計算的需求，但是資料量比較少，所以在實時方面形成不了完整的體系，基本所有的開發都是具體問題具體分析，來一個需求做一個，基本不考慮它們之間的關係，開發形式如下：
早期實時計算
如上圖所示，拿到資料來源後，會經過資料清洗，擴維，通過Flink進行業務邏輯處理，最後直接進行業務輸出。把這個環節拆開來看，資料來源端會重複引用相同的資料來源，後面進行清洗、過濾、擴維等操作，都要重複做一遍，唯一不同的是業務的程式碼邏輯是不一樣的。
隨著產品和業務人員對實時資料需求的不斷增多，這種開發模式出現的問題越來越多：
-
資料指標越來越多，“煙囪式”的開發導致程式碼耦合問題嚴重。
-
需求越來越多，有的需要明細資料，有的需要 OLAP 分析。單一的開發模式難以應付多種需求。
-
每個需求都要申請資源，導致資源成本急速膨脹，資源不能集約有效利用。
-
缺少完善的監控系統，無法在對業務產生影響之前發現並修復問題。
大家看實時數倉的發展和出現的問題，和離線數倉非常類似，後期資料量大了之後產生了各種問題，離線數倉當時是怎麼解決的？離線數倉通過分層架構使資料解耦，多個業務可以共用資料，實時數倉是否也可以用分層架構呢？當然是可以的，但是細節上和離線的分層還是有一些不同，稍後會講到。
實時數倉建設
從方法論來講，實時和離線是非常相似的，離線數倉早期的時候也是具體問題具體分析，當資料規模漲到一定量的時候才會考慮如何治理。分層是一種非常有效的資料治理方式，所以在實時數倉如何進行管理的問題上，首先考慮的也是分層的處理邏輯。
實時數倉的架構如下圖：
實時數倉架構
從上圖中我們具體分析下每層的作用：
-
資料來源：在資料來源的層面，離線和實時在資料來源是一致的，主要分為日誌類和業務類，日誌類又包括使用者日誌，埋點日誌以及伺服器日誌等。
-
實時明細層：在明細層，為了解決重複建設的問題，要進行統一構建，利用離線數倉的模式，建設統一的基礎明細資料層，按照主題進行管理，明細層的目的是給下游提供直接可用的資料，因此要對基礎層進行統一的加工，比如清洗、過濾、擴維等。
-
彙總層：彙總層通過Flink的簡潔運算元直接可以算出結果，並且形成彙總指標池，所有的指標都統一在彙總層加工，所有人按照統一的規範管理建設，形成可複用的彙總結果。
我們可以看出，實時數倉和離線數倉的分層非常類似，比如 資料來源層，明細層，彙總層，乃至應用層，他們命名的模式可能都是一樣的。但仔細比較不難發現，兩者有很多區別：
-
與離線數倉相比，實時數倉的層次更少一些：
-
從目前建設離線數倉的經驗來看，數倉的資料明細層內容會非常豐富，處理明細資料外一般還會包含輕度彙總層的概念，另外離線數倉中應用層資料在數倉內部，但實時數倉中，app 應用層資料已經落入應用系統的儲存介質中，可以把該層與數倉的表分離。
-
應用層少建設的好處：實時處理資料的時候，每建一個層次，資料必然會產生一定的延遲。
-
彙總層少建的好處：在彙總統計的時候，往往為了容忍一部分資料的延遲，可能會人為的製造一些延遲來保證資料的準確。舉例，在統計跨天相關的訂單事件中的資料時，可能會等到 00:00:05 或者 00:00:10 再統計，確保 00:00 前的資料已經全部接受到位了，再進行統計。所以，彙總層的層次太多的話，就會更大的加重人為造成的資料延遲。
-
-
與離線數倉相比，實時數倉的資料來源儲存不同：
- 在建設離線數倉的時候，基本整個離線數倉都是建立在 Hive 表之上。但是，在建設實時數倉的時候，同一份表，會使用不同的方式進行儲存。比如常見的情況下，明細資料或者彙總資料都會存在 Kafka 裡面，但是像城市、渠道等維度資訊需要藉助 Hbase，MySQL 或者其他 KV 儲存等資料庫來進行儲存。
Lambda架構的實時數倉
Lambda和Kappa架構的概念已在前文中解釋，不瞭解的小夥伴可點選連結：一文讀懂大資料實時計算
下圖是基於 Flink 和 Kafka 的 Lambda 架構的具體實踐，上層是實時計算，下層是離線計算，橫向是按計算引擎來分，縱向是按實時數倉來區分：
Lambda架構的實時數倉
Lambda架構是比較經典的架構，以前實時的場景不是很多，以離線為主，當附加了實時場景後，由於離線和實時的時效性不同，導致技術生態是不一樣的。Lambda架構相當於附加了一條實時生產鏈路，在應用層面進行一個整合，雙路生產，各自獨立。這在業務應用中也是順理成章採用的一種方式。
雙路生產會存在一些問題，比如加工邏輯double，開發運維也會double，資源同樣會變成兩個資源鏈路。因為存在以上問題，所以又演進了一個Kappa架構。
Kappa架構的實時數倉
Kappa架構相當於去掉了離線計算部分的Lambda架構，具體如下圖所示：
Kappa架構的實時數倉
Kappa架構從架構設計來講比較簡單，生產統一，一套邏輯同時生產離線和實時。但是在實際應用場景有比較大的侷限性，因為實時資料的同一份表，會使用不同的方式進行儲存，這就導致關聯時需要跨資料來源，運算元據有很大侷限性，所以在業內直接用Kappa架構生產落地的案例不多見，且場景比較單一。
關於 Kappa 架構，熟悉實時數倉生產的同學，可能會有一個疑問。因為我們經常會面臨業務變更，所以很多業務邏輯是需要去迭代的。之前產出的一些資料，如果口徑變更了，就需要重算，甚至重刷歷史資料。對於實時數倉來說，怎麼去解決資料重算問題？
Kappa 架構在這一塊的思路是：首先要準備好一個能夠儲存歷史資料的訊息佇列，比如 Kafka，並且這個訊息佇列是可以支援你從某個歷史的節點重新開始消費的。接著需要新起一個任務，從原來比較早的一個時間節點去消費 Kafka 上的資料，然後當這個新的任務執行的進度已經能夠和現在的正在跑的任務齊平的時候，你就可以把現在任務的下游切換到新的任務上面，舊的任務就可以停掉，並且原來產出的結果表也可以被刪掉。
流批結合的實時數倉
隨著實時 OLAP 技術的發展，目前開源的OLAP引擎在效能，易用等方面有了很大的提升，如Doris、Presto等，加上資料湖技術的迅速發展，使得流批結合的方式變得簡單。
如下圖是流批結合的實時數倉：
流批結合的實時數倉
資料從日誌統一採集到訊息佇列，再到實時數倉，作為基礎資料流的建設是統一的。之後對於日誌類實時特徵，實時大屏類應用走實時流計算。對於Binlog類業務分析走實時OLAP批處理。
我們看到流批結合的方式與上面幾種架構的儲存方式發生了變化，由Kafka換成了Iceberg，Iceberg是介於上層計算引擎和底層儲存格式之間的一箇中間層，我們可以把它定義成一種“資料組織格式”，底層儲存還是HDFS，那麼為什麼加了中間層，就對流批結合處理的比較好了呢？Iceberg的ACID能力可以簡化整個流水線的設計，降低整個流水線的延遲，並且所具有的修改、刪除能力能夠有效地降低開銷，提升效率。Iceberg可以有效支援批處理的高吞吐資料掃描和流計算按分割槽粒度併發實時處理。