一、資料倉庫的用途

• 整合公司所有業務資料，建立統一的資料中心
• 產生業務報表，用于作出決策
• 為網站運營提供運營上的資料支持
• 可以作為各個業務的資料源，形成業務資料互相反饋的良性回圈
• 分析用戶行為資料，通過資料挖掘來降低投入成本，提高投入效果
• 開發資料產品，直接或間接地為公司盈利

二、數倉運行架構圖

三、資料集市與數倉的區別

資料集市（Data Market）：是一種微型的資料倉庫，它通常有更少的資料，更少的主題區域，以及更少的歷史資料，因此是部門級的，一般只能為某個區域范圍內的管理人員服務，

資料倉庫（Data Warehouse）：資料倉庫是企業級的，能為整個企業各個部門的運行提供決策支持手段，

四、數倉分層

1. 分層原因

• 把復雜問題簡單化：將復雜的任務分解成多層來完成，每一層只處理簡單任務，方便定位問題，
• 減少重復開發：規范資料分層，通過中間層資料，能夠減少大量的重復計算，增加一次計算結果的復用性，
• 隔離原始資料：不論是資料的例外還是資料的敏感性，使真實資料與統計資料解耦開，

2. 基本分層模型

ODS（資料源層，原始資料） – ETL --> DWD（資料明細層） – hive sql --> DWS（資料匯總） – sqoop --> ADS（資料應用：報表、用戶畫像）

3. 資料倉庫分層

3.1 數倉分層概述

在阿里巴巴的資料體系中，建議將資料倉庫分為三層，自下而上為：

資料引入層ODS（Operation Data Store）：存放未經過處理的原始資料至資料倉庫系統，結構上與源系統保持一致，是資料倉庫的資料準備區，主要完成基礎資料引入到MaxCompute的職責，同時記錄基礎資料的歷史變化，

資料公共層CDM（Common Data Model，又稱通用資料模型層）:包括DIM維度表、DWD和DWS，由ODS層資料加工而成，主要完成資料加工與整合，建立一致性的維度，構建可復用的面向分析和統計的明細事實表，以及匯總公共粒度的指標，根據目前業務特點，暫時只建立DWD層

• 明細粒度事實層（DWD）：以業務程序作為建模驅動，基于每個具體的業務程序特點，構建最細粒度的明細層事實表，可以結合企業的資料使用特點，將明細事實表的某些重要維度屬性欄位做適當冗余，即寬表化處理，
• 資料中間層：DWM（Data WareHouse Middle）該層會在DWD層的資料基礎上，對資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的復用性，減少重復加工，直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標，
• 公共匯總粒度事實層（DWS）：以分析的主題物件作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段物理化模型，構建命名規范、口徑一致的統計指標，為上層提供公共指標，建立匯總寬表、明細事實表，
• 公共維度層（DIM）：基于維度建模理念思想，建立整個企業的一致性維度，降低資料計算口徑和演算法不統一風險，公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應，

資料應用層ADS（Application Data Service）：存放資料產品個性化的統計指標資料，根據CDM與ODS層加工生成，

中英文及簡寫：

資料引入層（ODS，Operation Data Store）
資料公共層（CDM，Common Data Model）
公共維度層（DIM，Dimension）
數倉明細層（DWD，Data Warehouse Detail）
資料匯總層（DWS，Data Warehouse Service）
資料應用層（ADS，Application Data Service），

3.2 各層級用途

1) 資料引入層（ODS，Operation Data Store）：將原始資料幾乎無處理的存放在資料倉庫系統，結構上與源系統基本保持一致，是資料倉庫的資料準備區，原始資料，主要是埋點資料（日志資料）和業務操作資料（binlong），資料源主要是 Mysql、HDFS、Kafka 等

2) 資料公共層（CDM，Common Data Model，又稱通用資料模型層），包括 DIM 維度表、DWD 和 DWS，由ODS 層資料加工而成，主要完成資料加工與整合，建立一致性的維度，構建可復用的面向分析和統計的明細事實表，以及匯總公共粒度的指標，這一層里又包括三層：

• 公共維度層（DIM）：

1. 基于維度建模理念思想，建立整個企業的一致性維度，降低資料計算口徑和演算法不統一風險，公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應，
2. 主要使用 MySQL、Hbase、Redis 三種存盤引擎，對于維表資料比較少的情況可以使用 MySQL，對于單條資料大小比較小，查詢 QPS 比較高的情況，可以使用 Redis 存盤，降低機器記憶體資源占用，對于資料量比較大，對維表資料變化不是特別敏感的場景，可以使用 HBase 存盤，

• 數倉明細層（DWD）：

1. ODS 層經過清洗，落地這一層，一般是最細粒度，
2. 以業務程序作為建模驅動，**基于每個具體的業務程序特點，構建最細粒度的明細層事實表，**可以結合企業的資料使用特點，將明細事實表的某些重要維度屬性欄位做適當冗余，即寬表化處理，

• 資料匯總層（DWS）：

1. 對 DWD 層的輕微聚合，對一些可累加的指標進行聚合，增加復用性，
2. 以分析的主題物件作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段物理化模型，構建命名規范、口徑一致的統計指標，為上層提供公共指標，建立匯總寬表、明細事實表，公共匯總粒度事實層的表通常也被稱為匯總邏輯表，用于存放派生指標資料，

3) 資料應用層（ADS，Application Data Service）：存放資料產品個性化的統計指標資料，根據 CDM 與 ODS 層加工生成，

4. 開發規范

4.1 命名規則

1) ods 層

增量資料： {project_name}.ods_{資料來源}_{源系統表名}_delta
全量資料： {project_name}.ods_{資料來源}_{源系統表名}

資料來源說明：
01 -> hdfs 資料
02 -> mysql 資料
03 -> redis 資料
04 -> mongodb 資料
05 -> tidb 資料

舉例如下：
行為日志表： ods_01_action_log
用戶表： ods_02_user

2) dim 層

公共區域維表： {project_name}.dim_pub_{自定義命名標簽}
具體業務維表： {project_name}.dim_{業務縮寫}_{自定義命名標簽}

舉例如下：
公共區域維表： dim_pub_area
公共時間維表： dim_pub_date
A公司電商板塊的商品全量表： dim_asale_itm

3) dwd 層

多個業務公共表： {project_name}.dwd_pub_{自定義命名標簽}
具體業務資料增量表： {project_name}.dwd_{業務縮寫}_{自定義命名標簽}_di
具體業務資料全量表： {project_name}.dwd_{業務縮寫}_{自定義命名標簽}_df

舉例如下：
交易會員資訊事實表：ods_asale_trd_mbr_di
交易商品資訊事實表：dwd_asale_trd_itm_di
交易訂單資訊事實表：dwd_asale_trd_ord_di

4) dws 層

多個業務公共表： {project_name}.dws_pub_{自定義命名標簽}
具體業務最近一天匯總事實表： {project_name}.dws_{業務縮寫}_{自定義命名標簽}_1d
具體業務最近N天匯總事實表： {project_name}.dws_{業務縮寫}_{自定義命名標簽}_nd
具體業務歷史截至當天匯總表： {project_name}.dws_{業務縮寫}_{自定義命名標簽}_td
具體業務小時匯總表： {project_name}.dws_{業務縮寫}_{自定義命名標簽}_hh

舉例如下：
dws_asale_trd_byr_subpay_1d（A電商公司買家粒度交易分階段付款一榷訓總事實表）
dws_asale_trd_byr_subpay_td（A電商公司買家粒度分階段付款截至當榷訓總表）
dws_asale_trd_byr_cod_nd（A電商公司買家粒度貨到付款交易匯總事實表）
dws_asale_itm_slr_td（A電商公司賣家粒度商品截至當日存量匯總表）
dws_asale_itm_slr_hh（A電商公司賣家粒度商品小時匯總表）---維度為小時
dws_asale_itm_slr_mm（A電商公司賣家粒度商品分鐘匯總表）---維度為分鐘

5) ads 層

{project_name}.ads_{業務縮寫}_{自定義命名標簽}

舉例如下：
訂單統計表： ads_nshop_order_form
訂單支付統計： ads_nshop_orderpay_form

4.2 資料來源介紹

1) 業務資料
業務資料往往產生于事務型程序處理，所以一般存盤在關系型資料庫中，如 mysql、oracle，
業務資料源： 用戶基本資訊、商品分類資訊、商品資訊、店鋪資訊、訂單資料、訂單支付資訊、活動資訊、物流資訊等

2) 埋點日志

埋點日志相對業務資料是用于資料分析、挖掘需求，一般以日志形式存盤于日志檔案中，隨后通過采集落地分布式存盤介質中如 hdfs、hbase，
用戶行為日志： 用戶瀏覽、用戶點評、用戶關注、用戶搜索、用戶投訴、用戶咨詢

3) 外部資料

當前一般公司都會通過線上廣告來進行獲客，與三方公司合作更多的提取相關資料來進行深度刻畫用戶及用戶群體，另外爬取公共公開資料也是分析運營的常用方式，
外部資料源： 廣告投放資料、爬蟲資料、三方介面資料

5. 分層的誤區

數倉層內部的劃分不是為了分層而分層，分層是為了解決 ETL 任務及作業流的組織、資料的流向、讀寫權限的控制、不同需求的滿足等各類問題，

業界較為通行的做法將整個數倉層（DW）又劃分成了 dwd、dwb、dws、dim、mid 等等很多層，然而我們卻始終說不清楚這幾層之間清晰的界限是什么，或者說我們能說清楚它們之間的界限，復雜的業務場景卻令我們無法真正落地執行，

所以資料分層這塊一般來說 ODS、DWD、DWS 這三層是最基礎的：

至于DW層如何進行切分，是根據具體的業務需求和公司場景自己去定義，一般來說需要：

• 分層是解決資料流向和快速支撐業務的目的；
• 必須按照主題域和業務域進行貫穿；
• 層級之間不可逆向依賴，
• 如果依賴ODS層資料可以完成資料支撐，那么業務方直接使用落地層這也有利于快速、低成本地進行一些資料方面的探索和嘗試，
• 確定分層規范后，后續最好都遵循這個架構，約定成俗即可；
• 血緣關系、資料依賴、資料字典、資料命名規范等配套先行；

DW 內的分層沒有最正確的，只有最適合你的，

6. 寬表的誤區

在數倉層開始引入了寬表，所謂寬表，迄今為止并沒有一個明確的定義，通常做法是把很多的維度、事實上卷（roll-up）或者下鉆（drill-down）之后關聯到某一個事實表中，形成一張既包含了大量維度又包含了相關事實的表，

寬表的使用，有其一定的便利性，使用方不需要再去考慮跟維度表的關聯，也不需要了解維度表和事實表是什么東西，
但是隨著業務的增長，我們始終無法預見性地設計和定義寬表究竟該冗余多少維度，也無法清晰地定義出寬表冗余維度的底線在哪里，

一個可能存在的情況是，為了滿足使用上的需求，要不斷地將維表中已經存在的列增加到寬表中，這直接導致了寬表的表結構頻繁發生變動，

目前我們所采用的做法是：

• 根據主題域和業務域，將某個業務的所有節點梳理清楚；
• 將關鍵節點的資料作為事實表依據，然后橫向擴充其他事實表上卷資料（包含一些統計指標），同時縱向的添加該節點上一些主鍵對應的維度；
• 寬表的涉及不依賴具體的業務需求而是根據整體業務線相匹配；
• 盡量用維度建模代替寬表；

為什么說盡量用維度建模代替寬表，就算欄位和資料會冗余，維度建模的方式也會表全量資料的寬表模式較好，原因：

• 維度建模是以某一個既定的事實為依據，既然是事實表，那么這塊的業務如果不變動的情況下，事實表的粒度基本不會改變；
• 事實表和維度表解耦，維度表的變更事實表基本不會影響，結果表也只需要回刷一下資料流程即可；
• 新增維度完全可以按照星型模型或者雪花模型動態添加新維度；
• 維度模型可以作為寬表的基礎，一旦確定全部的資料流程，可以通過維度模型再生成對應寬表進行快速的業務支撐；
  

五、數倉建模

1.范式理論

1.1 范式概念

1）定義

范式可以理解為設計一張資料表的表結構，符合的標準級別、規范和要求，

2）優點

采用范式，可以降低資料的冗余性，

為什么要降低資料冗余性？

（1）十幾年前，磁盤很貴，為了減少磁盤存盤，

（2）以前沒有分布式系統，都是單機，只能增加磁盤，磁盤個數也是有限的

（3）一次修改，需要修改多個表，很難保證資料一致性

3）缺點

范式的缺點是獲取資料時，需要通過Join拼接出最后的資料，

4）分類

目前業界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)，

1.2 函式依賴

1、完全函式依賴

設X、Y是關系R的兩個屬性集合，X'是X的真子集，存在X→Y，但對于每一個X'都有X'!→Y，則稱Y完全函式依賴于X，

比如通過，（學號，課程）推出分數，那么就可以說：分數完全依賴于（學號，課程），

即：通過AB能得出C,但是AB單獨得不出C,那么說C完全依賴于AB，

2、部分函式依賴

假如Y函式依賴于X，但同時Y并不完全函式依賴于X，那么我們就稱Y部分函式依賴于X，

比如通過（學號，課程）推出姓名，因為直接可以通過學號推出姓名，所以姓名部分依賴于（學號，課程）

即：通過AB能得出C,通過A也能得出C，或者通過B也能得出C，那么說C部分依賴于AB，

3、傳遞函式依賴

設X、Y、Z是關系R中互不相同的屬性集合，存在X→Y（Y'!→X），Y→Z，則稱Z傳遞函式依賴于X，

學號推出系名，系名推出系主任，但是系主任推不出學號，系主任主要依賴于系名，這種情況可以說系主任傳遞依賴于學號，

即：通過A得到B，通過B得到C，但是C得不到A，那么說C傳遞依賴于A，

1.3 三范式區分

第一范式

1NF核心原則：屬性不可切割

很明顯上圖所示的表格設計是不符合第一范式的，商品列中的資料不是原子資料項，是可以進行分割的，于是對表格進行修改，讓表格符合第一范式的要求，如下圖所示：

事實上，1NF是所有關系型資料庫的最基本要求，只要在RDBMS中已經存在的資料表，一定是符合1NF的，

第二范式

2NF核心原則：不能存在部分函式依賴

以上表格明顯存在部分依賴，比如，這張表的主鍵是（學號，課名），分數確實完全依賴于（學號，課名），但是姓名并不完全依賴于（學號，課名），

上圖右面表格符合第二范式，去掉了部分函式依賴，

第三范式

3NF核心原則：不能存在傳遞函式依賴

在下圖所示表格中，存在傳遞函式依賴：學號->系名->系主任，但是系主任推不出學號，

上面表需要再次拆解：

2. 關系建模與維度建模

當今的資料處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing），OLTP是傳統的關系型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易，OLAP是資料倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果，二者的主要區別對比如下表所示，

2.1 關系建模

關系模型如圖所示，嚴格遵循第三范式（3NF），從圖中可以看出，較為松散、零碎，物理表數量多，而資料冗余程度低，由于資料分布于眾多的表中，這些資料可以更為靈活地被應用，功能性較強，關系模型主要應用與OLTP系統中，為了保證資料的一致性以及避免冗余，所以大部分業務系統的表都是遵循第三范式的，

2.2 維度建模

維度模型如圖所示，主要應用于OLAP系統中，通常以某一個事實表為中心進行表的組織，主要面向業務，特征是可能存在資料的冗余，但是能方便的得到資料，

關系模型雖然冗余少，但是在大規模資料，跨表分析統計查詢程序中，會造成多表關聯，這會大大降低執行效率，所以通常我們采用維度模型建模，把相關各種表整理成兩種：事實表和維度表兩種，

3. 維度表和事實表

3.1 維度表

維度表：一般是對事實的描述資訊，每一張維表對應現實世界中的一個物件或者概念，例如：用戶、商品、日期、地區等，

在維度表中，每個表都包含獨立于其他維度表的事實特性，例如，客戶維度表包含有關客戶的資料，維度表中的列欄位可以將資訊分為不同層次的結構級，

維表的特征：

• 維表的范圍很寬（具有多個屬性、列比較多）
• 跟事實表相比，行數相對較小：通常< 10萬條
• 內容相對固定：編碼表

時間維度表：

3.2 事實表

事實表：每個資料倉庫都包含一個或者多個事實資料表，事實資料表可能包含業務銷售資料，如現金登記事務所產生的資料，事實資料表通常包含大量的行，事實資料表的主要特點是包含數字資料（事實），并且這些數字資訊可以匯總，以提供有關單位作為歷史的資料，每個事實資料表包含一個由多個部分組成的索引，該索引包含作為外鍵的相關性緯度表的主鍵，而維度表包含事實記錄的特性，事實資料表不應該包含描述性的資訊，也不應該包含除數字度量欄位及使事實與緯度表中對應項的相關索引欄位之外的任何資料，

包含在事實資料表中的“度量值”有兩中：一種是可以累計的度量值，另一種是非累計的度量值，最有用的度量值是可累計的度量值，其累計起來的數字是非常有意義的，用戶可以通過累計度量值獲得匯總資訊，例如，可以匯總具體時間段內一組商店的特定商品的銷售情況，非累計的度量值也可以用于事實資料表，單匯總結果一般是沒有意義的，例如，在一座大廈的不同位置測量溫度時，如果將大廈中所有不同位置的溫度累加是沒有意義的，但是求平均值是有意義的，

一般來說，一個事實資料表都要和一個或多個緯度表相關聯，用戶在利用事實資料表創建多維資料集時，可以使用一個或多個維度表，

事實表中的每行資料代表一個業務事件（下單、支付、退款、評價等），“事實”這個術語表示的是業務事件的度量值（可統計次數、個數、金額等），例如，2020年5月21日，宋老師在京東花了250塊錢買了一雙安踏鞋，維度表：時間、用戶、商品、商家，事實表：250塊錢、一雙

每一個事實表的行包括：具有可加性的數值型的度量值、與維表相連接的外鍵，通常具有兩個和兩個以上的外鍵，

事實表的特征：

• 非常的大
• 內容相對的窄：列數較少（主要是外鍵id和度量值）
• 經常發生變化，每天會新增加很多，

1）事務型事實表

以每個事務或事件為單位，例如一個銷售訂單記錄，一筆支付記錄等，作為事實表里的一行資料，一旦事務被提交，事實表資料被插入，資料就不再進行更改，其更新方式為增量更新，

2）周期型快照事實表

周期型快照事實表中不會保留所有資料，只保留固定時間間隔的資料，例如每天或者每月的銷售額，或每月的賬戶余額等，

例如購物車，有加減商品，隨時都有可能變化，但是我們更關心每天結束時這里面有多少商品，方便我們后期統計分析，

3）累積型快照事實表

累計快照事實表用于跟蹤業務事實的變化，例如，資料倉庫中可能需要累積或者存盤訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業務階段的時間點資料來跟蹤訂單宣告周期的進展情況，當這個業務程序進行時，事實表的記錄也要不斷更新，

4. 維度模型分類

在維度建模的基礎上又分為三種模型：星型模型、雪花模型、星座模型，

4.1 星型模型

星型模型和雪花模型的主要區別在于維度的層級，標準的星型模型維度只有一層，而雪花模型會涉及多級，

4.2 雪花模型

雪花模型，比較靠近3NF，但是無法完全遵守，因為遵循3NF的性能成本太高，

4.3 星座模型

星座模型與前兩種的區別是事實表的數量，星座模型是基于多個事實表，

基本上是很多資料倉庫的常態，因為很多資料倉庫都是多個事實表的，所以星座不星座只反映是否有多個事實表，他們之間是否共享一些維度表，所以星座模型并不和前兩種沖突，

4.4 模型的選擇

首先就是星座不星座這個只跟資料和需求有關系，跟設計沒關系，不用選擇，

星型還是雪花，取決于性能優化，還是靈活更優先，

目前實際企業開發中，不會絕對選擇一種，根據情況靈活組合，甚至并存（一層維度和多層維度都保存），但是整體來看，更傾向于維度更少的星型模型，尤其是Hadoop體系，減少Join就是減少Shuffle，性能差距很大，（關系型資料可以依靠強大的主鍵索引）