如果把指標?喻成?棵樹上的果實，那模型就是這棵?樹的軀?，想讓果實結得好，必須讓樹?變得粗壯。真實場景舉例：

?多數公司的分析師會結合業務做?些數據分析（需要?到?量的數據），通過報表的?式服務于業務部?的運營。但是在數據中臺構建之前，分析師經常發現??沒有可以復?的數據，不得不使?原始數據進?清洗、加?、計算指標。

由于他們?多是?技術專業出?，寫的SQL質量?較差，甚??過5層以上的嵌套。這種SQL對資源消耗?常?，會造成隊列阻塞，影響其他數倉任務，會引起數據開發的不滿。數據開發會要求收回分析師的原始數據讀取權限，分析師?會抱怨數倉數據不完善，要啥沒啥，?個需求經常要等?周甚?半個?。分析師與數據開發的?盾從此開始。

這個?盾的根源在于數據模型?法復?，數據開發是煙囪式的，每次遇到新的需求，都從原始數據重新計算，?然耗時。?要解決這個?盾，就要搞清楚我們的數據模型應該設計成什么樣?。

什么才是?個好的數據模型設計？

來看?組數據，這兩個表格是基于元數據中?提供的?緣信息，分別對?數據平臺上運?的任務和分析查詢（Ad-hoc）進?的統計。

表1：

表2：

下圖是數倉分層架構圖，?便回憶數據模型分層的設計架構：

表1

表1中有2547張未識別分層的表，占總表6049的40%，它們基本沒辦法復?。

重點是在已識別分層的讀表任務中，ODS：DWD：DWS：ADS的讀取任務分別是1072：545：187：433，直接讀取ODS層任務占這四層任務總和的47.9%，這說明有?量任務都是基于原始數據加?，中間模型復?性很差。

表2

在已識別的分層的查詢中，ODS：DWD：DWS：ADS的命中的查詢分別是892：1008：152：305，有37.8%的查詢直接命中ODS層原始數據，說明DWD、DWS、ADS層數據建設缺失嚴重。尤其是ADS和DWS，查詢越底層的表，就會導致查詢掃描的數據量會越?，查詢時間會越?，查詢的資源消耗也越?，使?數據的?滿意度會低。

最后，進?步對ODS層被讀取的704張表進?分解，發現有382張表的下游產出是DWS，ADS，尤其是ADS達到了323張表，占ODS層表的?例45.8%，說明有?量ODS層表被進?物理深加?。

通過上?的分析，我們似乎已經找到了?個理想的數倉模型設計應該具備的因素，那就是“數據模型可復?，完善且規范”。

如何衡量完善度

DWD層完善度：衡量DWD層是否完善，最好看ODS層有多少表被DWS/ADS/DM層引?。因為DWD以上的層引?的越多，就說明越多的任務是基于原始數據進?深度聚合計算的，明細數據沒有積累，?法被復?， 數據清洗、格式化、集成存在重復開發。因此，我提出?跨層引?率指標衡量DWD的完善度。

跨層引?率：ODS層直接被DWS/ADS/DM層引?的表，占所有ODS層表（僅統計活躍表）?例。

跨層引?率越低越好，在數據中臺模型設計規范中，要求不允許出現跨層引?，ODS層數據只能被DWD引?。

DWS/ADS/DM層完善度：考核匯總數據的完善度，主要看匯總數據能直接滿?多少查詢需求（也就是?匯總層數據的查詢?例衡量）。如果匯總數據?法滿?需求，使?數據的?就必須使?明細數據，甚?是原始數據。

匯總數據查詢?例：DWS/ADS/DM層的查詢占所有查詢的?例。

要明確的是，這個跟跨層引?率不同，匯總查詢?例不可能做到100%，但值越?，說明上層的數據建設越完善，對于使?數據的?來說，查詢速度和成本會減少，?起來會更爽。

如何衡量復?度

數據中臺模型設計的核?是追求模型的復?和共享，通過元數據中?的數據?緣圖，可以看到，?個?較差的模型設計，?下?上是?條線。??個理想的模型設計，它應該是交織的發散型結構。

?模型引?系數作為指標，衡量數據中臺模型設計的復?度。引?系數越?，說明數倉的復?性越好。

模型引?系數：?個模型被讀取，直接產出下游模型的平均數量。

?如?張DWD層表被5張DWS層表引?，這張DWD層表的引?系數就是5，如果把所有DWD層表（有下游表的）引?系數取平均值，則為DWD層表平均模型引?系數，?般低于2?較差，3以上相對?較好（經驗值）。

如何衡量規范度

表1中，超過40%的表都沒有分層信息，在模型設計層?，這顯然是不規范的。除了看這個表有沒有分層，還要看它有沒有歸屬到主題域（例如交易域）如果沒有歸屬主題域，就很難找到這張表，也?法復?。

其次，要看表的命名。拿stock這個命名為例，當看到這個表時，知道它是哪個主題域、業務過程？是全量數據的表，還是每天的增量數據？總的來說，通過這個表名獲取的信息太有限了。?個規范的表命名應該包括主題域、分層、表是全量快照，還是增量等信息。

除此之外，如果在表A中??ID的命名是UserID，在表B中??ID命名是ID，就會對使?者造成困擾，這到底是不是?個東西。所以我們要求相同的字段在不同的模型中，它的命名必須是?致的。

經驗和建議：

1. 可以拿著這些指標去評估?下，??的數倉現狀如何。2. 然后制訂?些針對性的改進計劃，?如把這些不規范命名的表消滅掉，把主題域覆蓋的表?例提?到90%以上。

3. 在嘗試完?段時間的模型重構和優化后，再拿著這些指標去測?測是不是真的變好了。

模型重構到底對數據建設有多少幫助？有沒有?些量化的指標可以衡量？基于上面的知識已經可以很好回答這兩個問題了。

如何從煙囪式的?數倉到共享的數據中臺

建設數據中臺本質就是構建企業的公共數據層，把原先分散的、煙囪式的、雜亂的?數倉，合并成?個可共享、可復?的數據中臺。

第?，接管ODS層，控制源頭。

ODS是業務數據進?數據中臺的第?站，是所有數據加?的源頭，控制住源頭，才能從根本上防??個重復的數據體系的出現。

數據中臺團隊必須明確職責，全?接管ODS層數據，從業務系統的源數據庫權限??，確保數據從業務系統產?后進?數據倉庫時，只能在數據中臺保持?份。這個可以跟業務系統數據庫管理者達成?致，只有中臺團隊的賬號才能同步數據。

ODS層表的數據必須和數據源的表結構、表記錄數?致，?度?損，對于ODS層表的命名采?ODS_業務系統數據庫名_業務系統數據庫表名?式，?如ods_warehous_stock，warehous是業務系統數據庫名，stock是該庫下?的表名。

第?，劃分主題域，構建總線矩陣。

主題域是業務過程的抽象集合。可能這么講，稍微有點?抽象，但其實業務過程就是企業經營過程中?個個不可拆分的?為事件，?如倉儲管理??有?庫、出庫、發貨、簽收，都是業務過程，抽象出來的主題域就是倉儲域。

主題域劃分要盡量涵蓋所有業務需求，保持相對穩定性，還具備?定的擴展性（新加??個主題域，不影響已經劃分的主題域的表）。

主題域劃分好以后，就要開始構建總線矩陣，明確每個主題域下的業務過程有哪些分析維度，舉個例?：

第三，構建?致性維度。

售后團隊的投訴?單數量有針對地區的分析維度，?配送團隊的配送延遲也有針對地區的分析維度，你想分析因為配送延遲導致的投訴增加，但是兩個地區的分析維度包含內容不?致，最終會導致?些地區沒辦法分析。所以我們構建全局?致性的維表，確保維表只存?份。

維度統?的最?的難題在于維度屬性（如果維度是商品，那么商品類別、商品品牌、商品尺?等商品的屬性，我們稱為維度屬性）的整合。是不是所有維度屬性都要整合到?個?的維表中，也不?得，我給你?個 建議。

1. 公共維度屬性與特有維度屬性拆成兩個維表。在?營平臺中，通常也會有?些第三?的商家?駐，但是數 量很少。?部分商品其實都沒有店鋪的屬性，這種情況，就不建議將店鋪和商品的其他維度屬性，?如商品類別、品牌設計成?個維表。

2. 產出時間相差較?的維度屬性拆分單獨的維表，?如有些維度屬性產出時間在凌晨2點，有些維度屬性產出時間在凌晨6點，那2點和6點的就可以拆成兩個維表，確保核?維表盡早產出。

3. 出于維表穩定性產出的考慮，你可以將更新頻繁的和變化緩慢的進?拆分，訪問頻繁的和訪問較少的維表 進?拆分。

對于維表的規范化命名，建議?“dim_主題域_描述_分表規則”?式。分表可以這樣理解：?個表存   儲?千億?記錄實在是太?了，所以需要把?個表切割成很多?的分區，每天或者每周，隨著任務被調度，會?成?個分區。常?的分區規則（用時查詢）。

第四，事實表整合。

事實表整合遵循的最基本的?個原則是，統計粒度必須保持?致，不同統計粒度的數據不能出現在同

?個事實表中。來看?個例?：

在數據中臺構建前，供應鏈部?、倉儲部?和市場部?都有?些重復的事實表，我們需要將這些重復的內容進?去除，按照交易域和倉儲域，主題域的?式進?整合。

對于倉儲部?和供應鏈部?都有的庫存明細表，因為倉儲部?的統計粒度是商品加倉庫，?供應鏈部?的只有商品，所以原則上兩個表是不能合并，?是應該獨?存在。

對于市場部?和供應鏈部?的兩張下單明細表，因為統計粒度都是訂單級別，都歸屬于交易域下的下單業務過程，所以可以合并為?張事實表。

除此之外，還應該考慮將不全的數據補?。對于ODS層直接被引?產出DWS/ADS/DM層的任務，通過?緣，找到任務清單，逐個進?拆解。沒有ODS對應的DWD的，應該?成DWD表，對于已經存在的，應該遷移任務，使?DWD層表。

DWD/DWS/ADS/DM的命名規則適合采?“[層次][主題][?主題][內容描述][分表規則]”的命名?式。

第五，模型開發。

模型設計完成后，就進?模型開發階段，需要注意的點：

1. 所有任務都必須嚴格配置任務依賴，如果沒有配置任務依賴，會導致前?個任務沒有正常產出數據的情

況下，后?個任務被調度起來，基于錯誤的數據空跑，浪費資源，同時增加了排查故障的復雜度；

2. 任務中創建的臨時表，在任務結束前應該刪除，如果不刪除，會發現有?量的臨時表存在，占?空間；

3. 任務名稱最好跟表名?致，?便查找和關聯；

4. ?命周期的管理，對于ODS和DWD，?般盡可能保留所有歷史數據，對于DWS/ADS/DM需要設置?命周期，7?30天不等；

5. DWD層表宜采?壓縮的?式存儲，可?lzo壓縮。

第六，應?遷移。

最后?步就是應?的遷移，這個過程的核?是要注意數據的?對，確保數據的完全?致，然后進?應?遷移，刪除?的數據表。

總的來說，建設數據中臺不是???就能吃成?個胖?，它的建設往往是滾雪球的?式，隨著?個個應?的遷移，中臺的數據也越來越豐滿，發揮的價值也越來越?。

數倉建模?具EasyDesign

上述步驟的實現，離不開?個好?的?具作為?撐，為了規范化數據模型的設計，研發了EasyDesign的模型設計產品，讓這些流程實現系統化管理。EasyDesign的設計思路和功能：

網易有數：

?https://bigdata.163yun.com/product/easydesign?

EasyDesign構建于元數據中?之上，通過API調?元數據中?的數據?緣接?，結合數倉模型設計的指標，給出了模型設計度量。

EasyDesign按照主題域、業務過程、分層的?式管理所有的模型。

它還提供了維度、度量和字段基礎字典的管理，同時具備模型設計審批流程的控制。

總結

本文主要了解了數據中臺的模型設計。從確?設計?標，到通過?系列步驟，將?個個分散的、雜亂的、煙囪式的?數倉逐步規整到?個可復?、可共享的數據中臺，最后通過產品化的?式實現系統化的管理。最后，再強調?個點：

1. 完善度、復?度和規范度構成了衡量數據中臺模型設計的度量體系，可以幫助你評估數倉設計的好壞。

2. 維度設計是維度建模的靈魂，也是數據中臺模型設計的基礎，維度設計的核?是構建?致性維度。

3. 事實表的統計粒度必須保持?致，不同統計粒度的數據不能出現在同?個事實表中。

數據中臺的構建往往需要花費半年甚??年以上的時間，但是數據中臺建成后，對研發效率的提升效果?常明顯，在?易電商業務中，中臺構建后相?構建前，數據需求的平均交付時間從?周縮短到3天內，需求響應速度的提升，為企業運營效果提升提供了數據?撐。