數倉建設原則探討

阿新 • • 發佈：2021-11-11

一、資料模型架構原則

1. 數倉分層原則

優秀可靠的數倉體系，往往需要清晰的資料分層結構，即要保證資料層的穩定又要遮蔽對下游的影響，並且要避免鏈路過長。那麼問題來了，一直在講數倉要分層，那數倉分幾層最好？

目前市場上主流的分層方式眼花繚亂，不過看事情不能只看表面，還要看到內在的規律，不能為了分層而分層，沒有最好的，只有適合的。

分層是以解決當前業務快速的資料支撐為目的，為未來抽象出共性的框架並能夠賦能給其他業務線，同時為業務發展提供穩定、準確的資料支撐，並能夠按照已有的模型為新業務發展提供方向，也就是資料驅動和賦能。

一個好的分層架構，要有以下好處：

清晰資料結構；
資料血緣追蹤；
減少重複開發；

資料關係條理化；
遮蔽原始資料的影響。

數倉分層要結合公司業務進行，並且需要清晰明確各層職責，一般採用如下分層結構：

數倉建模在哪層建設呢？我們以維度建模為例，建模是在資料來源層的下一層進行建設，在上圖中，就是在DW層進行數倉建模，所以DW層是數倉建設的核心層。

下面詳細闡述下每層建設規範，和上圖的分層稍微有些區別：

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）層。

1) 資料明細層：DWD（Data Warehouse Detail）

該層一般保持和 ODS 層一樣的資料粒度，並且提供一定的資料質量保證。DWD 層要做的就是將資料清理、整合、規範化、髒資料、垃圾資料、規範不一致的、狀態定義不一致的、命名不規範的資料都會被處理

。

同時，為了提高資料明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。

另外，在該層也會做一部分的資料聚合，將相同主題的資料彙集到一張表中，提高資料的可用性。

2) 資料中間層：DWM（Data WareHouse Middle）

該層會在 DWD 層的資料基礎上，資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的複用性，減少重複加工。

直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。

在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然後再拼接成一張 DWS 的寬表。由於寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的資料再放在 DWS 亦可。

3) 資料服務層：DWS（Data WareHouse Servce）

DWS 層為公共彙總層，會進行輕度彙總，粒度比明細資料稍粗，基於 DWD 層上的基礎資料，整合彙總成分析某一個主題域的服務資料，一般是寬表。DWS 層應覆蓋 80% 的應用場景。又稱資料集市或寬表。

按照業務劃分，如主題域流量、訂單、使用者等，生成欄位比較多的寬表，用於提供後續的業務查詢，OLAP 分析，資料分發等。

一般來講，該層的資料表會相對比較少，一張表會涵蓋比較多的業務內容，由於其欄位較多，因此一般也會稱該層的表為寬表。

3. 資料應用層：APP（Application）

在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、 PostgreSql、Redis 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料探勘使用。比如我們經常說的報表資料，一般就放在這裡。

4. 維表層（Dimension）

如果維表過多，也可針對維表設計單獨一層，維表層主要包含兩部分資料：

高基數維度資料：一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。

低基數維度資料：一般是配置表，比如列舉值對應的中文含義，或者日期維表。資料量可能是個位數或者幾千幾萬。

2. 主題域劃分原則

1) 按照業務或業務過程劃分

業務容易理解，就是指的功能模組/業務線。

業務過程：指企業的業務活動事件，如下單、支付、退款都是業務過程。不過需要注意的是，一個業務過程是一個不可拆分的行為事件，通俗的講，業務過程就是企業活動中的事件。

2) 按照資料域劃分

資料域是指面向業務分析，將業務過程或者維度進行抽象的集合。其中，業務過程可以概括為一個個不可拆分的行為事件，在業務過程下，可以定義指標，維度是指度量的環境，如買家下單事件，買家是維度。為保障整個體系的生命力，資料域是需要抽象提煉，並且長期維護和更新的，但不輕易變動。在劃分資料域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的資料域中和擴充套件新的資料域。

3. 資料模型設計原則

1) 高內聚、低耦合

即主題內部高內聚、不同主題間低耦合。明細層按照業務過程劃分主題，彙總層按照“實體+ 活動”劃分不同分析主題，應用層根據應用需求劃分不同應用主題。

2) 核心模型和擴充套件模型要分離

建立核心模型與擴充套件模型體系，核心模型包括的欄位支援常用的核心業務，擴充套件模型包括的欄位支援個性化或少量應用的需要，不能讓擴充套件模型的欄位過度侵入核心模型，以免破壞核心模型的架構簡潔性與可維護性。

3) 公共處理邏輯下沉及單一

越是底層公用的處理邏輯越應該在資料排程依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用實現，不要讓公共邏輯多處同時存在。

4) 成本與效能平衡

適當的資料冗餘可換取查詢和重新整理效能，不宜過度冗餘與資料複製。

5) 資料可回滾

處理邏輯不變，在不同時間多次執行資料結果確定不變。

二、數倉公共開發規範

1. 層次呼叫規範

穩定業務按照標準的資料流向進行開發，即 ODS –> DWD –> DWS –> APP。非穩定業務或探索性需求，可以遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 兩個模型資料流。

在保障了資料鏈路的合理性之後，也必須保證模型分層引用原則：

正常流向：ODS -> DWD -> DWM -> DWS -> APP，當出現 ODS -> DWD -> DWS -> APP 這種關係時，說明主題域未覆蓋全。應將 DWD 資料落到 DWM 中，對於使用頻度非常低的表允許 DWD -> DWS。
儘量避免出現 DWS 寬表中使用 DWD 又使用（該 DWD 所歸屬主題域）DWM 的表。
同一主題域內對於 DWM 生成 DWM 的表，原則上要儘量避免，否則會影響 ETL 的效率。
DWM、DWS 和 APP 中禁止直接使用 ODS 的表， ODS 的表只能被 DWD 引用。
禁止出現反向依賴，例如 DWM 的表依賴 DWS 的表。

舉例：

2. 資料型別規範

需統一規定不同的資料的資料型別，嚴格按照規定的資料型別執行：

金額：double 或使用 decimal(28,6) 控制精度等，明確單位是分還是元。
字串：string。
id類：bigint。
時間：string。
狀態：string

3. 資料冗餘規範

寬表的冗餘欄位要確保：

冗餘欄位要使用高頻，下游3個或以上使用。
冗餘欄位引入不應造成本身資料產生過多的延後。
冗餘欄位和已有欄位的重複率不應過大，原則上不應超過60%，如需要可以選擇join或原表拓展。

4. NULL欄位處理規範

對於維度欄位，需設定為-1
對於指標欄位，需設定為 0

5. 指標口徑規範

保證主題域內，指標口徑一致，無歧義。

通過資料分層，提供統一的資料出口，統一對外輸出的資料口徑，避免同一指標不同口徑的情況發生。

1) 指標梳理

指標口徑的不一致使得資料使用的成本極高，經常出現口徑打架、反覆核對資料的問題。在資料治理中，我們將需求梳理到的所有指標進行進一步梳理，明確其口徑，如果存在兩個指標名稱相同，但口徑不一致，先判斷是否是進行合併，如需要同時存在，那麼在命名上必須能夠區分開。

2) 指標管理

指標管理分為原子指標維護和派生指標維護。

原子指標：

選擇原子指標的歸屬產線、業務板塊、資料域、業務過程
選擇原子指標的統計資料來源於該業務過程下的原始資料來源
錄入原子指標的英文名稱、中文名稱、概述
填寫指標函式
系統根據指標函式自動生成原子指標的定義表示式
系統根據指標定義表示式以及資料來源表生成原子指標SQL

派生指標：

在原子指標的基礎之上選擇了一些維度或者修飾限定詞。

6. 資料表處理規範

1) 增量表

新增資料，增量資料是上次匯出之後的新資料。

記錄每次增加的量，而不是總量；
增量表，只報變化量，無變化不用報；
每天一個分割槽。

2) 全量表

每天的所有的最新狀態的資料。

全量表，有無變化，都要報；
每次上報的資料都是所有的資料（變化的 + 沒有變化的）；
只有一個分割槽。

3) 快照表

按日分割槽，記錄截止資料日期的全量資料。

快照表，有無變化，都要報；
每次上報的資料都是所有的資料（變化的 + 沒有變化的）；
一天一個分割槽。

4) 拉鍊表

記錄截止資料日期的全量資料。

記錄一個事物從開始，一直到當前狀態的所有變化的資訊；
拉鍊表每次上報的都是歷史記錄的最終狀態，是記錄在當前時刻的歷史總量；
當前記錄存的是當前時間之前的所有歷史記錄的最後變化量（總量）；
只有一個分割槽。

7. 表的生命週期管理

這部分主要是要通過對歷史資料的等級劃分與對錶型別的劃分生成相應的生命週期管理矩陣。

1) 歷史資料等級劃分

主要將歷史資料劃分P0、Pl、P2、P3 四個等級，其具體定義如下：

P0：非常重要的主題域資料和非常重要的應用資料，具有不可恢復性，如交易、日誌、集團 KPI 資料、 IPO 關聯表。
Pl：重要的業務資料和重要的應用資料，具有不可恢復性，如重要的業務產品資料。
P2：重要的業務資料和重要的應用資料，具有可恢復性，如交易線 ETL 產生的中間過程資料。
P3：不重要的業務資料和不重要的應用資料，具有可恢復性，如某些 SNS 產品報表。

2) 表型別劃分

事件型流水錶（增量表）

事件型流水錶（增量表）指資料無重複或者無主鍵資料，如日誌。

事件型映象表（增量表）

事件型映象表（增量表）指業務過程性資料，有主鍵，但是對於同樣主鍵的屬性會發生緩慢變化，如交易、訂單狀態與時間會根據業務發生變更。

維表

維表包括維度與維度屬性資料，如使用者表、商品表。

Merge 全量表

Merge 全量表包括業務過程性資料或者維表資料。由於資料本身有新增的或者發生狀態變更，對於同樣主鍵的資料可能會保留多份，因此可以對這些資料根據主鍵進行 Merge 操作，主鍵對應的屬性只會保留最新狀態，歷史狀態保留在前一天分割槽中。例如，使用者表、交易表等都可以進行 Merge 操作。

ETL 臨時表

ETL 臨時表是指 ETL 處理過程中產生的臨時表資料，一般不建議保留，最多7天。

TT 臨時資料

TT 拉取的資料和 DbSync 產生的臨時資料最終會流轉到 DS 層，ODS 層資料作為原始資料保留下來，從而使得 TT&DbSync 上游資料成為臨時資料。這類資料不建議保留很長時間，生命週期預設設定為 93天，可以根據實際情況適當減少保留天數。

7. 普通全量表

很多小業務資料或者產品資料，BI一般是直接全量拉取，這種方式效率快，對儲存壓力也不是很大，而且表保留很長時間，可以根據歷史資料等級確定保留策略。

通過上述歷史資料等級劃分與表型別劃分，生成相應的生命週期管理矩陣，如下表所示：

三、數倉各層開發規範

1. ODS層設計規範

同步規範：

一個系統源表只允許同步一次；
全量初始化同步和增量同步處理邏輯要清晰；
以統計日期和時間進行分割槽儲存；
目標表欄位在源表不存在時要自動填充處理。

表分類與生命週期：

ods流水全量表：

不可再生的永久儲存；
日誌可按留存要求；
按需設定保留特殊日期資料；
按需設定保留特殊月份資料；

ods映象型全量表：

推薦按天儲存；
對歷史變化進行保留；
最新資料儲存在最大分割槽；
歷史資料按需保留；

ods增量資料：

推薦按天儲存；
有對應全量表的，建議只保留14天資料；
無對應全量表的，永久保留；

ods的etl過程中的臨時表：

推薦按需保留；
最多保留7天；
建議用完即刪，下次使用再生成；

BDSync非去重資料：

通過中間層保留，預設用完即刪，不建議保留。

資料質量：

全量表必須配置唯一性欄位標識；
對分割槽空資料進行監控；
對列舉型別欄位，進行列舉值變化和分佈監控；
ods表資料量級和記錄數做環比監控；
ods全表都必須要有註釋；

2. 公共維度層設計規範

1) 設計準則

一致性

共維度在不同的物理表中的欄位名稱、資料型別、資料內容必須保持一致（歷史原因不一致，要做好版本控制）

維度的組合與拆分

組合原則：

將維度與關聯性強的欄位進行組合，一起查詢，一起展示，兩個維度必須具有天然的關係，如：商品的基本屬性和所屬品牌。

無相關性：如一些使用頻率較小的雜項維度，可以構建一個集合雜項維度的特殊屬性。

行為維度：經過計算的度量，但下游當維度處理，例：點選量 0-1000,100-1000等，可以做聚合分類。

拆分與冗餘：

針對重要性，業務相關性、源、使用頻率等可分為核心表、擴充套件表。

資料記錄較大的維度，可以適當冗餘一些子集。

2) 儲存及生命週期管理

建議按天分割槽。

3個月內最大訪問跨度<=4天時，建議保留最近7天分割槽；
3個月內最大訪問跨度<=12天時，建議保留最近15天分割槽；
3個月內最大訪問跨度<=30天時，建議保留最近33天分割槽；
3個月內最大訪問跨度<=90天時，建議保留最近120天分割槽；
3個月內最大訪問跨度<=180天時，建議保留最近240天分割槽；
3個月內最大訪問跨度<=300天時，建議保留最近400天分割槽；

3. DWD明細層設計規範

1) 儲存及生命週期管理

建議按天分割槽。

3個月內最大訪問跨度<=4天時，建議保留最近7天分割槽；
3個月內最大訪問跨度<=12天時，建議保留最近15天分割槽；
3個月內最大訪問跨度<=30天時，建議保留最近33天分割槽；
3個月內最大訪問跨度<=90天時，建議保留最近120天分割槽；
3個月內最大訪問跨度<=180天時，建議保留最近240天分割槽；
3個月內最大訪問跨度<=300天時，建議保留最近400天分割槽；

2) 事務型事實表設計準則

基於資料應用需求的分析設計事務型事實表，結合下游較大的針對某個業務過程和分析指標需求，可考慮基於某個事件過程構建事務型實時表；
一般選用事件的發生日期或時間作為分割槽欄位，便於掃描和裁剪；
冗餘子集原則，有利於降低後續IO開銷；
明細層事實表維度退化，減少後續使用join成本。

3) 週期快照事實表

週期快照事實表中的每行彙總了發生在某一標準週期，如某一天、某周、某月的多個度量事件。
粒度是週期性的，不是個體的事務。
通常包含許多事實，因為任何與事實表粒度一致的度量事件都是被允許的。

4) 累積快照事實表

多個業務過程聯合分析而構建的事實表，如採購單的流轉環節。
用於分析事件時間和時間之間的間隔週期。
少量的且當前事務型不支援的，如關閉、發貨等相關的統計。

4. DWS公共彙總層設計規範

資料倉庫的效能是資料倉庫建設是否成功的重要標準之一。聚集主要是通過彙總明細粒度資料來獲得改進查詢效能的效果。通過訪問聚集資料，可以減少資料庫在響應查詢時必須執行的工作量，能夠快速響應使用者的查詢，同時有利於減少不同用訪問明細資料帶來的結果不一致問題。

1) 聚集的基本原則

一致性。聚集表必須提供與查詢明細粒度資料一致的查詢結果。
避免單一表設計。不要在同一個表中儲存不同層次的聚集資料。
聚集粒度可不同。聚集並不需要保持與原始明細粒度資料一樣的粒度，聚集只關心所需要查詢的維度。

2) 聚集的基本步驟

第一步：確定聚集維度

在原始明細模型中會存在多個描述事實的維度，如日期、商品類別、賣家等，這時候需要確定根據什麼維度聚集，如果只關心商品的交易額情況，那麼就可以根據商品維度聚集資料。

第二步：確定一致性上鑽

這時候要關心是按月彙總還是按天彙總，是按照商品彙總還是按照類目彙總，如果按照類目彙總，還需要關心是按照大類彙總還是小類彙總。當然，我們要做的只是瞭解使用者需要什麼，然後按照他們想要的進行聚集。

第三步：確定聚集事實

在原始明細模型中可能會有多個事實的度量，比如在交易中有交易額、交易數量等，這時候要明確是按照交易額彙總還是按照成交數量彙總。

3) 公共彙總層設計原則

除了聚集基本的原則外，公共彙總層還必須遵循以下原則：

資料公用性。彙總的聚集會有第三者使用嗎？基於某個維度的聚集是不是經常用於資料分析中？如果答案是肯定的，那麼就有必要把明細資料經過彙總沉澱到聚集表中。
不跨資料域。資料域是在較高層次上對資料進行分類聚集的抽象。如以業務
區分統計週期。在表的命名上要能說明資料的統計週期，如_Id表示最近1天，_td表示截至當天，_nd表示最近N天。

四、數倉命名規範

1. 詞根設計規範

詞根屬於數倉建設中的規範，屬於元資料管理的範疇，現在把這個劃到資料治理的一部分。完整的數倉建設是包含資料治理的，只是現在談到數倉偏向於資料建模，而談到資料治理，更多的是關於資料規範、資料管理。

表命名，其實在很大程度上是對元資料描述的一種體現，表命名規範越完善，我們能從表名獲取到的資訊就越多。比如：一部分業務是關於貨架的，英文名是：rack， rack 就是一個詞根，那我們就在所有的表、欄位等用到的地方都叫 rack，不要叫成別的什麼。這就是詞根的作用，用來統一命名，表達同一個含義。

指標體系中有很多“率”的指標，都可以拆解成 XXX+率，率可以叫 rate，那我們所有的指標都叫做 XXX+rate。

詞根：可以用來統一表名、欄位名、主題域名等等。

舉例：以流程圖的方式來展示，更加直觀和易懂，本圖側重 dwm 層表的命名規範，其餘命名是類似的道理：

第一個判斷條件是該表的用途，是中間表、原始日誌還是業務展示用的表如果該表被判斷為中間表，就會走入下一個判斷條件：表是否有 group 操作通過是否有 group 操作來判斷該表該劃分在 dwd 層還是 dwm 和 dws 層如果不是 dwd 層，則需要判斷該表是否是多個行為的彙總表（即寬表）最後再分別填上事業群、部門、業務線、自定義名稱和更新頻率等資訊即可。

分層：表的使用範圍

事業群和部門：生產該表或者該資料的團隊

業務線：表明該資料是哪個產品或者業務線相關

主題域：分析問題的角度，物件實體

自定義：一般會盡可能多描述該表的資訊，比如活躍表、留存表等

更新週期：比如說天級還是月級更新

數倉表的命名規範如下：

1. 數倉層次:

公用維度：dim

DM層：dm

ODS層：ods

DWD層：dwd

DWS層：dws

2. 週期/資料範圍：

日快照：d

增量：i

全量：f

周：w

拉鍊表：l

非分割槽全量表：a

2. 表命名規範

1) 常規表

常規表是我們需要固化的表，是正式使用的表，是目前一段時間內需要去維護去完善的表。

規範：分層字首[dwd|dws|ads]_部門_業務域_主題域_XXX_更新週期|資料範圍

業務域、主題域我們都可以用詞根的方式列舉清楚，不斷完善。

更新週期主要的是時間粒度、日、月、年、周等。

2) 中間表

中間表一般出現在 Job 中，是 Job 中臨時儲存的中間資料的表，中間表的作用域只限於當前 Job 執行過程中，Job 一旦執行完成，該中間表的使命就完成了，是可以刪除的（按照自己公司的場景自由選擇，以前公司會保留幾天的中間表資料，用來排查問題）。

規範：mid_table_name_[0~9|dim]

table_name 是我們任務中目標表的名字，通常來說一個任務只有一個目標表。這裡加上表名，是為了防止自由發揮的時候表名衝突，而末尾大家可以選擇自由發揮，起一些有意義的名字，或者簡單粗暴，使用數字代替，各有優劣吧，謹慎選擇。

通常會遇到需要補全維度的表，這裡使用 dim 結尾。

如果要保留歷史的中間表，可以加上日期或者時間戳。

3) 臨時表

臨時表是臨時測試的表，是臨時使用一次的表，就是暫時儲存下資料看看，後續一般不再使用的表，是可以隨時刪除的表。

規範：tmp_xxx

只要加上 tmp 開頭即可，其他名字隨意，注意 tmp 開頭的表不要用來實際使用，只是測試驗證而已。

4) 維度表

維度表是基於底層資料，抽象出來的描述類的表。維度表可以自動從底層表抽象出來，也可以手工來維護。

規範：dim_xxx

維度表，統一以 dim 開頭，後面加上，對該指標的描述。

5) 手工表

手工表是手工維護的表，手工初始化一次之後，一般不會自動改變，後面變更，也是手工來維護。

一般來說，手工的資料粒度是偏細的，所以暫時統一放在 dwd 層，後面如果有目標值或者其他型別手工資料，再根據實際情況分層。

規範：dwd_業務域_manual_xxx

手工表，增加特殊的主題域，manual，表示手工維護表。

3. 指標命名規範

1) 公共規則

所有單詞小寫
單詞之間下劃線分割（反例：appName 或 AppName）
可讀性優於長度 (詞根，避免出現同一個指標，命名一致性)
禁止使用 sql 關鍵字，如欄位名與關鍵字衝突時 +col
數量欄位字尾 _cnt 等標識...
金額欄位字尾 _price 標識
天分割槽使用欄位 dt，格式統一（yyyymmdd 或 yyyy-mm-dd）
小時分割槽使用欄位 hh，範圍（00-23）
分鐘分割槽使用欄位 mi，範圍（00-59）
布林型別標識：is_{業務}，不允許出現空值

2) 指標命名規範

結合指標的特性以及詞根管理規範，將指標進行結構化處理。

基礎指標詞根，即所有指標必須包含以下基礎詞根：

業務修飾詞，用於描述業務場景的詞彙，例如trade-交易。

3.日期修飾詞，用於修飾業務發生的時間區間。

4.聚合修飾詞，對結果進行聚集操作。

5.基礎指標，單一的業務修飾詞+基礎指標詞根構建基礎指標，例如：交易金額-trade_amt。

6.派生指標，多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性，例如：安裝門店數量-install_poi_cnt。

7.普通指標命名規範，與欄位命名規範一致，由詞彙轉換即可以。