本文將全面講解數倉建設規范，從數據模型規范，到數倉公共規范，數倉各層規范，最后到數倉命名規范，包括表命名，指標字段命名規范等！

目錄：

一、數據模型架構原則

數倉分層原則

主題域劃分原則

數據模型設計原則

二、數倉公共開發規范

層次調用規范

數據類型規范

數據冗余規范

NULL字段處理規范

指標口徑規范

數據表處理規范

表的生命周期管理

三、數倉各層開發規范

ODS層設計規范

公共維度層設計規范

DWD明細層設計規范

DWS公共匯總層設計規范

四、數倉命名規范

詞根設計規范

表命名規范

指標命名規范

1.1. 數倉分層原則

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

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

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

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

清晰數據結構；

數據血緣追蹤；

減少重復開發；

數據關系條理化；

屏蔽原始數據的影響。

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

數據分層架構

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

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

ODS 層，是最接近數據源中數據的一層，為了考慮后續可能需要追溯數據問題，因此對于這一層就不建議做過多的數據清洗工作，原封不動地接入原始數據即可，至于數據的去噪、去重、異常值處理等過程可以放在后面的DWD 層來做。

數據倉庫層是我們在做數據倉庫時要核心設計的一層，在這里，從 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 分析，數據分發等。

一般來講，該層的數據表會相對比較少，一張表會涵蓋比較多的業務內容，由于其字段較多，因此一般也會稱該層的表為寬表。

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

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

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

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

1.2. 主題域劃分原則

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

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

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

1.3. 數據模型設計原則

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

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

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

適當的數據冗余可換取查詢和刷新性能，不宜過度冗余與數據復制。

處理邏輯不變，在不同時間多次運行數據結果確定不變。

2.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.2. 數據類型規范

需統一規定不同的數據的數據類型，嚴格按照規定的數據類型執行：

金額：double 或 使用 decimal(28,6) 控制精度等，明確單位是分還是元。

字符串：string。

id類：bigint。

時間：string。

狀態：string

2.3. 數據冗余規范

寬表的冗余字段要確保：

冗余字段要使用高頻，下游3個或以上使用。

冗余字段引入不應造成本身數據產生過多的延后。

冗余字段和已有字段的重復率不應過大，原則上不應超過60%，如需要可以選擇join或原表拓展。

2.4. NULL字段處理規范

對于維度字段，需設置為-1

對于指標字段，需設置為 0

2.5. 指標口徑規范

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

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

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

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

原子指標：

選擇原子指標的歸屬產線、業務板塊、數據域、業務過程

選擇原子指標的統計數據來源于該業務過程下的原始數據源

錄入原子指標的英文名稱、中文名稱、概述

填寫指標函數

系統根據指標函數自動生成原子指標的定義表達式

系統根據指標定義表達式以及數據源表生成原子指標SQL

派生指標：

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

2.6. 數據表處理規范

新增數據，增量數據是上次導出之后的新數據。

記錄每次增加的量，而不是總量；

增量表，只報變化量，無變化不用報；

每天一個分區。

每天的所有的最新狀態的數據。

全量表，有無變化，都要報；

每次上報的數據都是所有的數據（變化的 + 沒有變化的）；

只有一個分區。

按日分區，記錄截止數據日期的全量數據。

快照表，有無變化，都要報；

每次上報的數據都是所有的數據（變化的 + 沒有變化的）；

一天一個分區。

記錄截止數據日期的全量數據。

記錄一個事物從開始，一直到當前狀態的所有變化的信息；

拉鏈表每次上報的都是歷史記錄的最終狀態，是記錄在當前時刻的歷史總量；

當前記錄存的是當前時間之前的所有歷史記錄的最后變化量（總量）；

只有一個分區。

2.7. 表的生命周期管理

這部分主要是要通過對歷史數據的等級劃分與對表類型的劃分生成相應的生命周期管理矩陣。

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

P0 ：非常重要的主題域數據和非常重要的應用數據，具有不可恢復性，如交易、日志、集團 KPI 數據、 IPO 關聯表。

Pl ：重要的業務數據和重要的應用數據，具有不可恢復性，如重要的業務產品數據。

P2 ：重要的業務數據和重要的應用數據，具有可恢復性，如交易線 ETL 產生的中間過程數據。

P3 ：不重要的業務數據和不重要的應用數據，具有可恢復性，如某些 SNS 產品報表。

事件型流水表（增量表）

事件型流水表（增量表）指數據無重復或者無主鍵數據，如日志。

事件型鏡像表（增量表）

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

維表

維表包括維度與維度屬性數據，如用戶表、商品表。

Merge 全量表

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

ETL 臨時表

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

TT 臨時數據

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

7. 普通全量表

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

通過上述歷史數據等級劃分與表類型劃分，生成相應的生命周期管理矩陣，如下表所示：

3.1. ODS層設計規范

同步規范：

一個系統源表只允許同步一次；

全量初始化同步和增量同步處理邏輯要清晰；

以統計日期和時間進行分區存儲；

目標表字段在源表不存在時要自動填充處理。

表分類與生命周期：

ods流水全量表：

不可再生的永久保存；

日志可按留存要求；

按需設置保留特殊日期數據；

按需設置保留特殊月份數據；

ods鏡像型全量表：

推薦按天存儲；

對歷史變化進行保留；

最新數據存儲在最大分區；

歷史數據按需保留；

ods增量數據：

推薦按天存儲；

有對應全量表的，建議只保留14天數據；

無對應全量表的，永久保留；

ods的etl過程中的臨時表：

推薦按需保留；

最多保留7天；

建議用完即刪，下次使用再生成；

BDSync非去重數據：

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

數據質量：

全量表必須配置唯一性字段標識；

對分區空數據進行監控；

對枚舉類型字段，進行枚舉值變化和分布監控；

ods表數據量級和記錄數做環比監控；

ods全表都必須要有注釋；

3.2. 公共維度層設計規范

一致性

共維度在不同的物理表中的字段名稱、數據類型、數據內容必須保持一致（歷史原因不一致，要做好版本控制）

維度的組合與拆分 組合原則：

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

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

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

拆分與冗余：

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

數據記錄較大的維度，可以適當冗余一些子集。

建議按天分區。

3個月內最大訪問跨度<=4天時，建議保留最近7天分區；

3個月內最大訪問跨度<=12天時，建議保留最近15天分區；

3個月內最大訪問跨度<=30天時，建議保留最近33天分區；

3個月內最大訪問跨度<=90天時，建議保留最近120天分區；

3個月內最大訪問跨度<=180天時，建議保留最近240天分區；

3個月內最大訪問跨度<=300天時，建議保留最近400天分區；

3.3. DWD明細層設計規范

建議按天分區。

3個月內最大訪問跨度<=4天時，建議保留最近7天分區；

3個月內最大訪問跨度<=12天時，建議保留最近15天分區；

3個月內最大訪問跨度<=30天時，建議保留最近33天分區；

3個月內最大訪問跨度<=90天時，建議保留最近120天分區；

3個月內最大訪問跨度<=180天時，建議保留最近240天分區；

3個月內最大訪問跨度<=300天時，建議保留最近400天分區；

基于數據應用需求的分析設計事務型事實表，結合下游較大的針對某個業務過程和分析指標需求，可考慮基于某個事件過程構建事務型實時表；

一般選用事件的發生日期或時間作為分區字段，便于掃描和裁剪；

冗余子集原則，有利于降低后續IO開銷；

明細層事實表維度退化，減少后續使用join成本。

周期快照事實表中的每行匯總了發生在某一標準周期，如某一天、某周、某月的多個度量事件。

粒度是周期性的，不是個體的事務。

通常包含許多事實，因為任何與事實表粒度一致的度量事件都是被允許的。

多個業務過程聯合分析而構建的事實表，如采購單的流轉環節。

用于分析事件時間和時間之間的間隔周期。

少量的且當前事務型不支持的，如關閉、發貨等相關的統計。

3.4. DWS公共匯總層設計規范

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

一致性。聚集表必須提供與查詢明細粒度數據一致的查詢結果。

避免單一表設計。不要在同一個表中存儲不同層次的聚集數據。

聚集粒度可不同。聚集并不需要保持與原始明細粒度數據一樣的粒度，聚集只關心所需要查詢的維度。

第一步：確定聚集維度

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

第二步：確定一致性上鉆

這時候要關心是按月匯總還是按天匯總，是按照商品匯總還是按照類目匯總，如果按照類目匯總，還需要關心是按照大類匯總還是小類匯總。當然，我們要做的只是了解用戶需要什么，然后按照他們想要的進行聚集。

第三步：確定聚集事實

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

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

數據公用性。匯總的聚集會有第三者使用嗎？基于某個維度的聚集是不是經常用于數據分析中？如果答案是肯定的，那么就有必要把明細數據經過匯總沉淀到聚集表中。

不跨數據域。數據域是在較高層次上對數據進行分類聚集的抽象。如以業務

區分統計周期。在表的命名上要能說明數據的統計周期，如 _Id表示最近1天，_td 表示截至當天，_nd 表示最近N天。

4.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

4.2. 表命名規范

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

規范：分層前綴[dwd|dws|ads]_部門_業務域_主題域_XXX_更新周期|數據范圍

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

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

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

規范：mid_table_name_[0~9|dim]

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

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

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

臨時表是臨時測試的表，是臨時使用一次的表，就是暫時保存下數據看看，后續一般不再使用的表，是可以隨時刪除的表。

規范：tmp_xxx

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

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

規范：dim_xxx

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

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

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

規范：dwd_業務域_manual_xxx

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

4.3. 指標命名規范

所有單詞小寫

單詞之間下劃線分割（反例：appName 或 AppName）

可讀性優于長度 (詞根，避免出現同一個指標，命名一致性)

禁止使用 sql 關鍵字，如字段名與關鍵字沖突時 +col

數量字段后綴 _cnt 等標識...

金額字段后綴 _price 標識

天分區使用字段 dt，格式統一（yyyymmdd 或 yyyy-mm-dd）

小時分區使用字段 hh，范圍（00-23）

分鐘分區使用字段 mi，范圍（00-59）

布爾類型標識：is_{業務}，不允許出現空值

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

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

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

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

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

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

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

7.普通指標命名規范，與字段命名規范一致，由詞匯轉換即可以。