數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。
數據倉庫概念是Inmon於1990年提出並給出了完整的建設方法。隨着互聯網時代來臨，數據量暴增，開始使用大數據工具來替代經典數倉中的傳統工具。此時僅僅是工具的取代，架構上並沒有根本的區別，可以把這個架構叫做離線大數據架構。
后來隨着業務實時性要求的不斷提高，人們開始在離線大數據架構基礎上加了一個加速層，使用流處理技術直接完成那些實時性要求較高的指標計算，這便是Lambda架構。
再后來，實時的業務越來越多，事件化的數據源也越來越多，實時處理從次要部分變成了主要部分，架構也做了相應調整，出現了以實時事件處理為核心的Kappa架構。
數據倉庫模型架構
數據倉庫的建設主要包括數據的采集、數據的處理、數據歸檔、數據應用四個方面。
當前主要的應用場景包括報表展示、即席查詢、BI展示、數據分析、數據挖掘、模型訓練等方面。
數據倉庫的建設是面向主題的、集成性的、不可更新的、時許變化的。
實時與離線
離線數據倉庫主要基於sqoop、hive等技術來構建T+1的離線數據，通過定時任務每天拉取增量數據導入到hive表中，然后創建各個業務相關的主題維度數據，對外提供T+1的數據查詢接口。
實時數倉當前主要是基於數據采集工具，如canal等將原始數據寫入到Kafka這樣的數據通道中，最后一般都是寫入到類似於HBase這樣存儲系統中，對外提供分鍾級別、甚至秒級別的查詢方案。
數倉類型 |准確性 | 實時性 | 穩定性
----------| ---------| ------------------------------------
離線數倉 |准確度高 |時延一般在一天 |穩定性好，方便重算
實時數倉 |准確度底，數據延遲、數據亂序造成數據准確度低|分鍾級延遲|穩定性查，需要考慮數據回溯處理
實時數倉的的實施關鍵點
端到端數據延遲、數據流量的監控
故障的快速恢復能力
數據的回溯處理，系統支持消費指定時間端內的數據
實時數據從實時數倉中查詢，T+1數據借助離線通道修正
數據地圖、數據血緣關系的梳理
業務數據質量的實時監控，初期可以根據規則的方式來識別質量狀況
離線大數據架構
數據源通過離線的方式導入到離線數倉中。下游應用根據業務需求選擇直接讀取 DM 或加一層數據服務，比如 MySQL 或 Redis。數據倉庫從模型層面分為三層：
1.ODS，操作數據層，保存原始數據；
2.DWD，數據倉庫明細層，根據主題定義好事實與維度表，保存最細粒度的事實數據；
3.DM，數據集市/輕度匯總層，在 DWD 層的基礎之上根據不同的業務需求做輕度匯總；
典型的數倉存儲是 HDFS/Hive，ETL 可以是 MapReduce 腳本或 HiveSQL。
Lambda 架構
隨着大數據應用的發展，人們逐漸對系統的實時性提出了要求，為了計算一些實時指標，就在原來離線數倉的基礎上增加了一個實時計算的鏈路，並對數據源做流式改造（即把數據發送到消息隊列），實時計算去訂閱消息隊列，直接完成指標增量的計算，推送到下游的數據服務中去，由數據服務層完成離線&實時結果的合並。
Lambda 架構問題：
- 同樣的需求需要開發兩套一樣的代碼：這是 Lambda 架構最大的問題，兩套代碼不僅僅意味着開發困難（同樣的需求，一個在批處理引擎上實現，一個在流處理引擎上實現，還要分別構造數據測試保證兩者結果一致），后期維護更加困難，比如需求變更后需要分別更改兩套代碼，獨立測試結果，且兩個作業需要同步上線。
- 資源占用增多：同樣的邏輯計算兩次，整體資源占用會增多（多出實時計算這部分)
Kappa 架構
Lambda 架構雖然滿足了實時的需求，但帶來了更多的開發與運維工作，其架構背景是流處理引擎還不完善，流處理的結果只作為臨時的、近似的值提供參考。后來隨着 Flink 等流處理引擎的出現，流處理技術很成熟了，這時為了解決兩套代碼的問題，LickedIn 的 Jay Kreps 提出了 Kappa 架構。
1.Kappa 架構可以認為是 Lambda 架構的簡化版（只要移除 lambda 架構中的批處理部分即可）。
2.在 Kappa 架構中，需求修改或歷史數據重新處理都通過上游重放完成。
3.Kappa 架構最大的問題是流式重新處理歷史的吞吐能力會低於批處理，但這個可以通過增加計算資源來彌補。
Kappa架構的重新處理過程
重新處理是人們對Kappa架構最擔心的點，但實際上並不復雜：
1.選擇一個具有重放功能的、能夠保存歷史數據並支持多消費者的消息隊列，根據需求設置歷史數據保存的時長，比如Kafka，可以保存全部歷史數據。
2.當某個或某些指標有重新處理的需求時，按照新邏輯寫一個新作業，然后從上游消息隊列的最開始重新消費，把結果寫到一個新的下游表中。
3.當新作業趕上進度后，應用切換數據源，讀取2中產生的新結果表。
4.停止老的作業，刪除老的結果表。
Lambda架構與Kappa架構的對比
| 對比項 | Lambda架構 | Kappa架構 |
|---|---|---|
| 實時性 | 實時 | 實時 |
| 計算資源 | 批和流同時運行，資源開銷大 | 只有流處理，僅針對新需求開發階段運行兩個作業，資源開銷小 |
| 重新計算時吞吐 | 批式全量處理，吞吐較高 | 流式全量處理，吞吐較批處理低 |
| 開發、測試 | 每個需求都需要兩套不同代碼，開發、測試、上線難度較大 | 只需實現一套代碼，開發、測試、上線難度相對較小 |
| 運維成本 | 維護兩套系統（引擎），運維成本大 | 只需維護一套系統（引擎），運維成本小 |
在真實的場景中，很多時候並不是完全規范的Lambda架構或Kappa架構，可以是兩者的混合，比如大部分實時指標使用Kappa架構完成計算，少量關鍵指標（比如金額相關）使用Lambda架構用批處理重新計算，增加一次校對過程。
Kappa架構並不是中間結果完全不落地，現在很多大數據系統都需要支持機器學習（離線訓練），所以實時中間結果需要落地對應的存儲引擎供機器學習使用，另外有時候還需要對明細數據查詢，這種場景也需要把實時明細層寫出到對應的引擎中。
另外，隨着數據多樣性的發展，數據倉庫這種提前規定schema的模式顯得越來難以支持靈活的探索&分析需求，這時候便出現了一種數據湖技術，即把原始數據全部緩存到某個大數據存儲上，后續分析時再根據需求去解析原始數據。簡單的說，數據倉庫模式是schema on write，數據湖模式是schema on read。
實時數倉與離線數倉在幾方面的對比：
首先，從架構上，實時數倉與離線數倉有比較明顯的區別，實時數倉以 Kappa 架構為主，而離線數倉以傳統大數據架構為主。Lambda 架構可以認為是兩者的中間態。
其次，從建設方法上，實時數倉和離線數倉基本還是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流數據的 join 有隱藏時間語義，在建設中需注意。
最后，從數據保障看，實時數倉因為要保證實時性，所以對數據量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線數據的一個較為明顯的區別。