數據倉庫，英文全稱Data Warehouse，簡稱DW或DWH。

數據倉庫和數據庫的名字非常接近，但兩者是完全不同的東西。

我們先從數據倉庫的歷史開始說起吧。

數據倉庫的誕生

數據倉庫并不是一個新概念。事實上，它誕生至今，已經有幾十年的歷史。

上世紀70年代，關系數據庫（也就是傳統數據庫的主要類型）剛剛崛起的時候，美國康奈爾大學博士比爾·恩門（Bill Innmon，也有譯為比爾·因蒙）就開始定義和討論數據倉庫這一術語。

1988年，IBM研究人員巴里·德夫林（Barry Devlin）和鮑爾·穆爾菲（Paul Murphy），聯合發表了文章《商業和信息系統的架構》，其中引入了“商業數據倉庫”一詞。他們還開發了一種叫做“業務數據倉庫”的系統。

幾年后，1990年，美國科學家拉爾夫·金博爾（Ralph Kimball）創立了Red Brick Systems公司，推出專門用于數據倉庫的數據庫管理系統Red Brick Warehouse。

1991年，又是前面那個比爾·恩門，創立了Prism Solutions公司，推出用于開發數據倉庫的軟件Prism Warehouse Manager。

同年，比爾·恩門正式出版了數據倉庫的經典著作——《構建數據庫倉庫》，標志著數據倉庫概念的正式確立。

后來，比爾·恩門也被世人譽為“數據倉庫之父”。

比爾·恩門

數據倉庫的定義和特征

那么，到底什么是數據倉庫呢？

比爾·恩門在《構建數據庫倉庫》書中給出了一個定義——

數據倉庫，是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用于支持管理決策（Decision Making Support）。

這個定義非常抽象、燒腦，但準確概括了數據倉庫的幾個關鍵特征，值得剖析一下。

• 支持管理決策

先說“支持管理決策”，這是數據倉庫的作用，也是創造它的主要目的。

簡單來說，傳統數據庫主要是員工使用，支撐某項具體的工作。例如收銀系統等。

而數據倉庫，主要是管理層使用，用于掌握宏觀情況，以便做出更合理的決策。

以前小棗君給大家介紹數據庫入門的時候，提到過OLTP和OLAP。

OLTP是聯機事務處理（Online Transaction Processing）數據庫，出現較早，也是早期關系型數據庫的主要用途，用于支持日常業務操作，如訂單處理、庫存管理和銀行交易等。它們通常處理大量簡單的讀寫操作，需要系統能夠快速響應，且非常可靠。

OLAP是聯機分析處理（Online Analytical Processing）數據庫，出現較晚，用于支持復雜的分析查詢，如數據挖掘、趨勢分析和財務報告等。它們通常處理大量復雜的只讀查詢，對算力要求高，也需要支持很大的數據吞吐量。

數據倉庫，很顯然就是OLAP型。或者也可以說，數據倉庫是OLAP數據庫場景的延伸和發展。OLAP類應用，催生了數據倉庫。

概括來說，數據倉庫是一個戰略級的工具。它通常用于商業智能（Business Intelligence，簡稱BI，咨詢機構Gartner造出來的流行詞）和決策支持，可以幫助企業從大量數據中獲得有價值的信息，增加洞察能力。

終極目的，當然是增加收入、提升效率、降低成本。

• 面向主題

傳統數據庫，圍繞具體的工作（應用）來組織數據，用于一個明確的事務。例如進銷存數據庫、考勤數據庫、財務數據庫等。

而數據倉庫，是按照主題來組織數據的。所謂主題，是一個特定的業務領域，或者一個明確的分析目標，例如銷售分析主題、員工敬業度主題，學生在校表現主題等等。主題的范圍更大，level（層級）更高。

簡單來說，數據倉庫的數據，是多個傳統數據庫的集合和“拉通”。它把不同數據庫表單的信息挑選整合在一起，提供了一個更全面的數據呈現。

主題性的設計，顯然更適合支持管理者做決策和分析。

• 集成

集成，是指數據倉庫可以整合來自多個不同數據源（企業內部數據庫、供應商數據庫、渠道商數據庫等）的數據。

多方面的數據源，也是為了提供一個更全面的視角，以便服務于分析和決策。

這些數據，可以包括結構化數據、半結構化數據和非結構化數據等。但數據倉庫，主要還是結構化數據為主。

• 相對穩定

相對穩定，指的是數據一旦被加載到數據倉庫中，通常不會更新或修改，確保了數據的穩定性和用于長期分析的可靠性。

換言之，數據倉庫所涉及的操作，主要是數據查詢，而不是修改。

除了數據之外，數據倉庫的架構一般也不會頻繁變化。

• 反映歷史變化

傳統數據庫，一般都是數據更新。寫入新數據，替換舊數據。

數據倉庫不一樣。它保存了大量的歷史數據，有利于企業從時間的維度，分析業務的發展趨勢。

面向主題、集成、相對穩定、反映歷史變化，這就是數據倉庫的四大特征。

我們還是以超市為例，總結一下數據倉庫和傳統數據庫的區別。

假如你有一個大超市。

超市有基于傳統數據庫的很多個收銀臺，記錄了每天的每一筆交易（賣出了什么商品，金額是多少）。超市還有庫存系統，記錄了商品的信息（一共有多少個庫存）。還有會員系統、購物卡系統，等等。

所有這些數據，分散在不同的系統里，雜亂無章。

你把所有系統的數據（銷售數據、顧客信息、供應商記錄等），統一做了整理（比如去掉無效數據、統一“日期”格式），按主題分類（比如“銷售分析”、“客戶畫像”），集中存到一個龐大的數據系統里。這就是數據倉庫。

然后，你開發了一些工具，可以分析這些數據，回答你的一些疑問：

“過去5年哪些商品在春節賣得最好？”

“上海和北京的顧客購物習慣有什么差異？”

“如何預測明年的商品庫存需求？”

……

也可以以大屏的形式，觀看這些數據（掌控全局、運籌帷幄的老板既視感）：

圖片

當然了，這些數據也可以開放給各個部門的主管，幫助部門改善業績。

這個數據倉庫，是不是輔助了你的決策，創造了價值？

數據倉庫的架構和工作流

接下來，我們看看數據倉庫的整體架構，以及如何搭建。

每個公司的數據倉庫架構都不太一樣。但基本上都包括以下幾層：

數據倉庫的整體架構

原始數據層（ODS，Operation Data Store）：也叫數據引入層、操作數據層、數據準備層或貼源層，用于采集和存儲原始數據。

數據公共層（CDM，Common Data Model）：數據倉庫的主要部分。有時候又分為基礎層/明細層（DWD，DW Detail）、匯總層/服務層（DWS，DW Service）、公共維度層（DIM）。DWD對源數據進行清洗以便將其加載到數據倉庫中。DWS將經過清洗和轉換后的數據并輕度匯總。DIW用于保存維度信息，用于建模。

數據應用層（ADS，Application Data Service）：主要功能是保存結果數據，為外部系統提供查詢接口，用于滿足特定的商業智能、數據挖掘和報表應用。

數據倉庫的架構和它的工作流有密切的關系。

一般來說，數據倉庫的工作流分為以下幾步：

1、數據抽取

前面說了，數據倉庫有很多的數據源。所以，第一步，是從不同的數據源系統中抽取數據。

數據抽取是定期進行的，比如每天或每周，以確保數據是最新的。

2、數據清洗和轉換

抽取出的數據，通常需要經過清洗和轉換，以提高數據質量和一致性。

清洗包括修正錯誤、去除重復項、處理缺失值等。轉換則是將數據轉化為統一的格式，以便在數據倉庫中進行有效存儲和查詢。

3、數據建模

數據倉庫采用特定的數據模型，對數據進行組織和存儲，設計數據表。選擇合適的模型，可以簡化數據查詢和分析過程，提高查詢性能。

數據倉庫建模中，比較有代表性的兩類方法論是Ralph Kimball的建模方法論和Bill Inmon建模方法論（沒錯，就是前面提到的那兩個大佬）。

Ralph Kimball的維度建模方法論，是一種常用的數據倉庫建模方法，它強調使用星型模型、雪花模型、星座模型來設計數據倉庫。

圖片

Bill Inmon則認為企業數據倉庫應為原子數據的集成倉庫，應用第三范式和ER模型而非維度建模的事實表、維度表來建模。

這里要提到一個元數據的概念。

元數據是描述數據的數據。它用以描述數據倉庫內數據的結構、位置和建立方法，便于數據倉庫的管理和使用。

4、數據存儲

數據倉庫通常采用大容量、高性能的存儲系統，以滿足大量數據的存儲和查詢需求。數據倉庫的存儲結構通常針對查詢性能進行了優化，如列式存儲、索引等。

5、數據加載

抽取（Extract）、轉換（Transform）和加載（Load），就是著名的ETL三板斧。

ETL后的數據，會被加載到數據倉庫中。

根據需要，還可能會進一步加工，例如聚合、摘要和索引創建，以優化查詢性能。

另外，數據加載可以分為全量加載和增量加載兩種方式，也是根據需求選擇。

6、數據訪問與分析

數據倉庫完成數據存儲后，就可以開始用了。

數據倉庫支持各種數據分析和報表工具，如商業智能（BI）、SQL查詢、OLAP、數據挖掘等。用戶可以通過這些工具，對數據進行深入分析，找到其中的規律和趨勢。

值得一提的是，數據倉庫不僅支持宏觀趨勢分析，也支持微觀細節探究，能夠滿足各個層級的需求。

7、數據安全和訪問控制

在數據倉庫的使用過程中，當然還要注意數據安全和訪問控制。確保數據的安全性和合規性，防止數據泄露和濫用。

圖片

數據集市（Data Mart）

數據集市可以認為是數據倉庫的子集，是專用于特定業務部門或功能的數據系統。它的數據是從數據倉庫中提取并進一步加工得到的。

例如，一個銷售數據集市，可以提供詳細的銷售報告和分析，輔助銷售部門進行決策。

圖片

數據集市的優點包括：

1.規模小：由于只包含與特定主題相關的數據，因此數據集市的規模相對較小，易于構建和維護。

2.數據深：數據集市可以滿足特定部門或用戶的需求，提供更加詳細和深入的數據支持。

3.響應快：因為它的數據量相對較小且針對特定需求進行了優化，所以能夠提供更快的查詢響應時間。

4.建設周期短：由于規模較小且面向特定需求，數據集市的建設周期通常較短，可以快速實現并投入使用。（數據倉庫的建設周期一般需要數個月甚至一年以上。）

5.靈活性高：數據集市的數據模型和結構可以根據特定需求進行調整，具有較高的靈活性。

6.成本低：數據集市的實現成本相對較低，因為其數據量和復雜度較數據倉庫低。

數據倉庫的發展趨勢

數據倉庫誕生了幾十年，技術也一直在發展。為了實現處理能力的升級，經歷了多個發展階段。

早期的時候，基本上就是基于傳統數據庫產品（例如Oracle），構建的數據倉庫。數據倉庫最早也是離線的，數據源通過離線方式導入到離線數據倉庫中。

后來，進入21世紀，有了大數據技術（Hadoop、Spark等）。就開始將這些技術引入到數據倉庫，通過MapReduce、Hive、SparkSQL等離線計算引擎進行數據處理，處理效率有了明顯提升。

再后來，分別發展出了Lambda架構（離線+實時結合）和Kappa架構（批流一體）。

圖片

再再后來，到了近幾年，就是基于MPP數據庫和數據湖的實時數倉架構。

這些架構支持高性能并行處理，支持復雜查詢。在處理能力和效率上已經今非昔比，能夠幫助企業更及時、更準確地進行決策。

從部署方面來看，數據倉庫也有變化。以前是本地單機部署，后來是分布式部署，再后來，云計算崛起，就是云部署。

這兩年，AI很火。所以，很多企業開始研究AI與數據系統的深度結合。

說白了，就是看AI怎么讓數據倉庫能夠更智能地處理和分析數據，提高數據的準確性和可靠性。反過來，AI也是“吃”數據的，還要研究如何讓數據倉庫這樣的數據平臺，更好地服務于AI的訓練和推理。

這里面的發展前景，還是非常廣闊的。