如果把指標⽐喻成⼀棵樹上的果實，那模型就是這棵⼤樹的軀⼲，想讓果實結得好，必須讓樹⼲變得粗壯。真實場景舉例：
⼤多數公司的分析師會結合業務做⼀些數據分析（需要⽤到⼤量的數據），通過報表的⽅式服務於業務部⻔的運營。但是在數據中臺構建之前，分析師經常發現⾃⼰沒有可以復⽤的數據，不得不使⽤原始數據進⾏清洗、加⼯、計算指標。
由於他們⼤多是⾮技術專業出⾝，寫的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天內，需求響應速度的提升，爲企業運營效果提升提供了數據⽀撐。
思考
在數據中臺實際實施落地的過程中，數據團隊不但要建設公共數據層，形成數據中臺，還要承擔着巨⼤的新需求的壓⼒。⽽且，往往需求的優先級都⾼於建設公共數據層的優先級，導致中臺建設的進度難以保障。
對這個問題，你有什麼解決⽅法呢？
比如：
1、先滿⾜需求（活下去），再研發公共數據層（構建美好未來）。
2、獲得⾼層領導的⽀持，以獲得更多的研發資源。
3、在滿⾜業務需求的過程中，根據業務需求不斷對公共數據層進⾏迭代和優化。
4、隨着時間的推移，越來越多的⽇常業務需求可以⽤公共數據層（中臺來完成）。
5、⽇常業務需求開發和公共數據層構建是相互促進的循環。
另外，爲了保障數據中臺的推進速度，可以嘗試成⽴專⼈團隊，這些⼈的⽬標明確就是中臺構建，模型的重構和整合，指標的梳理。這些⼈不接業務需求，這樣可以避免⽇常業務需求對數據團隊的中臺建設的⼲擾；合理設置KPI和KPI權重，給予充足的中臺建設的動⼒。
