一、數據倉庫的用途

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

二、數倉運行架構圖

三、數據集市與數倉的區別

數據集市（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）：

基于維度建模理念思想，建立整個企業的一致性維度。降低數據計算口徑和算法不統一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應。

主要使用 MySQL、Hbase、Redis 三種存儲引擎，對于維表數據比較少的情況可以使用 MySQL，對于單條數據大小比較小，查詢 QPS 比較高的情況，可以使用 Redis 存儲，降低機器內存資源占用，對于數據量比較大，對維表數據變化不是特別敏感的場景，可以使用 HBase 存儲。

• 數倉明細層（DWD）：

ODS 層經過清洗，落地這一層，一般是最細粒度。

以業務過程作為建模驅動，**基于每個具體的業務過程特點，構建最細粒度的明細層事實表。**可以結合企業的數據使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。

• 數據匯總層（DWS）：

對 DWD 層的輕微聚合，對一些可累加的指標進行聚合，增加復用性。

以分析的主題對象作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段物理化模型。構建命名規范、口徑一致的統計指標，為上層提供公共指標，建立匯總寬表、明細事實表。公共匯總粒度事實層的表通常也被稱為匯總邏輯表，用于存放派生指標數據。

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是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果。二者的主要區別對比如下表所示。

對比屬性	OLTP	OLAP
讀特性	每次查詢只返回少量記錄	對大量記錄進行匯總
寫特性	隨機、低延時寫入用戶的輸入	批量導入
使用場景	用戶，Java?EE項目	內部分析師，為決策提供支持
數據表征	最新數據狀態	隨時間變化的歷史狀態
數據規模	GB	TB到PB

2.1 關系建模

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

2.2?維度建模

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

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

3.?維度表和事實表

3.1?維度表

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

在維度表中，每個表都包含獨立于其他維度表的事實特性，例如，客戶維度表包含有關客戶的數據。維度表中的列字段可以將信息分為不同層次的結構級。

維表的特征：

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

時間維度表：

日期ID	day?of?week	day?of?year	季度	節假日
2020-01-01	2	1	1	元旦
2020-01-02	3	2	1	無
2020-01-03	4	3	1	無
2020-01-04	5	4	1	無
2020-01-05	6	5	1	無

3.2?事實表

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

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

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

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

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

事實表的特征：

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

1）事務型事實表

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

2）周期型快照事實表

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

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

3）累積型快照事實表

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

訂單id	用戶id	下單時間	打包時間	發貨時間	簽收時間	訂單金額
		3-8	3-8	3-9	3-10

4. 維度模型分類

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

4.1 星型模型

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

4.2 雪花模型

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

4.3 星座模型

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

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

4.4 模型的選擇

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

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

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

總結

以上是生活随笔為你收集整理的Hive之数仓的分层及建模理论的全部內容，希望文章能夠幫你解決所遇到的問題。

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