⼤多數公司的分析師會結合業務做⼀些資料分析（需要⽤到⼤量的數倉模型），透過報表的⽅式服務於業務部⻔的運營。但是在資料中臺構建之前，分析師經常發現⾃⼰沒有可以復⽤的資料，不得不使⽤原始資料進⾏清洗、加⼯、計算指標。
由於他們⼤多是⾮技術專業出⾝，寫的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，就會對使⽤者造成困擾，這到底是不是⼀個東西。所以我們要求相同的欄位在不同的模型中，它的命名必須是⼀致的。
經驗和建議：
可以拿著這些指標去評估⼀下，⾃⼰的數倉現狀如何。
然後制訂⼀些針對性的改進計劃，⽐如把這些不規範命名的表消滅掉，把主題域覆蓋的表⽐例提⾼到90%以上。
在嘗試完⼀段時間的模型重構和最佳化後，再拿著這些指標去測⼀測是不是真的變好了。
模型重構到底對資料建設有多少幫助？有沒有⼀些量化的指標可以衡量？基於上面的知識已經可以很好回答這兩個問題了。
如何從煙囪式的⼩數倉到共享的資料中臺
建設資料中臺本質就是構建企業的公共資料層，把原先分散的、煙囪式的、雜亂的⼩數倉，合併成⼀個可共享、可復⽤的資料中臺。
第⼀，接管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天內，
需求響應速度的提升，為企業運營效果提升提供了資料⽀撐。
思考
在資料中臺實際實施落地的過程中，資料團隊不但要建設公共資料層，形成資料中臺，還要承擔著巨⼤的新需求的壓⼒。⽽且，往往需求的優先順序都⾼於建設公共資料層的優先順序，導致中臺建設的進度難以保障。
對這個問題，你有什麼解決⽅法呢？
比如：
1、先滿⾜需求（活下去），再研發公共資料層（構建美好未來）。
2、獲得⾼層領導的⽀持，以獲得更多的研發資源。
3、在滿⾜業務需求的過程中，根據業務需求不斷對公共資料層進⾏迭代和最佳化。
4、隨著時間的推移，越來越多的⽇常業務需求可以⽤公共資料層（中臺來完成）。
5、⽇常業務需求開發和公共資料層構建是相互促進的迴圈。
另外，為了保障資料中臺的推進速度，可以嘗試成⽴專⼈團隊，這些⼈的⽬標明確就是中臺構建，模型的重構和整合，指標的梳理。這些⼈不接業務需求，這樣可以避免⽇常業務需求對資料團隊的中臺建設的⼲擾；合理設定KPI和KPI權重，給予充足的中臺建設的動⼒。
