Hive之數倉的分層及模組化理論

一、資料倉庫的用途

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

二、數倉運作架構圖

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

資料集市（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是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，并且提供直覺易懂的查詢結果。二者的主要差別對比如下表所示。

對比屬性	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，性能差距很大。（關系型資料可以依靠強大的主鍵索引）