我們在談數倉之前，為了讓大家有直觀的認識，先來談數倉架構，“架構”是什麼？這個問題從來就沒有一個準確的答案。這裡我們引用一段話：在軟體行業，一種被普遍接受的架構定義是指系統的一個或多個結構。結構中包括軟體的構建（構建是指軟體的設計與實現），構建的外部可以看到屬性以及它們之間的相互關係。 ...
文檔大綱
一、數倉基本概念
1、數據倉庫架構
我們在談數倉之前，為了讓大家有直觀的認識，先來談數倉架構，“架構”是什麼？這個問題從來就沒有一個準確的答案。這裡我們引用一段話：在軟體行業，一種被普遍接受的架構定義是指系統的一個或多個結構。結構中包括軟體的構建（構建是指軟體的設計與實現），構建的外部可以看到屬性以及它們之間的相互關係。
這裡參考此定義，把數據倉庫架構理解成構成數據倉庫的組件及其之間的關係，畫出下麵的數倉架構圖：
數倉架構
上圖中顯示的整個數據倉庫環境包括操作型系統和數據倉庫系統兩大部分。操作型系統的數據由各種形式的業務數據組成，這些數據經過抽取、轉換和裝載（ETL）過程進入數據倉庫系統。
任何事物都是隨著時間的演進變得越來越完善，當然也是越來越複雜，數倉也不例外。在數據倉庫技術演化過程中，產生了幾種主要的架構方法，包括數據集市架構、Inmon企業信息工廠架構、Kimball數據倉庫架構、混合型數據倉庫架構。這幾種架構我們後面再講，接下來看下數倉的基本概念。
2、數據倉庫概念
英文名稱為Data Warehouse，可簡寫為DW或DWH。數據倉庫的目的是構建面向分析的集成化數據環境，為企業提供決策支持（Decision Support）。它出於分析性報告和決策支持目的而創建。
數據倉庫本身並不“生產”任何數據，同時自身也不需要“消費”任何的數據，數據來源於外部，並且開放給外部應用，這也是為什麼叫“倉庫”，而不叫“工廠”的原因。
1) 基本特征
數據倉庫是面向主題的、集成的、非易失的和時變的數據集合，用以支持管理決策。
①面向主題:
傳統資料庫中，最大的特點是面嚮應用進行數據的組織，各個業務系統可能是相互分離的。而數據倉庫則是面向主題的。主題是一個抽象的概念，是較高層次上企業信息系統中的數據綜合、歸類併進行分析利用的抽象。在邏輯意義上，它是對應企業中某一巨集觀分析領域所涉及的分析對象。
②集成性:
通過對分散、獨立、異構的資料庫數據進行抽取、清理、轉換和彙總便得到了數據倉庫的數據，這樣保證了數據倉庫內的數據關於整個企業的一致性。
數據倉庫中的綜合數據不能從原有的資料庫系統直接得到。因此在數據進入數據倉庫之前，必然要經過統一與綜合，這一步是數據倉庫建設中最關鍵、最複雜的一步，所要完成的工作有：
-
要統一源數據中所有矛盾之處，如欄位的同名異義、異名同義、單位不統一、字長不一致，等等。
-
進行數據綜合和計算。數據倉庫中的數據綜合工作可以在從原有資料庫抽取數據時生成，但許多是在數據倉庫內部生成的，即進入數據倉庫以後進行綜合生成的。
下圖說明一個保險公司綜合數據的簡單處理過程，其中數據倉庫中與“保險” 主題有關的數據來自於多個不同的操作型系統。這些系統內部數據的命名可能不同，數據格式也可能不同。把不同來源的數據存儲到數據倉庫之前，需要去除這些不一致。
數倉主題
③非易失性（不可更新性）:
數據倉庫的數據反映的是一段相當長的時間內歷史數據的內容，是不同時點的資料庫快照的集合，以及基於這些快照進行統計、綜合和重組的導出數據。
數據非易失性主要是針對應用而言。數據倉庫的用戶對數據的操作大多是數據查詢或比較複雜的挖掘，一旦數據進入數據倉庫以後，一般情況下被較長時間保留。數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少。因此，數據經加工和集成進入數據倉庫後是極少更新的，通常只需要定期的載入和更新。
④時變性:
數據倉庫包含各種粒度的歷史數據。數據倉庫中的數據可能與某個特定日期、星期、月份、季度或者年份有關。數據倉庫的目的是通過分析企業過去一段時間業務的經營狀況，挖掘其中隱藏的模式。雖然數據倉庫的用戶不能修改數據，但並不是說數據倉庫的數據是永遠不變的。分析的結果只能反映過去的情況，當業務變化後，挖掘出的模式會失去時效性。因此數據倉庫的數據需要更新，以適應決策的需要。從這個角度講，數據倉庫建設是一個項目，更是一個過程。數據倉庫的數據隨時間的變化表現在以下幾個方面：
-
數據倉庫的數據時限一般要遠遠長於操作型數據的數據時限。
-
操作型系統存儲的是當前數據，而數據倉庫中的數據是歷史數據。
-
數據倉庫中的數據是按照時間順序追加的，它們都帶有時間屬性。
3、為什麼要有數據倉庫
先來看下數據倉庫的數據從哪裡來，最終要到哪裡去？
通常數據倉庫的數據來自各個業務應用系統。業務系統中的數據形式多種多樣，可能是 Oracle、MySQL、SQL Server等關係資料庫里的結構化數據，可能是文本、CSV等平面文件或Word、Excel文檔中的數據，還可能是HTML、XML等自描述的半結構化數據。這些業務數據經過一系列的數據抽取、轉換、清洗，最終以一種統一的格式裝載進數據倉庫。數據倉庫里的數據作為分析用的數據源，提供給後面的即席查詢、 分析系統、數據集市、報表系統、數據挖掘系統等。
這時我們就想了，為什麼不能把業務系統的數據直接拿來供即席查詢、分析系統、報表系統等使用呢，為什麼要經過數據倉庫這一步？實際上在數倉出現之前，確實是這麼做的，但是有很多數據分析的先驅者當時已經發現，簡單的“直接訪問”方式很難良好工作，這樣做的失敗案例數不勝數。下麵列舉一些直接訪問業務系統無法工作的原因：
-
某些業務數據由於安全或其他因素不能直接訪問。
-
業務系統的版本變更很頻繁，每次變更都需要重寫分析系統並重新測試。
-
很難建立和維護彙總數據來源於多個業務系統版本的報表。
-
業務系統的列名通常是硬編碼，有時僅僅是無意義的字元串，這讓編寫分析系統更加困難。
-
業務系統的數據格式，如日期、數字的格式不統一。
-
業務系統的表結構為事務處理性能而優化，有時並不適合查詢與分析。
-
沒有適當的方式將有價值的數據合併進特定應用的資料庫。
-
沒有適當的位置存儲元數據。
-
用戶需要看到的顯示數據欄位，有時在資料庫中並不存在。
-
通常事務處理的優先順序比分析系統高，所以如果分析系統和事務處理運行在同一硬體之上，分析系統往往性能很差。
-
有誤用業務數據的風險。
-
極有可能影響業務系統的性能。
儘管需要增加軟硬體的投入，但建立獨立數據倉庫與直接訪問業務數據相比，無論是成本還是帶來的好處，這樣做都是值得的。隨著處理器和存儲成本的逐年降低，數據倉庫方案的優勢更加明顯，在經濟上也更具可行性。
4、數據倉庫與資料庫的區別
資料庫與數據倉庫的區別實際講的是 OLTP 與 OLAP 的區別。
操作型處理，叫聯機事務處理 OLTP（On-Line Transaction Processing，），也可以稱面向交易的處理系統，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。用戶較為關心操作的響應時間、數據的安全性、完整性和併發支持的用戶數等問題。傳統的資料庫系統作為數據管理的主要手段，主要用於操作型處理，像MySQL，Oracle等關係型資料庫一般屬於OLTP。
分析型處理，叫聯機分析處理 OLAP（On-Line Analytical Processing）一般針對某些主題的歷史數據進行分析，支持管理決策。
首先要明白，數據倉庫的出現，並不是要取代資料庫。資料庫是面向事務的設計，數據倉庫是面向主題設計的。資料庫一般存儲業務數據，數據倉庫存儲的一般是歷史數據。
資料庫設計是儘量避免冗餘，一般針對某一業務應用進行設計，比如一張簡單的User表，記錄用戶名、密碼等簡單數據即可，符合業務應用，但是不符合分析。數據倉庫在設計是有意引入冗餘，依照分析需求，分析維度、分析指標進行設計。
資料庫是為捕獲數據而設計，數據倉庫是為分析數據而設計。
以銀行業務為例。資料庫是事務系統的數據平臺，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這裡，可以簡單地理解為用資料庫記賬。數據倉庫是分析系統的數據平臺，它從事務系統獲取數據，並做彙總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款餘額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。
顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能存儲很短一段時間的數據。而分析系統是事後的，它要提供關註時間段內所有的有效數據。這些數據是海量的，彙總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。
數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的“大型資料庫”。
5、數據倉庫分層架構
按照數據流入流出的過程，數據倉庫架構可分為：源數據、數據倉庫、數據應用。
數據倉庫
數據倉庫的數據來源於不同的源數據，並提供多樣的數據應用，數據自下而上流入數據倉庫後向上層開放應用，而數據倉庫只是中間集成化數據管理的一個平臺。
源數據：此層數據無任何更改，直接沿用外圍系統數據結構和數據，不對外開放；為臨時存儲層，是介面數據的臨時存儲區域，為後一步的數據處理做準備。
數據倉庫：也稱為細節層，DW層的數據應該是一致的、準確的、乾凈的數據，即對源系統數據進行了清洗（去除了雜質）後的數據。
數據應用：前端應用直接讀取的數據源；根據報表、專題分析需求而計算生成的數據。
數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是數據倉庫的流水線，也可以認為是數據倉庫的血液，它維繫著數據倉庫中數據的新陳代謝，而數據倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩定。
那麼為什麼要數據倉庫進行分層呢?
-
用空間換時間，通過大量的預處理來提升應用系統的用戶體驗（效率），因此數據倉庫會存在大量冗餘的數據；不分層的話，如果源業務系統的業務規則發生變化將會影響整個數據清洗過程，工作量巨大。
-
通過數據分層管理可以簡化數據清洗的過程，因為把原來一步的工作分到了多個步驟去完成，相當於把一個複雜的工作拆成了多個簡單的工作，把一個大的黑盒變成了一個白盒，每一層的處理邏輯都相對簡單和容易理解，這樣我們比較容易保證每一個步驟的正確性，當數據發生錯誤的時候，往往我們只需要局部調整某個步驟即可。
6、主要數據倉庫架構
通過上面的內容我們大概瞭解數倉的概念，接下來就看下數倉的幾種演進架構。
1）數據集市架構
數據集市是按主題域組織的數據集合，用於支持部門級的決策。有兩種類型的數據集市：獨立數據集市和從屬數據集市。
① 獨立數據集市
獨立數據集市集中於部門所關心的單一主題域，數據以部門為基礎部署，無須考慮企業級別的信息共用與集成。例如，製造部門、人力資源部門和其他部門都各自有他們自己的數據集市。
優點：因為一個部門的業務相對於整個企業要簡單，數據量也小得多，所以部門的獨立數據集市具有周期短、見效快的特點。
缺點：
-
從業務角度看，當部門的分析需求擴展，或者需要分析跨部門或跨主題域的數據時，獨立數據市場會顯得力不從心。
-
當數據存在歧義，比如同一個產品，在A部門和B部門的定義不同時，將無法在部門間進行信息比較。
-
每個部門使用不同的技術，建立不同的ETL的過程，處理不同的事務系統，而在多個獨立的數據集市之間還會存在數據的交叉與重疊，甚至會有數據不一致的情況。
②從屬數據集市
從屬數據集市的數據來源於數據倉庫。數據倉庫里的數據經過整合、重構、彙總後傳遞給從屬數據集市。
建立從屬數據集市的好處主要有：
-
性能：當數據倉庫的查詢性能出現問題，可以考慮建立幾個從屬數據集市，將查詢從數據倉庫移出到數據集市。
-
安全：每個部門可以完全控制他們自己的數據。
-
數據一致：因為每個數據集市的數據來源都是同一個數據倉庫，有效消除了數據不一致的情況。
2）Inmon企業工廠架構
上圖的前兩步不過多介紹，直接從第三步開始。
企業級數據倉庫：是該架構中的核心組件。正如Inmon數據倉庫所定義的，企業級數據倉庫是一個細節數據的集成資源庫。其中的數據以最低粒度級別被捕獲，存儲在滿足三範式設計的關係資料庫中。
部門級數據集市：是面向主題數據的部門級視圖，數據從企業級數據倉庫獲取。數據在進入部門數據集市時可能進行聚合。數據集市使用多維模型設計，用於數據分析。重要的一點是，所有的報表工具、BI工具或其他數據分析應用都從數據集市查詢數據，而不是直接查詢企業級數據倉庫。
3）Kimball數據倉庫架構
對比上一張圖可以看到，Kimball與Inmon兩種架構的主要區別在於核心數據倉庫的設計和建立。
Kimball的數據倉庫包含高粒度的企業數據，使用多維模型設計，這也意味著數據倉庫由星型模式的維度表和事實表構成。分析系統或報表工具可以直接訪問多維數據倉庫里的數據。
在此架構中的數據集市也與Inmon中的不同。這裡的數據集市是一個邏輯概念，只是多維數據倉庫中的主題域劃分，並沒有自己的物理存儲，也可以說是虛擬的數據集市。
4）混合型數據倉庫架構
所謂的混合型結構，指的是在一個數據倉庫環境中，聯合使用Inmon和Kimball兩種架構。
從架構圖可以看到，這種架構將Inmon方法中的數據集市部分替換成了一個多維數據倉庫，而數據集市則是多維數據倉庫上的邏輯視圖。
使用這種架構的好處是：既可以利用規範化設計消除數據冗餘，保證數據的粒度足夠細；又可以利用多維結構更靈活地在企業級實現報表和分析。
7、數據倉庫元數據的管理
元數據（Meta Date），主要記錄數據倉庫中模型的定義、各層級間的映射關係、監控數據倉庫的數據狀態及ETL的任務運行狀態。一般會通過元數據資料庫（Metadata Repository）來統一地存儲和管理元數據，其主要目的是使數據倉庫的設計、部署、操作和管理能達成協同和一致。
元數據是數據倉庫管理系統的重要組成部分，元數據管理是企業級數據倉庫中的關鍵組件，貫穿數據倉庫構建的整個過程，直接影響著數據倉庫的構建、使用和維護。
-
構建數據倉庫的主要步驟之一是ETL。這時元數據將發揮重要的作用，它定義了源數據系統到數據倉庫的映射、數據轉換的規則、數據倉庫的邏輯結構、數據更新的規則、數據導入歷史記錄以及裝載周期等相關內容。數據抽取和轉換的專家以及數據倉庫管理員正是通過元數據高效地構建數據倉庫。
-
用戶在使用數據倉庫時，通過元數據訪問數據，明確數據項的含義以及定製報表。
-
數據倉庫的規模及其複雜性離不開正確的元數據管理，包括增加或移除外部數據源，改變數據清洗方法，控制出錯的查詢以及安排備份等。
元數據可分為技術元數據和業務元數據。技術元數據為開發和管理數據倉庫的IT 人員使用，它描述了與數據倉庫開發、管理和維護相關的數據，包括數據源信息、數據轉換描述、數據倉庫模型、數據清洗與更新規則、數據映射和訪問許可權等。而業務元數據為管理層和業務分析人員服務，從業務角度描述數據，包括商務術語、數據倉庫中有什麼數據、數據的位置和數據的可用性等，幫助業務人員更好地理解數據倉庫中哪些數據是可用的以及如何使用。
由上可見，元數據不僅定義了數據倉庫中數據的模式、來源、抽取和轉換規則等，而且是整個數據倉庫系統運行的基礎，元數據把數據倉庫系統中各個鬆散的組件聯繫起來，組成了一個有機的整體。
8、數倉常見術語解析
本小節結構如下圖所示：
1）數倉名詞解釋
① 實體
實體是指依附的主體，就是我們分析的一個對象，比如我們分析商品的銷售情況，如華為手機近半年的銷售量是多少，那華為手機就是一個實體；我們分析用戶的活躍度，用戶就是一個實體。當然實體也可以現實中不存在的，比如虛擬的業務對象，活動，會員等都可看做一個實體。
實體的存在是為了業務分析，作為分析的一個篩選的維度，擁有描述自己的屬性，本身具有可分析的價值。
②維度
維度就是看待問題的角度，分析業務數據，從什麼角度分析，就建立什麼樣的維度。所以維度就是要對數據進行分析時所用的一個量，比如你要分析產品銷售情況，你可以選擇按商品類別來進行分析，這就構成一個維度，把所有商品類別集合在一起，就構成了維度表。
③度量
度量是業務流程節點上的一個數值。比如銷量，價格，成本等等。
事實表中的度量可分為三類：完全可加，半可加，不可加。
-
完全可加的度量是最靈活，最有用的，比如說銷量，銷售額等，可進行任意維度彙總；
-
半可加的度量可以對某些維度彙總，但不能對所有維度彙總，差額是常見的半可加度量，它除了時間維度外，可以跨所有維度進行加法操作；
-
還有一種是完全不可加的，例如：比率。對於這類非可加度量，一種好的方法是，儘可能存儲非可加度量的完全可加分量，併在計算出最終的非可加事實前，將這些分量彙總到最終的結果集中。
④粒度
粒度就是業務流程中對度量的單位，比如商品是按件記錄度量，還是按批記錄度量。
在數倉建設中，我們說這是用戶粒度的事實表，那麼表中每行數據都是一個用戶，無重覆用戶；例如還有銷售粒度的表，那麼表中每行都是一條銷售記錄。
選擇合適的粒度級別是數據倉庫建設好壞的重要關鍵內容，在設計數據粒度時，通常需重點考慮以下因素：
-
要接受的分析類型、可接受的數據最低粒度和能存儲的數據量；
-
粒度的層次定義越高，就越不能在該倉庫中進行更細緻的分析；
-
如果存儲資源有一定的限制，就只能採用較高的數據粒度劃分；
-
數據粒度劃分策略一定要保證：數據的粒度確實能夠滿足用戶的決策分析需要，這是數據粒度劃分策略中最重要的一個準則。
⑤口徑
口徑就是取數邏輯（如何取數的），比如要取的數是10歲以下兒童中男孩的平均身高，這就是統計的口徑。
⑥指標
指標是口徑的衡量值，也就是最後的結果。比如最近七天的訂單量，一個促銷活動的購買轉化率等。
一個指標具體到計算實施，主要有以下幾部分組成：
-
指標加工邏輯，比如count ,sum, avg。
-
維度，比如按部門、地域進行指標統計，對應sql中的group by。
-
業務限定/修飾詞，比如以不同的支付渠道來算對應的指標，微信支付的訂單退款率，支付寶支付的訂單退款率 ，對應sql中的where。
除此之外，指標本身還可以衍生、派生出更多的指標，基於這些特點，可以將指標進行分類：
-
原子指標：基本業務事實，沒有業務限定、沒有維度。比如訂單表中的訂單量、訂單總金額都算原子指標；
業務方更關心的指標，是有實際業務含義，可以直接取數據的指標。比如店鋪近1天訂單支付金額就是一個派生指標，會被直接在產品上展示給商家看。
但是這個指標卻不能直接從數倉的統一中間層里取數（因為沒有現成的事實欄位，數倉提供的一般都是大寬表）。需要有一個橋梁連接數倉中間層和業務方的指標需求，於是便有了派生指標。
-
派生指標：維度+修飾詞+原子指標。店鋪近1天訂單支付金額中店鋪是維度，近1天是一個時間類型的修飾詞，支付金額是一個原子指標；
維度：觀察各項指標的角度；
修飾詞：維度的一個或某些值，比如維度性別下，男和女就是2種修飾詞。
-
衍生指標：比如某一個促銷活動的轉化率就是衍生指標，因為需要促銷投放人數指標和促銷訂單數指標進行計算得出。
⑦標簽
標簽是人為設定的、根據業務場景需求，對目標對象運用一定的演算法得到的高度精煉的特征標識。可見標簽是經過人為再加工後的結果，如網紅、白富美、蘿莉。對於有歧義的標簽，我們內部可進行標簽區分，比如：蘋果，我們可以定義蘋果指的是水果，蘋果手機才指的是手機。
⑧自然鍵
由現實中已經存在的屬性組成的鍵，它在業務概念中是唯一的，並具有一定的業務含義，比如商品ID，員工ID。
以數倉角度看，來自於業務系統的標識符就是自然鍵，比如業務庫中員工的編號。
⑨持久鍵
保持永久性不會發生變化。有時也被叫做超自然持久鍵。比如身份證號屬於持久鍵。
自然鍵和持久鍵區別：舉個例子就明白了，比如說公司員工離職之後又重新入職，他的自然鍵也就是員工編號發生了變化，但是他的持久鍵身份證號是不變的。
⑩代理鍵
就是不具有業務含義的鍵。代理鍵有許多其他的稱呼：無意義鍵、整數鍵、非自然鍵、人工鍵、合成鍵等。
代理鍵就是簡單的以按照順序序列生產的整數表示。產品行的第1行代理鍵為1，則下一行的代理鍵為2，如此進行。代理鍵的作用僅僅是連接維度表和事實表。
⑪退化維度
退化維度，就是那些看起來像是事實表的一個維度關鍵字，但實際上並沒有對應的維度表，就是維度屬性存儲到事實表中，這種存儲到事實表中的維度列被稱為退化維度。與其他存儲在維表中的維度一樣，退化維度也可以用來進行事實表的過濾查詢、實現聚合操作等。
那麼究竟怎麼定義退化維度呢？比如說訂單id，這種量級很大的維度，沒必要用一張維度表來進行存儲，而我們進行數據查詢或者數據過濾的時候又非常需要，所以這種就冗餘在事實表裡面，這種就叫退化維度，citycode這種我們也會冗餘在事實表裡面，但是它有對應的維度表，所以它不是退化維度。
⑫下鑽
這是在數據分析中常見的概念，下鑽可以理解成增加維的層次，從而可以由粗粒度到細粒度來觀察數據，比如對產品銷售情況分析時，可以沿著時間維從年到月到日更細粒度的觀察數據。從年的維度可以下鑽到月的維度、日的維度等。
⑬上捲
知道了下鑽，上捲就容易理解了，它倆是相逆的操作，所以上捲可以理解為刪掉維的某些層，由細粒度到粗粒度觀察數據的操作或沿著維的層次向上聚合彙總數據。
⑭數據集市
數據集市（Data Mart），也叫數據市場，數據集市就是滿足特定的部門或者用戶的需求，按照多維的方式進行存儲，包括定義維度、需要計算的指標、維度的層次等，生成面向決策分析需求的數據立方體。其實就是從數據倉庫中抽取出來的一個小合集。
2）數倉名詞之間關係
①實體表，事實表，維度表之間的關係
在Kimball維度建模中有維度與事實，在Inmon範式建模中有實體與關係，如果我們分開兩種建模方式看這些概念比較容易理解。但是目前也出現了不少混合建模方式，兩種建模方式結合起來看，這些概念是不是容易記憶混亂，尤其事實表和實體表，它們之間到底有怎樣區別與聯繫，先看下它們各自概念：
-
維度表：維度表可以看成是用戶用來分析一個事實的視窗，它裡面的數據應該是對事實的各個方面描述，比如時間維度表，地域維度表，維度表是事實表的一個分析角度。
-
事實表：事實表其實就是通過各種維度和一些指標值的組合來確定一個事實的，比如通過時間維度，地域組織維度，指標值可以去確定在某時某地的一些指標值怎麼樣的事實。事實表的每一條數據都是幾條維度表的數據和指標值交匯而得到的。
-
實體表：實體表就是一個實際對象的表，實體表放的數據一定是一條條客觀存在的事物數據，比如說各種商品，它就是客觀存在的，所以可以將其設計一個實體表。實時表只描述各個事物，並不存在具體的事實，所以也有人稱實體表是無事實的事實表。
舉個例子：比如說手機商場中有蘋果手機，華為手機等各品牌各型號的手機，這些數據可以組成一個手機實體表，但是表中沒有可度量的數據。某天蘋果手機賣了15台，華為手機賣了20台，這些手機銷售數據屬於事實，組成一個事實表。這樣就可以使用日期維度表和地域維度表對這個事實表進行各種維度分析。
②指標與標簽的區別
-
概念不同
指標是用來定義、評價和描述特定事物的一種標準或方式。比如：新增用戶數、累計用戶數、用戶活躍率等是衡量用戶發展情況的指標；
標簽是人為設定的、根據業務場景需求，對目標對象運用一定的演算法得到的高度精煉的特征標識。可見標簽是經過人為再加工後的結果，如網紅、白富美、蘿莉。
-
構成不同
指標名稱是對事物質與量兩方面特點的命名；指標取值是指標在具體時間、地域、條件下的數量表現，如人的體重，指標名稱是體重，指標的取值就是120斤；
標簽名稱通常都是形容詞或形容詞+名詞的結構，標簽一般是不可量化的，通常是孤立的，除了基礎類標簽，通過一定演算法加工出來的標簽一般都沒有單位和量綱。如將超過200斤的稱為大胖子。
-
分類不同
對指標的分類：
按照指標計算邏輯，可以將指標分為原子指標、派生指標、衍生指標三種類型；
按照對事件描述內容的不同，分為過程性指標和結果性指標；
對標簽的分類：
按照標簽的變化性分為靜態標簽和動態標簽；
按照標簽的指代和評估指標的不同，可分為定性標簽和定量標簽；
指標最擅長的應用是監測、分析、評價和建模。
標簽最擅長的應用是標註、刻畫、分類和特征提取。
特別需要指出的是，由於對結果的標註也是一種標簽，所以在自然語言處理和機器學習相關的演算法應用場景下，標簽對於監督式學習有重要價值，只是單純的指標難以做到的。而指標在任務分配、績效管理等領域的作用，也是標簽無法做到的。
③維度和指標區別與聯繫
維度就是數據的觀察角度，即從哪個角度去分析問題，看待問題。
指標就是從維度的基礎上去衡算這個結果的值。
維度一般是一個離散的值，比如時間維度上每一個獨立的日期或地域，因此統計時，可以把維度相同記錄的聚合在一起，應用聚合函數做累加、均值、最大值、最小值等聚合計算。
指標就是被聚合的通計算，即聚合運算的結果，一般是一個連續的值。
④自然鍵與代理鍵在數倉的使用區別
數倉工具箱中說維度表的唯一主鍵應該是代理鍵而不應該是自然鍵。有時建模人員不願意放棄使用自然鍵，因為他們希望與操作型代碼查詢事實表，而不希望與維度表做連接操作。然而，應該避免使用包含業務含義的多維鍵，因為不管我們做出任何假設最終都可能變得無效，因為我們控制不了業務庫的變動。
所以數據倉庫中維度表與事實表的每個連接應該基於無實際含義的整數代理鍵。避免使用自然鍵作為維度表的主鍵。
⑤數據集市和數據倉庫的關係
數據集市是企業級數據倉庫的一個子集，他主要面向部門級業務，並且只面向某個特定的主題。為瞭解決靈活性和性能之間的矛盾，數據集市就是數據倉庫體繫結構中增加的一種小型的部門或工作組級別的數據倉庫。數據集市存儲為特定用戶預先計算好的數據，從而滿足用戶對性能的需求。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。
數據集市和數據倉庫的主要區別：數據倉庫是企業級的，能為整個企業各個部門的運行提供決策支持手段；而數據集市則是一種微型的數據倉庫,它通常有更少的數據,更少的主題區域,以及更少的歷史數據,因此是部門級的，一般只能為某個局部範圍內的管理人員服務，因此也稱之為部門級數據倉庫。
二、離線數倉建設核心
數據倉庫的核心是展現層和提供優質的服務。ETL 及其規範、分層等所做的一切都是為了一個更清晰易用的展現層。
1、數倉分層
數倉分層的原則：
-
為便於數據分析，要屏蔽底層複雜業務，簡單、完整、集成的將數據暴露給分析層。
-
底層業務變動與上層需求變動對模型衝擊最小化，業務系統變化影響削弱在基礎數據層，結合自上而下的建設方法削弱需求變動對模型的影響。
-
高內聚松耦合，即主題之內或各個完整意義的系統內數據的高內聚，主題之間或各個完整意義的系統間數據的松耦合。
-
構建倉庫基礎數據層，使底層業務數據整合工作與上層應用開發工作相隔離，為倉庫大規模開發奠定基礎 倉庫層次更加清晰，對外暴露數據更加統一。
一般採用如下分層結構：
1）數據源層：ODS（Operational Data Store）
ODS 層，是最接近數據源中數據的一層，為了考慮後續可能需要追溯數據問題，因此對於這一層就不建議做過多的數據清洗工作，原封不動地接入原始數據即可，至於數據的去噪、去重、異常值處理等過程可以放在後面的 DWD 層來做。
2）數據倉庫層：DW（Data Warehouse）
數據倉庫層是我們在做數據倉庫時要核心設計的一層，在這裡，從 ODS 層中獲得的數據按照主題建立各種數據模型。
DW 層又細分為 DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和 DWS（Data WareHouse Servce） 層。
①數據明細層：DWD（Data Warehouse Detail）
該層一般保持和 ODS 層一樣的數據粒度，並且提供一定的數據質量保證。DWD 層要做的就是將數據清理、整合、規範化、臟數據、垃圾數據、規範不一致的、狀態定義不一致的、命名不規範的數據都會被處理。
同時，為了提高數據明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。
另外，在該層也會做一部分的數據聚合，將相同主題的數據彙集到一張表中，提高數據的可用性 。
②數據中間層：DWM（Data WareHouse Middle）
該層會在 DWD 層的數據基礎上，數據做輕度的聚合操作，生成一系列的中間表，提升公共指標的復用性，減少重覆加工。
直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。
在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然後再拼接成一張 DWS 的寬表。由於寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的數據再放在 DWS 亦可。
③數據服務層：DWS（Data WareHouse Servce）
DWS 層為公共彙總層，會進行輕度彙總，粒度比明細數據稍粗，基於 DWD 層上的基礎數據，整合彙總成分析某一個主題域的服務數據，一般是寬表。DWS 層應覆蓋 80% 的應用場景。又稱數據集市或寬表。
按照業務劃分，如主題域流量、訂單、用戶等，生成欄位比較多的寬表，用於提供後續的業務查詢，OLAP 分析，數據分發等。
一般來講，該層的數據表會相對比較少，一張表會涵蓋比較多的業務內容，由於其欄位較多，因此一般也會稱該層的表為寬表。
3）數據應用層：APP（Application）
在這裡，主要是提供給數據產品和數據分析使用的數據，一般會存放在 ES、 PostgreSql、Redis 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用。比如我們經常說的報表數據，一般就放在這裡。
4）維表層：DIM（Dimension）
如果維表過多，也可針對維表設計單獨一層，維表層主要包含兩部分數據：
高基數維度數據：一般是用戶資料表、商品資料表類似的資料表。數據量可能是千萬級或者上億級別。
低基數維度數據：一般是配置表，比如枚舉值對應的中文含義，或者日期維表。數據量可能是個位數或者幾千幾萬。
2、數倉建模方法
數倉建模在哪層建設呢？我們以維度建模為例，建模是在數據源層的下一層進行建設，在上節的分層架構中，就是在DW層進行數倉建模，所以DW層是數倉建設的核心層。
那數倉建模怎麼建呢？其實數據倉庫的建模方法有很多種，每一種建模方法代表了哲學上的一個觀點，代表了一種歸納、概括世界的一種方法。常見的有 範式建模法、維度建模法、實體建模法等，每種方法從本質上將是從不同的角度看待業務中的問題。
1）範式建模法（Third Normal Form，3NF）
範式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型資料庫的數據存儲，利用的一種技術層面上的方法。目前，我們在關係型資料庫中的建模方法，大部分採用的是三範式建模法。
範式 是符合某一種級別的關係模式的集合。構造資料庫必須遵循一定的規則，而在關係型資料庫中這種規則就是範式，這一過程也被稱為規範化。目前關係資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、Boyce-Codd範式（BCNF）、第四範式（4NF）和第五範式（5NF）。
在數據倉庫的模型設計中，一般採用第三範式。一個符合第三範式的關係必須具有以下三個條件 :
-
每個屬性值唯一，不具有多義性 ;
-
每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;
-
每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。
範式建模
根據 Inmon 的觀點，數據倉庫模型的建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關係型資料庫上的實例化。
2）維度建模法（Dimensional Modeling）
維度模型是數據倉庫領域另一位大師Ralph Kimall所倡導，他的《數據倉庫工具箱》是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。
維度建模
典型的代表是我們比較熟知的星形模型（Star-schema），以及在一些特殊場景下適用的雪花模型（Snow-schema）。
維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）。其最簡單的描述就是，按照事實表、維度表來構建數據倉庫、數據集市。
3）實體建模法（Entity Modeling）
實體建模法並不是數據倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關係組成。那麼我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們數據建模需要做的工作。
雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件，說明，如下圖所示：
實體建模
上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這裡可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。
3、維度建模詳解
目前在互聯網公司最常用的建模方法就是維度建模，我們將重點講解！
維度建模是專門應用於分析型資料庫、數據倉庫、數據集市建模的方法。數據集市可以理解為是一種"小型數據倉庫"。
我們先不著急開始維度建模，先來瞭解下維度建模中表的類型和維度建模的模式之後再開始建模，這樣能夠讓我們深刻理解！
1）維度建模中表的類型
維度建模分為兩種表：事實表和維度表：
-
事實表：必然存在的一些數據，像採集的日誌文件，訂單表，都可以作為事實表
特征：是一堆主鍵的集合，每個主鍵對應維度表中的一條記錄， 客觀存在的，根據主題確定出需要使用的數據
-
維度表：維度就是所分析的數據的一個量，維度表就是以合適的角度來創建的表，分析問題的一個角度：時間、地域、終端、用戶等角度。
①事實表
發生在現實世界中的操作型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實表行對應一個度量事件，反之亦然。
事實表表示對分析主題的度量。比如一次購買行為我們就可以理解為是一個事實。
事實與維度
圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。事實表的特征：表裡沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外鍵，可與維度表關聯。事實表的度量通常是數值類型，且記錄數會不斷增加，表數據規模迅速增長。
明細表（寬表）：
事實表的數據中，有些屬性共同組成了一個欄位（糅合在一起），比如年月日時分秒構成了時間,當需要根據某一屬性進行分組統計的時候，需要截取拼接之類的操作，效率極低。如：
