Vol.1
實時數倉的發展
在早期也有部分公司有實時計算的需求，但是數據量比較少，所以在實時方面無法形成完整的體系，實時數倉更多是以實時計算的形式存在，作爲離線數倉的輔助，主要使用的技術也是Storm或Spark Streaming。基本所有的實時任務都是具體問題具體分析，來一個需求做一個，基本不考慮它們之間的關係。
【示圖：數倉開發模式】
隨着產品和業務人員對實時數據需求的不斷增多，這種開發模式出現的問題越來越多：
1
指標越來越多，“攤大餅”的開發導致代碼耦合問題嚴重。
2
需求越來越多，有的需要明細數據，有的需要 OLAP 分析。
3
每個需求都要申請資源，導致資源成本急速膨脹，資源不能集約有效利用。
4
容錯性低，由於是實時的數據處理，當線上環境出現問題或者要更新時，需要考慮如何確保數據不重不丟。
其實仔細分析這些問題，可以知道和離線數倉遇到的問題比較相似，數據量大了、作業多了之後產生了各種問題，離線數倉當時是怎麼解決的？離線數倉通過分層架構使數據解耦，多個業務可以共用數據，實時數倉是否也可以用分層架構呢？當然是可以的，但是細節上和離線的分層還是有一些不同。
Vol.2
實時數倉的建設
實時數倉建設的方法論也是和離線數倉比較相似，畢竟二者遇到的問題比較類似，早期也是來一個需求，開發一個作業，當規模起來之後就需要考慮治理的問題。而分層則是一個不錯的治理方式，通過合理的分層可以把不同粒度、不同來源的數據採用ER建模、維度建模的方式統一加工、清洗、彙總數據，形成基礎的數倉公共層，並根據下游業務部門的具體需求建設數倉應用層。既滿足了業務靈活多變的需求，又減少了重複建設導致的資源浪費和人力成本。
【示圖：實時數倉的分層架構】
1
●
ods貼源層
在貼源層，它的數據主要來自於上游的數據源，並和這些數據源保持一致，而數據源主要有來自業務的DB數據、程序服務的日誌、用戶的埋點數據和一些結構化數據。需要注意的是這些數據源都是可實時產生數據的流式數據通道，比如DB數據往往是來自MySQL binlog,Oracle Logminer等管道，而不是定時執行SQL去獲取一批數據的管道。
2
●
dwd明細層
在明細層，主要是爲了解決重複建設的問題，需要按照主題構建統一的基礎明細層，同時爲了給下游提供直接可用的數據，還需要對這些進行清洗、過濾和擴維。
3
●
dws彙總層
在彙總層，主要是對業務需求進行梳理得到共性維度、採用維度建模的方式建立明細寬表；同時對於一些固化統計需求，可以實現進行輕度彙總，形成彙總指標表，減輕下游的計算壓力，並形成可複用的結果。
從上面看出，實時數倉和離線數倉的分層非常相似，甚至連命名都是相同的。但仔細對比可以發現他們存在很大的不同。
1、與離線數倉相比，實時數倉的存儲是不同
在建立離線數倉時，整個存儲都是在建立在Hive上，但在實時數倉中，同一份表數據，可能會同時存儲在多個不同的地方，比如明細層、彙總層的數據會同時存放在Kafka和Hdfs中，但是像用戶信息這些維表數據則會藉助於MySQL、HBase或其他KV數據庫存儲。
2、與離線數倉相比，實時數倉的層次更少一些
從目前建設離線數倉的經驗來看，離線數倉中ads應用層數據一般是在數倉內部，但實時數倉中，ads 應用層數據已經落入應用系統的存儲介質中，可以把該層與數倉的表分離。
實時處理數據的時候，每建一個層次，數據必然會產生一定的延遲。舉例，在統計跨天相關的訂單事件中的數據時，可能會等到 00:00:05 或者 00:00:10 再統計，確保 00:00 前的數據已經全部接受到位了，再進行統計。所以，彙總層的層次太多的話，就會更大的加重人爲造成的數據延遲。
Vol.3
實時數倉的架構
目前大部分企業已經基於Hive搭建了自己的離線數倉，而離線數倉明顯無法滿足實時計算、實時查詢的需求，所以一般而言，爲了同時滿足實時和離線的需要，會採用經典的Lambda架構。Lambda架構的核心思想是把大數據系統拆分成三層：批量層，速度層和服務層。
1
批量層負責數據集存儲以及全量數據集的預查詢。
1
速度層主要負責對增量數據進行計算，生成實時的計算結構。
1
服務層用於響應用戶的查詢請求，它將離線計算層和實時計算層的結果進行合併，得到最後的結果，返回給用戶。
Lambda體系架構通過批處理層提供了高延遲的精度，而速度層提供了低延遲近似值。但同時Lambda架構也有相應的缺點，他需要對同樣的業務邏輯進行兩次編程：一次爲批量計算的系統，一次爲流程處理的系統，兩個系統走的是不同的計算代碼，最後處理的結構容易不一致。爲此有人提出了更先進的Kappa架構，不過由於目前的技術發展和篇幅原因，暫且不展開描述。
儘管Lambda架構有着上述缺點，仍然因爲它的可行性、擴展性和魯棒性，而被應用在各企業的數據倉庫中。
【示圖：實時數倉的一種架構設計】
上述是一個典型的Lambda架構，利用Flink強大的實時計算能力，大部分的數據處理可以交由Flink完成，而爲了數據的可靠性和容錯，還會將數據保存在HDFS內作爲備份，同時也可以供已有的離線數倉進行消費，減少離線任務的延時。在ads層則是根據業務需求可以將計算的結果存放不同的存儲查詢引擎中，比如藉助於數果自研的時序數據加速引擎Tindex可以對Kafka和HDFS構建聯合視圖，達到同時查詢實時和歷史數據的效果；藉助於數果的標籤分析引擎Uindex可以實現標籤數據的實時更新和實時查詢。
Vol.4
實時數倉的未來
隨着大數據技術的發展，特別是實時OLAP技術的迅速崛起，目前開源的OLAP引擎在性能，易用等方面有了很大的提升，如Doris、Presto等，加上數據湖技術的迅速發展，使得流批結合的方式變得簡單，可以簡化實時數倉的處理流程和架構設計。
【示圖：流批結合的實時數倉】
數據從日誌統一採集到消息隊列，再到實時數倉，作爲基礎數據流的建設是統一的。之後對於日誌類實時特徵，實時大屏類應用走實時流計算。對於Binlog類業務分析走實時OLAP批處理。
可以看到引入數據湖之後（圖中的Hudi/Iceberg，可以簡單理解爲一種數據格式，本質上還是存儲在HDFS），實時數倉在計算引擎和底層存儲引入了一箇中間層——數據湖，同時基於數據湖的ACID能力，可以解決傳統離線數倉不支持高效修改的痛點，同時也簡化了整體數據流水線處理的過程，降低了整個處理的延遲。但是目前數據湖的發展不是太成熟，相應的生態支持也比較少，所以應用的不多，不過社區比較活躍，而且大家也都看到了數據湖在數倉中的潛力，在日後應該會在實時數倉中佔有一席之地。