數據倉庫數據模型設計是構建數據倉庫的核心過程之一。其目的是將多個數據源中的數據整合到一個統一的數據模型中，以支持業務分析和決策。然而，在數倉建設的過程中，由于未能完全按照規范操作， 從而導致數據倉庫建設比較混亂，常見以下問題：

數倉分層不清晰：數倉的分層沒有明確的邏輯，導致數據難以管理和維護。 數據域劃分不明確：沒有明確的數據域劃分，導致數據冗余和不一致。 模型設計不合理：模型設計沒有考慮到業務的實際需求，導致數據質量低下。 代碼不規范：代碼不符合規范，導致維護困難。 命名不統一：命名不統一，導致數據難以理解和使用。 主題域劃分不完整：主題域劃分沒有涵蓋所有業務需求，導致數據缺失。

本文主要探討關于數倉數據模型建設的一些方法論和經驗，通過此篇文章你可以收獲：

應用層和公共層模型設計的方法 如何定位各個分層之間的邊界 各個分層模型設計該注意什么 數倉分層標準

ODS:操作型數據(Operational Data Store)，指結構與源系統基本保持一致的增量或者全量數據。作為DW數據的一個數據準備區，同時又承擔基礎數據記錄歷史變化，之所以保留原始數據和線上原始數據保持一致，方便后期數據核對需要。

CDM：通用數據模型，又稱為數據中間層(Common Data Model)，包含DWD、DWS、DIM層。

DWD：數據倉庫明細層數據(Data Warehouse Detail)。對ODS層數據進行清洗轉化，以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細事實表。可以結合企業的數據使用特點，基于維度建模思想，將明細事實表的某些重要屬性字段做適當冗余，也即寬表化處理，構建明細寬表。

DWS：數據倉庫匯總層數據(Data Warehouse Summary)，基于指標需求，構建初步匯總事實表，一般是寬表。基于上層的應用和產品的指標需求，構建公共粒度的匯總指標表。以寬表化手段物理化模型，構建命名規范、口徑一致的統計指標，為上層提供公共指標。
DIM：建立一致數據分析維表，可以降低數據計算口徑不統一的風險，同時可以方便進行交叉探查。以維度作為建模驅動，基于每個維度的業務含義，通過添加維度屬性、關聯維度等定義計算邏輯，完成屬性定義的過程并建立一致的數據分析維表。

ADS：面向應用的數據服務層(Application Data Service)。整合匯總成分析某一個主題域的服務數據，面向應用邏輯的數據加工。該層主要存放數據產品個性化的統計指標數據，這一層的數據直接對接數據的消費者，是產品、運營等角色可以直接感知理解的一層，大多數這一層的表都可以直接在BI上通過圖表的形式直接透出。

開發流程

只有上面的分層標準顯然是不夠的，還需要有一個具體的實施路徑，這樣才可以一步一步地去開發實現。關于該如何開發，其實也是有一個標準的，具體如下：

數據調研

1、了解業務系統數據，表關系，字段含義

2、分析具體的業務需求，比如需要哪些指標，具體口徑是什么

數據域劃分

所謂的數據域，即是對業務過程或維度進行抽象，比如交易、流量、用戶等等

構建總線矩陣

1、明確業務過程所屬的數據域

2、明確業務過程與分析維度的關系

明確統計指標

通常情況下，需要明確原子指標與派生指標

模型設計

1、構建一致性維表(DIM)

2、構建一致性事實表(DWD)

3、構建公共匯總模型(DWS)

4、構建應用匯總模型(ADS)

代碼開發

數據業務邏輯開發，測試、數據驗證

部署運維

1、上線任務

2、任務監控

3、DQC監控

其實，面對不斷發展變化的業務以及永遠做不完的需求，往往會陷入短期的需求導向的怪圈，從而出現了各種各樣的煙囪，從而導致數據混亂低效，成本不可控。

一些常見的問題 分層的邊界是什么

在一些特殊情況下，一般為了快速開發，直接從回流的ODS表開發相應的ADS表，導致ADS與DWS邊界不清晰，豎立了一個又一個小煙囪。

模型設計全憑經驗，不同的人有不同的理解，最終的模型也是各不相同 明確分層定位 ODS：把操作系統數據幾乎無處理的存放在數據倉庫系統中，采用增量或全量同步，根據業務需要保存歷史數據、清洗數據。 公共層：通過抽象復用，從而提升ADS層的開發效率，確保一些共性邏輯保持全局一致性，由于是復用，要考慮模型的易用性和穩定性 ADS：專注支持業務需求，提升開發效率，確保口徑一致。面向具體應用場景構建，場景間松耦合，一般為專表專用，快速滿足業務需求 高內聚和低耦合

一個邏輯和物理模型由哪些記錄和字段組成，應該遵循最基本的軟件設計方法論的高內聚和低耦合原則。主要從數據業務特性和訪問特性兩個角度來考慮：

將業務相近或者相關的數據、粒度相同數據設計為一個邏輯或者物理模型； 將高概率同時訪問的數據放一起，將低概率同時訪問的數據分開存儲。

核心模型與擴展模型分離

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

公共處理邏輯下沉

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

成本與性能平衡

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

數據可回滾

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

指標一致性

相同的字段含義在不同表中字段命名必須相同，必須使用規范定義中的名稱。

命名清晰可理解

表命名需清晰、一致，表名需易于消費者理解和使用。

層次依賴合理

dwd應嚴格遵守層次依賴，理論上只可引用ODS、DIM和部分DWD數據，不可引用處于下游層次的ADS等數據，以避免出現“反向引用”的情況； dws應嚴格遵守層次依賴，理論上只可引用DIM、DWD數據，不可引用處于下游層次的ADS等數據，以避免出現“反向引用”的情況。

關于ODS層的處理很簡單，基本上是將業務系統數據原封不動的回流即可，一般采用增全量的方式。

公共層主要通過抽象、復用、沉淀物理或邏輯的模型，以提升整體架構的數據效率并確保口徑一致性。整體公共層設計要點在于需求上識別共性邏輯，設計上抽象復用模型，實現上平衡易用性和穩定性。

一般情況下，一個比較好的公共層遵循一下幾個原則：

1、數據域的劃分是建設公共層的前提，但是數據域不是一成不變的，由于業務不同，對應的數據域劃分也自然各不相同，有時候需要靈活處理，并且要根據業務的發展而調整相關數據域的劃分。 2、其實，數據域的目的是為了給數據分類，所以盡量可以更好地以業務分析視角去組織公共數據，從而更好地保持數據的獨立性，切不可大一統的簡單劃分粗略的一個域。 1、DWS層的原則：DWS的核心訴求是通過空間換時間，在節約成本、提升效率的同時，實現數據口徑的一致性。既然是這樣，那就不能為了加工DWS而加工DWS數據，要基于是否是業務的核心指標判斷是否要沉淀公共層，另外，如果是事后沉淀公共層，那要看下需要沉淀的指標的應用場景有多少，假如只在一個地方使用，那也就沒有沉淀DWS的必要了 2、DWD的原則：一般情況下，DWD的模型相對好設計一些，核心是基于維度建模，冗余維度屬性，降低頻繁關聯，提升基礎數據模型的易用性

公共層模型不是為某一應用場景單獨設計的，而是面向大部分的應用場景進行設計，因此需要進行一定的抽象以提升通用性，從而盡可能覆蓋更多的應用場景

復用性

指標復用性抽象：轉變不可累加指標為可累加指標，如比率型建議保留分子分母； 粒度復用性抽象：以最大公約數的邏輯抽象復用，比如上游表ADS1是子公司粒度、表ADS2是一級類目粒度，那就可以設計出sku粒度的DWS表

易用性

在不影響模型產出時效性的情況下，需盡量考慮模型易用性，提升應用研發的使用效率。易用性的設計主要指的是寬表設計和水平切分，用于降低下游理解和多表關聯。

DWS模型易用性上，通過冗余維度屬性、采用大寬表方式構建，以提升下游易用性。 DWS冗余相對不易變的維度屬性，減少下游頻繁關聯； 如無時效性問題，同數據域同粒度進行寬表設計，提升下游易用性； DWD模型易用性上，通過采用星型模型、維度冗余和信息完善度進行設計，以提升下游易用性，模型設計應以星型模型為主。

穩定性

通過大寬表的建設方式，公共層極大提升了模型的易用性，但因應用場景差異化，時效性也對應有不同的要求。公共層需進行必要的的穩定性設計，滿足下游重要應用高時效性產出的要求。

扁平化設計提升穩定性：公共層整體需扁平化設計，進行不要依賴層級過深

DWS穩定性設計：結合訪問熱度、數據穩定情況，進行必要的解耦設計，以提升DWS模型的穩定性；比如根據訪問的熱度，將1d、nd、td的數據模型進行垂直拆分， 對于DIM維表也可以根據垂直拆分的方式，保證核心維度的產出效率，將低熱度的擴展維度屬性與核心維度屬性進行拆分 一般情況下，對于數據量比較小的場景，可以優先構建DWD，后構建DWS，在構建DWS的過程中，可以優先構建細粒度的DWS表(為了擴展性)，最后沉淀粗粒度的DWS表 對于數據體量比較大的情況，可以優先構建粗粒度的DWS，對于DWD的構建，可以采用水平拆分的方式，比如不在冗余半結構的字段(attributes擴展字段)，從而提升產出的時效，提升下游的使用效率。

應用層的定位為根據特定業務訴求，按照業務角度組織數據以快速滿足業務需求。應用層研發核心關注研發效率、口徑一致性，以及核心應用的穩定性。

一個好的應用層模型需要重點關注以下幾個原則：

需求驅動構建集市：按需最小原則設計，除非有明確的業務延續，否則不做過度的擴展設計。應用層的設計需要考慮業務定制的需求，提供面向業務定制的應用數據，如報表數據、大寬表等，供線上系統使用。

與公共層類似，以高內聚低耦合的原則對集市進行劃分，讓單集市數據研發聚焦在某一領域的業務需求實現；集市間應該避免互相依賴，避免復雜度的提升。 ADS也可以抽象出公共部分，通過依賴ADS數據，提升開發的效率和產出效率

減少直接引用ODS表，降低源系統變更帶來的改造成本，架構合理上考慮，公共層針對復用性的場景進行模型沉淀，當源系統變更時，通過公共層適應性改造屏蔽下游變更。

本文主要討論了應用層和公共層模型設計的方法、如何定位各個分層之間的邊界、各個分層模型設計該注意什么三方面的內容，當然在實際的應用過程中，需要靈活處理，希望本文對你有所幫助。