1.數據倉庫簡介
數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。
數據倉庫是伴隨著企業信息化發展起來的，在企業信息化的過程中，隨著信息化工具的升級和新工具的應用，數據量變的越來越大，數據格式越來越多，決策要求越來越苛刻，數據倉庫技術也在不停的發展。
數據倉庫的趨勢：
- 實時數據倉庫以滿足實時化&自動化決策需求；
- 大數據&數據湖以支持大量&複雜數據類型（文本、圖像、視頻、音頻）；
2.數據倉庫的發展
數據倉庫有兩個環節：數據倉庫的構建與數據倉庫的應用。
早期數據倉庫構建主要指的是把企業的業務數據庫如ERP、CRM、SCM等數據按照決策分析的要求建模並彙總到數據倉庫引擎中，其應用以報表為主，目的是支持管理層和業務人員決策（中長期策略型決策）。
隨著業務和環境的發展，這兩方面都在發生著劇烈變化。
- 隨著IT技術走向互聯網、移動化，數據源變得越來越豐富，在原來業務數據庫的基礎上出現了非結構化數據，比如網站log，IoT設備數據，APP埋點數據等，這些數據量比以往結構化的數據大了幾個量級，對ETL過程、存儲都提出了更高的要求；
- 互聯網的在線特性也將業務需求推向了實時化，隨時根據當前客戶行為而調整策略變得越來越常見，比如大促過程中庫存管理，運營管理等（即既有中遠期策略型，也有短期操作型）；同時公司業務互聯網化之後導致同時服務的客戶劇增，有些情況人工難以完全處理，這就需要機器自動決策。比如欺詐檢測和用戶審核。
總結來看，對數據倉庫的需求可以抽象成兩方面：實時產生結果、處理和保存大量異構數據。
注：這裡不討論數據湖技術。
3.數據倉庫建設方法論
1）面向主題
從公司業務出發，是分析的宏觀領域，比如供應商主題、商品主題、客戶主題和倉庫主題
2）為多維數據分析服務
數據報表；數據立方體，上卷、下鑽、切片、旋轉等分析功能。
4.數據倉庫架構的演變
數據倉庫概念是Inmon於1990年提出並給出了完整的建設方法。隨著互聯網時代來臨，數據量暴增，開始使用大數據工具來替代經典數倉中的傳統工具。此時僅僅是工具的取代，架構上並沒有根本的區別，可以把這個架構叫做離線大數據架構。
後來隨著業務實時性要求的不斷提高，人們開始在離線大數據架構基礎上加了一個加速層，使用流處理技術直接完成那些實時性要求較高的指標計算，這便是Lambda架構。
再後來，實時的業務越來越多，事件化的數據源也越來越多，實時處理從次要部分變成了主要部分，架構也做了相應調整，出現了以實時事件處理為核心的Kappa架構。
4.1離線大數據架構
數據源通過離線的方式導入到離線數倉中。
下游應用根據業務需求選擇直接讀取DM或加一層數據服務，比如mysql 或 redis。
數據倉庫從模型層面分為三層：
- ODS，操作數據層，保存原始數據；
- DWD，數據倉庫明細層，根據主題定義好事實與維度表，保存最細粒度的事實數據；
- DM，數據集市/輕度彙總層，在DWD層的基礎之上根據不同的業務需求做輕度彙總；
典型的數倉存儲是HDFS/Hive，ETL可以是MapReduce腳本或HiveSQL。
4.2 Lambda架構
隨著大數據應用的發展，人們逐漸對系統的實時性提出了要求，為了計算一些實時指標，就在原來離線數倉的基礎上增加了一個實時計算的鏈路，並對數據源做流式改造（即把數據發送到消息隊列），實時計算去訂閱消息隊列，直接完成指標增量的計算，推送到下游的數據服務中去，由數據服務層完成離線&實時結果的合併。
注：流處理計算的指標批處理依然計算，最終以批處理為準，即每次批處理計算後會覆蓋流處理的結果。（這僅僅是流處理引擎不完善做的折中）
Lambda架構問題：
- 1.同樣的需求需要開發兩套一樣的代碼
- 這是Lambda架構最大的問題，兩套代碼不僅僅意味著開發困難（同樣的需求，一個在批處理引擎上實現，一個在流處理引擎上實現，還要分別構造數據測試保證兩者結果一致），後期維護更加困難，比如需求變更後需要分別更改兩套代碼，獨立測試結果，且兩個作業需要同步上線。
- 2.資源佔用增多：同樣的邏輯計算兩次，整體資源佔用會增多（多出實時計算這部分）
4.3 Kappa架構
Lambda架構雖然滿足了實時的需求，但帶來了更多的開發與運維工作，其架構背景是流處理引擎還不完善，流處理的結果只作為臨時的、近似的值提供參考。後來隨著Flink等流處理引擎的出現，流處理技術很成熟了，這時為了解決兩套代碼的問題，LickedIn 的Jay Kreps提出了Kappa架構
Kappa架構可以認為是Lambda架構的簡化版（只要移除lambda架構中的批處理部分即可）。
在Kappa架構中，需求修改或歷史數據重新處理都通過上游重放完成。
Kappa架構最大的問題是流式重新處理歷史的吞吐能力會低於批處理，但這個可以通過增加計算資源來彌補。
Kappa架構的重新處理過程
重新處理是人們對Kappa架構最擔心的點，但實際上並不複雜：
- 1.選擇一個具有重放功能的、能夠保存歷史數據並支持多消費者的消息隊別，根據需求設置歷史數據保存的時長，比如Kafka，可以保存全部歷史數據。
- 2.當某個或某些指標有重新處理的需求時，按照新邏輯寫一個新作業，然後從上游消息隊列的最開始重新消費，把結果寫到一個新的下游表中。
- 3.當新作業趕上進度後，應用切換數據源，讀取2中產生的新結果表。
- 4.停止老的作業，刪除老的結果表。
4.4 Lambda架構與Kappa架構的對比
在真實的場景中，很多時候並不是完全規範的Lambda架構或Kappa架構，可以是兩者的混合，比如大部分實時指標使用Kappa架構完成計算，少量關鍵指標（比如金額相關）使用Lambda架構用批處理重新計算，增加一次校對過程。（1）
Kappa架構並不是中間結果完全不落地，現在很多大數據系統都需要支持機器學習（離線訓練），所以實時中間結果需要落地對應的存儲引擎供機器學習使用，另外有時候還需要對明細數據查詢，這種場景也需要把實時明細層寫出到對應的引擎中。（2）參考後面的案例
另外，隨著數據多樣性的發展，數據倉庫這種提前規定schema的模式顯得越來難以支持靈活的探索&分析需求，這時候便出現了一種數據湖技術，即把原始數據全部緩存到某個大數據存儲上，後續分析時再根據需求去解析原始數據。簡單的說，數據倉庫模式是schema on write，數據湖模式是schema on read。（3）
5.實時數倉案例
菜鳥倉配實時數據倉庫
5.1 整體設計
整體設計如右圖，基於業務系統的數據，數據模型採用中間層的設計理念，建設倉配實時數倉；計算引擎，選擇更易用、性能表現更佳的實時計算作為主要的計算引擎；數據服務，選擇天工數據服務中間件，避免直連數據庫，且基於天工可以做到主備鏈路靈活配置秒級切換；數據應用，圍繞大促全鏈路，從活動計劃、活動備貨、活動直播、活動售後、活動覆盤五個維度，建設倉配大促數據體系。
5.2 數據模型
不管是從計算成本，還是從易用性，還是從複用性，還是從一致性……，我們都必須避免煙囪式的開發模式，而是以中間層的方式建設倉配實時數倉。與離線中間層基本一致，我們將實時中間層分為兩層。
第一層DWD公共實時明細層
實時計算訂閱業務數據消息隊列，然後通過數據清洗、多數據源join、流式數據與離線維度信息等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加數據易用性和複用性，得到最終的實時明細數據。這部分數據有兩個分支，一部分直接落地到ADS，供實時明細查詢使用，一部分再發送到消息隊列中，供下層計算使用；
第二層DWS公共實時彙總層
以數據域+業務域的理念建設公共彙總層，與離線數倉不同的是，這裡彙總層分為輕度彙總層和高度彙總層，並同時產出，輕度彙總層寫入ADS，用於前端產品複雜的olap查詢場景，滿足自助分析和產出報表的需求；高度彙總層寫入Hbase，用於前端比較簡單的kv查詢場景，提升查詢性能，比如實時大屏等；
注：
1.ADS是一款提供OLAP分析服務的引擎。開源提供類似功能的有，Elastic Search、Kylin、Druid等；
2.案例中選擇把數據寫入到Hbase供KV查詢，也可根據情況選擇其他引擎，比如數據量不多，查詢壓力也不大的話，可以用mysql
3.因主題建模與業務關係較大，這裡不做描述
5.3 數據保障
集團每年都有雙十一等大促，大促期間流量與數據量都會暴增。
實時系統要保證實時性，相對離線系統對數據量要更敏感，對穩定性要求更高。
所以為了應對這種場景，還需要在這種場景下做兩種準備：
- 大促前的系統壓測；
- 大促中的主備鏈路保障；
6. 實時數倉與離線數倉的對比
在看過前面的敘述與菜鳥案例之後，我們看一下實時數倉與離線數倉在幾方面的對比：
首先，從架構上，實時數倉與離線數倉有比較明顯的區別，實時數倉以Kappa架構為主，而離線數倉以傳統大數據架構為主。Lambda架構可以認為是兩者的中間態。
其次，從建設方法上，實時數倉和離線數倉基本還是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流數據的join有隱藏時間語義，在建設中需注意。
最後，從數據保障看，實時數倉因為要保證實時性，所以對數據量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線數據的一個較為明顯的區別。
閱讀更多 IT技術管理那些事兒 的文章
