點擊上方“朱小廝的博客”，選擇“設為星標”

回復”666“獲取新整理的1000+GB資料

數(shù)據(jù)倉庫也是公司數(shù)據(jù)發(fā)展到一定規(guī)模后必然會提供的一種基礎服務，數(shù)據(jù)倉庫的建設也是“數(shù)據(jù)智能”中必不可少的一環(huán)。本文將從數(shù)據(jù)倉庫的簡介、經(jīng)歷了怎樣的發(fā)展、如何建設、架構演變、應用案例以及實時數(shù)倉與離線數(shù)倉的對比六個方面全面分享關于數(shù)倉的詳細內容。

1.數(shù)據(jù)倉庫簡介

數(shù)據(jù)倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合，用于支持管理決策。

數(shù)據(jù)倉庫是伴隨著企業(yè)信息化發(fā)展起來的，在企業(yè)信息化的過程中，隨著信息化工具的升級和新工具的應用，數(shù)據(jù)量變的越來越大，數(shù)據(jù)格式越來越多，決策要求越來越苛刻，數(shù)據(jù)倉庫技術也在不停的發(fā)展。數(shù)據(jù)倉庫的趨勢：

• 實時數(shù)據(jù)倉庫以滿足實時化&自動化決策需求；
• 大數(shù)據(jù)&數(shù)據(jù)湖以支持大量&復雜數(shù)據(jù)類型（文本、圖像、視頻、音頻）；

2.數(shù)據(jù)倉庫的發(fā)展

數(shù)據(jù)倉庫有兩個環(huán)節(jié)：數(shù)據(jù)倉庫的構建與數(shù)據(jù)倉庫的應用。早期數(shù)據(jù)倉庫構建主要指的是把企業(yè)的業(yè)務數(shù)據(jù)庫如 ERP、CRM、SCM 等數(shù)據(jù)按照決策分析的要求建模并匯總到數(shù)據(jù)倉庫引擎中，其應用以報表為主，目的是支持管理層和業(yè)務人員決策（中長期策略型決策）。隨著業(yè)務和環(huán)境的發(fā)展，這兩方面都在發(fā)生著劇烈變化。

• 隨著IT技術走向互聯(lián)網(wǎng)、移動化，數(shù)據(jù)源變得越來越豐富，在原來業(yè)務數(shù)據(jù)庫的基礎上出現(xiàn)了非結構化數(shù)據(jù)，比如網(wǎng)站 log，IoT 設備數(shù)據(jù)，APP 埋點數(shù)據(jù)等，這些數(shù)據(jù)量比以往結構化的數(shù)據(jù)大了幾個量級，對 ETL 過程、存儲都提出了更高的要求；
• 互聯(lián)網(wǎng)的在線特性也將業(yè)務需求推向了實時化，隨時根據(jù)當前客戶行為而調整策略變得越來越常見，比如大促過程中庫存管理，運營管理等（即既有中遠期策略型，也有短期操作型）；同時公司業(yè)務互聯(lián)網(wǎng)化之后導致同時服務的客戶劇增，有些情況人工難以完全處理，這就需要機器自動決策。比如欺詐檢測和用戶審核。

總結來看，對數(shù)據(jù)倉庫的需求可以抽象成兩方面：實時產(chǎn)生結果、處理和保存大量異構數(shù)據(jù)。注：這里不討論數(shù)據(jù)湖技術。

3.數(shù)據(jù)倉庫建設方法論

3.1 面向主題

從公司業(yè)務出發(fā)，是分析的宏觀領域，比如供應商主題、商品主題、客戶主題和倉庫主題

3.2 為多維數(shù)據(jù)分析服務

數(shù)據(jù)報表；數(shù)據(jù)立方體，上卷、下鉆、切片、旋轉等分析功能。

3.3 反范式數(shù)據(jù)模型

以事實表和維度表組成的星型數(shù)據(jù)模型

注：圖片來自 51 CTO

4.數(shù)據(jù)倉庫架構的演變

數(shù)據(jù)倉庫概念是 Inmon 于 1990 年提出并給出了完整的建設方法。隨著互聯(lián)網(wǎng)時代來臨，數(shù)據(jù)量暴增，開始使用大數(shù)據(jù)工具來替代經(jīng)典數(shù)倉中的傳統(tǒng)工具。此時僅僅是工具的取代，架構上并沒有根本的區(qū)別，可以把這個架構叫做離線大數(shù)據(jù)架構。
后來隨著業(yè)務實時性要求的不斷提高，人們開始在離線大數(shù)據(jù)架構基礎上加了一個加速層，使用流處理技術直接完成那些實時性要求較高的指標計算，這便是?Lambda 架構。再后來，實時的業(yè)務越來越多，事件化的數(shù)據(jù)源也越來越多，實時處理從次要部分變成了主要部分，架構也做了相應調整，出現(xiàn)了以實時事件處理為核心的?Kappa 架構。

4.1 離線大數(shù)據(jù)架構

數(shù)據(jù)源通過離線的方式導入到離線數(shù)倉中。下游應用根據(jù)業(yè)務需求選擇直接讀取 DM 或加一層數(shù)據(jù)服務，比如 MySQL 或 Redis。數(shù)據(jù)倉庫從模型層面分為三層：

• ODS，操作數(shù)據(jù)層，保存原始數(shù)據(jù)；
• DWD，數(shù)據(jù)倉庫明細層，根據(jù)主題定義好事實與維度表，保存最細粒度的事實數(shù)據(jù)；
• DM，數(shù)據(jù)集市/輕度匯總層，在 DWD 層的基礎之上根據(jù)不同的業(yè)務需求做輕度匯總；

典型的數(shù)倉存儲是 HDFS/Hive，ETL 可以是 MapReduce 腳本或 HiveSQL。

4.2 Lambda 架構

隨著大數(shù)據(jù)應用的發(fā)展，人們逐漸對系統(tǒng)的實時性提出了要求，為了計算一些實時指標，就在原來離線數(shù)倉的基礎上增加了一個實時計算的鏈路，并對數(shù)據(jù)源做流式改造（即把數(shù)據(jù)發(fā)送到消息隊列），實時計算去訂閱消息隊列，直接完成指標增量的計算，推送到下游的數(shù)據(jù)服務中去，由數(shù)據(jù)服務層完成離線&實時結果的合并。注：流處理計算的指標批處理依然計算，最終以批處理為準，即每次批處理計算后會覆蓋流處理的結果。（這僅僅是流處理引擎不完善做的折中）

Lambda 架構問題

• 同樣的需求需要開發(fā)兩套一樣的代碼：這是 Lambda 架構最大的問題，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求，一個在批處理引擎上實現(xiàn)，一個在流處理引擎上實現(xiàn)，還要分別構造數(shù)據(jù)測試保證兩者結果一致），后期維護更加困難，比如需求變更后需要分別更改兩套代碼，獨立測試結果，且兩個作業(yè)需要同步上線。
• 資源占用增多：同樣的邏輯計算兩次，整體資源占用會增多（多出實時計算這部分

4.3 Kappa 架構

Lambda 架構雖然滿足了實時的需求，但帶來了更多的開發(fā)與運維工作，其架構背景是流處理引擎還不完善，流處理的結果只作為臨時的、近似的值提供參考。后來隨著 Flink 等流處理引擎的出現(xiàn)，流處理技術很成熟了，這時為了解決兩套代碼的問題，LickedIn 的 Jay Kreps 提出了 Kappa 架構。

• Kappa 架構可以認為是 Lambda 架構的簡化版（只要移除 lambda 架構中的批處理部分即可）。

• 在 Kappa 架構中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成。

• Kappa 架構最大的問題是流式重新處理歷史的吞吐能力會低于批處理，但這個可以通過增加計算資源來彌補。

Kappa 架構的重新處理過程：重新處理是人們對 Kappa 架構最擔心的點，但實際上并不復雜：

• 選擇一個具有重放功能的、能夠保存歷史數(shù)據(jù)并支持多消費者的消息隊列，根據(jù)需求設置歷史數(shù)據(jù)保存的時長，比如 Kafka，可以保存全部歷史數(shù)據(jù)。
• 當某個或某些指標有重新處理的需求時，按照新邏輯寫一個新作業(yè)，然后從上游消息隊列的最開始重新消費，把結果寫到一個新的下游表中。
• 當新作業(yè)趕上進度后，應用切換數(shù)據(jù)源，讀取 2 中產(chǎn)生的新結果表。
• 停止老的作業(yè)，刪除老的結果表。

4.4 Lambda 架構與 Kappa 架構的對比

在真實的場景中，很多時候并不是完全規(guī)范的 Lambda 架構或 Kappa 架構，可以是兩者的混合，比如大部分實時指標使用 Kappa 架構完成計算，少量關鍵指標（比如金額相關）使用 Lambda 架構用批處理重新計算，增加一次校對過程。

Kappa 架構并不是中間結果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機器學習（離線訓練），所以實時中間結果需要落地對應的存儲引擎供機器學習使用，另外有時候還需要對明細數(shù)據(jù)查詢，這種場景也需要把實時明細層寫出到對應的引擎中。參考后面的案例。

另外，隨著數(shù)據(jù)多樣性的發(fā)展，數(shù)據(jù)倉庫這種提前規(guī)定 schema 的模式顯得越來難以支持靈活的探索&分析需求，這時候便出現(xiàn)了一種數(shù)據(jù)湖技術，即把原始數(shù)據(jù)全部緩存到某個大數(shù)據(jù)存儲上，后續(xù)分析時再根據(jù)需求去解析原始數(shù)據(jù)。簡單的說，數(shù)據(jù)倉庫模式是 schema on write，數(shù)據(jù)湖模式是 schema on read。

5.實時數(shù)倉案例

菜鳥倉配實時數(shù)據(jù)倉庫本案例參考自菜鳥倉配團隊的分享，涉及全局設計、數(shù)據(jù)模型、數(shù)據(jù)保障等幾個方面。

注：特別感謝緣橋同學的無私分享。

5.1 整體設計

整體設計如下圖，基于業(yè)務系統(tǒng)的數(shù)據(jù)，數(shù)據(jù)模型采用中間層的設計理念，建設倉配實時數(shù)倉；計算引擎，選擇更易用、性能表現(xiàn)更佳的實時計算作為主要的計算引擎；數(shù)據(jù)服務，選擇天工數(shù)據(jù)服務中間件，避免直連數(shù)據(jù)庫，且基于天工可以做到主備鏈路靈活配置秒級切換；數(shù)據(jù)應用，圍繞大促全鏈路，從活動計劃、活動備貨、活動直播、活動售后、活動復盤五個維度，建設倉配大促數(shù)據(jù)體系。

5.2 數(shù)據(jù)模型

不管是從計算成本，還是從易用性，還是從復用性，還是從一致性等等，我們都必須避免煙囪式的開發(fā)模式，而是以中間層的方式建設倉配實時數(shù)倉。與離線中間層基本一致，我們將實時中間層分為兩層。

• 第一層 DWD 公共實時明細層

實時計算訂閱業(yè)務數(shù)據(jù)消息隊列，然后通過數(shù)據(jù)清洗、多數(shù)據(jù)源 join、流式數(shù)據(jù)與離線維度信息等的組合，將一些相同粒度的業(yè)務系統(tǒng)、維表中的維度屬性全部關聯(lián)到一起，增加數(shù)據(jù)易用性和復用性，得到最終的實時明細數(shù)據(jù)。這部分數(shù)據(jù)有兩個分支，一部分直接落地到 ADS，供實時明細查詢使用，一部分再發(fā)送到消息隊列中，供下層計算使用；

• 第二層 DWS 公共實時匯總層

以數(shù)據(jù)域+業(yè)務域的理念建設公共匯總層，與離線數(shù)倉不同的是，這里匯總層分為輕度匯總層和高度匯總層，并同時產(chǎn)出，輕度匯總層寫入 ADS，用于前端產(chǎn)品復雜的 olap 查詢場景，滿足自助分析和產(chǎn)出報表的需求；高度匯總層寫入 Hbase，用于前端比較簡單的 kv 查詢場景，提升查詢性能，比如實時大屏等；

注：

• ADS 是一款提供 OLAP 分析服務的引擎。開源提供類似功能的有，Elastic Search、Kylin、Druid 等；
• 案例中選擇把數(shù)據(jù)寫入到 Hbase 供 KV 查詢，也可根據(jù)情況選擇其他引擎，比如數(shù)據(jù)量不多，查詢壓力也不大的話，可以用 MySQL；
• 因主題建模與業(yè)務關系較大，這里不做描述；

5.3 數(shù)據(jù)保障

阿里巴巴每年都有雙十一等大促，大促期間流量與數(shù)據(jù)量都會暴增。實時系統(tǒng)要保證實時性，相對離線系統(tǒng)對數(shù)據(jù)量要更敏感，對穩(wěn)定性要求更高。所以為了應對這種場景，還需要在這種場景下做兩種準備：

• 大促前的系統(tǒng)壓測；

• 大促中的主備鏈路保障；

菜鳥雙11「倉儲配送數(shù)據(jù)實時化」詳情了解：

https://yq.aliyun.com/articles/658787?spm=a2c4e.11153940.0.0.449f1d531ZoDbX

6. 實時數(shù)倉與離線數(shù)倉的對比

在看過前面的敘述與菜鳥案例之后，我們看一下實時數(shù)倉與離線數(shù)倉在幾方面的對比：

• 首先，從架構上，實時數(shù)倉與離線數(shù)倉有比較明顯的區(qū)別，實時數(shù)倉以 Kappa 架構為主，而離線數(shù)倉以傳統(tǒng)大數(shù)據(jù)架構為主。Lambda 架構可以認為是兩者的中間態(tài)。
• 其次，從建設方法上，實時數(shù)倉和離線數(shù)倉基本還是沿用傳統(tǒng)的數(shù)倉主題建模理論，產(chǎn)出事實寬表。另外實時數(shù)倉中實時流數(shù)據(jù)的 join 有隱藏時間語義，在建設中需注意。
• 最后，從數(shù)據(jù)保障看，實時數(shù)倉因為要保證實時性，所以對數(shù)據(jù)量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線數(shù)據(jù)的一個較為明顯的區(qū)別。

想知道更多？掃描下面的二維碼關注我

---

加技術群入口（備注：Tech）：>>>Learn More<<

免費星球入口：>>>Free<<<

內推通道>>>>

最近整理了一份資料，包含Java技術棧、消息中間件、分布式存儲、大數(shù)據(jù)、高可用架構、通用型技術架構等。獲取方式：點擊「在看」，關注公眾號并在后臺回復“666”即可獲取。

朕已閱?

總結

以上是生活随笔為你收集整理的中秋干货 | 架构进阶之路上的实时数仓的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。