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

?多數(shù)公司的分析師會結(jié)合業(yè)務(wù)做?些數(shù)據(jù)分析（需要?到?量的數(shù)據(jù)），通過報表的?式服務(wù)于業(yè)務(wù)部?的運營。但是在數(shù)據(jù)中臺構(gòu)建之前，分析師經(jīng)常發(fā)現(xiàn)??沒有可以復(fù)?的數(shù)據(jù)，不得不使?原始數(shù)據(jù)進(jìn)?清洗、加?、計算指標(biāo)。

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

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

什么才是?個好的數(shù)據(jù)模型設(shè)計？

---

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

表1：

表2：

下圖是數(shù)倉分層架構(gòu)圖，?便回憶數(shù)據(jù)模型分層的設(shè)計架構(gòu)：

表1

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

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

表2

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

最后，進(jìn)?步對ODS層被讀取的704張表進(jìn)?分解，發(fā)現(xiàn)有382張表的下游產(chǎn)出是DWS，ADS，尤其是ADS達(dá)到了323張表，占ODS層表的?例45.8%，說明有?量ODS層表被進(jìn)?物理深加?。

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

如何衡量完善度

---

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

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

跨層引?率越低越好，在數(shù)據(jù)中臺模型設(shè)計規(guī)范中，要求不允許出現(xiàn)跨層引?，ODS層數(shù)據(jù)只能被DWD引?。

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

匯總數(shù)據(jù)查詢?例：DWS/ADS/DM層的查詢占所有查詢的?例。

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

如何衡量復(fù)?度

---

數(shù)據(jù)中臺模型設(shè)計的核?是追求模型的復(fù)?和共享，通過元數(shù)據(jù)中?的數(shù)據(jù)?緣圖，可以看到，?個?較差的模型設(shè)計，?下?上是?條線。??個理想的模型設(shè)計，它應(yīng)該是交織的發(fā)散型結(jié)構(gòu)。

?模型引?系數(shù)作為指標(biāo)，衡量數(shù)據(jù)中臺模型設(shè)計的復(fù)?度。引?系數(shù)越?，說明數(shù)倉的復(fù)?性越好。

模型引?系數(shù)：?個模型被讀取，直接產(chǎn)出下游模型的平均數(shù)量。

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

如何衡量規(guī)范度

---

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

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

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

經(jīng)驗和建議：

   1. 可以拿著這些指標(biāo)去評估?下，??的數(shù)倉現(xiàn)狀如何。

2. 然后制訂?些針對性的改進(jìn)計劃，?如把這些不規(guī)范命名的表消滅掉，把主題域覆蓋的表?例提?到90%以上。

3. 在嘗試完?段時間的模型重構(gòu)和優(yōu)化后，再拿著這些指標(biāo)去測?測是不是真的變好了。

模型重構(gòu)到底對數(shù)據(jù)建設(shè)有多少幫助？有沒有?些量化的指標(biāo)可以衡量？基于上面的知識已經(jīng)可以很好回答這兩個問題了。

如何從煙囪式的?數(shù)倉到共享的數(shù)據(jù)中臺

建設(shè)數(shù)據(jù)中臺本質(zhì)就是構(gòu)建企業(yè)的公共數(shù)據(jù)層，把原先分散的、煙囪式的、雜亂的?數(shù)倉，合并成?個可共享、可復(fù)?的數(shù)據(jù)中臺。

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

ODS是業(yè)務(wù)數(shù)據(jù)進(jìn)?數(shù)據(jù)中臺的第?站，是所有數(shù)據(jù)加?的源頭，控制住源頭，才能從根本上防??個重復(fù)的數(shù)據(jù)體系的出現(xiàn)。

數(shù)據(jù)中臺團隊必須明確職責(zé)，全?接管ODS層數(shù)據(jù)，從業(yè)務(wù)系統(tǒng)的源數(shù)據(jù)庫權(quán)限??，確保數(shù)據(jù)從業(yè)務(wù)系統(tǒng)產(chǎn)?后進(jìn)?數(shù)據(jù)倉庫時，只能在數(shù)據(jù)中臺保持?份。這個可以跟業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫管理者達(dá)成?致，只有中臺團隊的賬號才能同步數(shù)據(jù)。

ODS層表的數(shù)據(jù)必須和數(shù)據(jù)源的表結(jié)構(gòu)、表記錄數(shù)?致，?度?損，對于ODS層表的命名采?ODS_業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫名_業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫表名?式，?如ods_warehous_stock，warehous是業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫名，stock是該庫下?的表名。

第?，劃分主題域，構(gòu)建總線矩陣。

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

主題域劃分要盡量涵蓋所有業(yè)務(wù)需求，保持相對穩(wěn)定性，還具備?定的擴展性（新加??個主題域，不影響已經(jīng)劃分的主題域的表）。

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

第三，構(gòu)建?致性維度。

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

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

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

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

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

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

第四，事實表整合。

事實表整合遵循的最基本的?個原則是，統(tǒng)計粒度必須保持?致，不同統(tǒng)計粒度的數(shù)據(jù)不能出現(xiàn)在同

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

在數(shù)據(jù)中臺構(gòu)建前，供應(yīng)鏈部?、倉儲部?和市場部?都有?些重復(fù)的事實表，我們需要將這些重復(fù)的內(nèi)容進(jìn)?去除，按照交易域和倉儲域，主題域的?式進(jìn)?整合。

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

對于市場部?和供應(yīng)鏈部?的兩張下單明細(xì)表，因為統(tǒng)計粒度都是訂單級別，都?xì)w屬于交易域下的下單業(yè)務(wù)過程，所以可以合并為?張事實表。

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

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

第五，模型開發(fā)。

模型設(shè)計完成后，就進(jìn)?模型開發(fā)階段，需要注意的點：

1. 所有任務(wù)都必須嚴(yán)格配置任務(wù)依賴，如果沒有配置任務(wù)依賴，會導(dǎo)致前?個任務(wù)沒有正常產(chǎn)出數(shù)據(jù)的情

況下，后?個任務(wù)被調(diào)度起來，基于錯誤的數(shù)據(jù)空跑，浪費資源，同時增加了排查故障的復(fù)雜度；

2. 任務(wù)中創(chuàng)建的臨時表，在任務(wù)結(jié)束前應(yīng)該刪除，如果不刪除，會發(fā)現(xiàn)有?量的臨時表存在，占?空間；

3. 任務(wù)名稱最好跟表名?致，?便查找和關(guān)聯(lián)；

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

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

第六，應(yīng)?遷移。

最后?步就是應(yīng)?的遷移，這個過程的核?是要注意數(shù)據(jù)的?對，確保數(shù)據(jù)的完全?致，然后進(jìn)?應(yīng)?遷移，刪除?的數(shù)據(jù)表。

總的來說，建設(shè)數(shù)據(jù)中臺不是???就能吃成?個胖?，它的建設(shè)往往是滾雪球的?式，隨著?個個應(yīng)?的遷移，中臺的數(shù)據(jù)也越來越豐滿，發(fā)揮的價值也越來越?。

數(shù)倉建模?具EasyDesign

---

上述步驟的實現(xiàn)，離不開?個好?的?具作為?撐，為了規(guī)范化數(shù)據(jù)模型的設(shè)計，研發(fā)了EasyDesign的模型設(shè)計產(chǎn)品，讓這些流程實現(xiàn)系統(tǒng)化管理。EasyDesign的設(shè)計思路和功能：

網(wǎng)易有數(shù)：

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

EasyDesign構(gòu)建于元數(shù)據(jù)中?之上，通過API調(diào)?元數(shù)據(jù)中?的數(shù)據(jù)?緣接?，結(jié)合數(shù)倉模型設(shè)計的指標(biāo)，給出了模型設(shè)計度量。

EasyDesign按照主題域、業(yè)務(wù)過程、分層的?式管理所有的模型。

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

總結(jié)

---

本文主要了解了數(shù)據(jù)中臺的模型設(shè)計。從確?設(shè)計?標(biāo)，到通過?系列步驟，將?個個分散的、雜亂的、煙囪式的?數(shù)倉逐步規(guī)整到?個可復(fù)?、可共享的數(shù)據(jù)中臺，最后通過產(chǎn)品化的?式實現(xiàn)系統(tǒng)化的管理。最后，再強調(diào)?個點：

1. 完善度、復(fù)?度和規(guī)范度構(gòu)成了衡量數(shù)據(jù)中臺模型設(shè)計的度量體系，可以幫助你評估數(shù)倉設(shè)計的好壞。

2. 維度設(shè)計是維度建模的靈魂，也是數(shù)據(jù)中臺模型設(shè)計的基礎(chǔ)，維度設(shè)計的核?是構(gòu)建?致性維度。

3. 事實表的統(tǒng)計粒度必須保持?致，不同統(tǒng)計粒度的數(shù)據(jù)不能出現(xiàn)在同?個事實表中。

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

思考

在數(shù)據(jù)中臺實際實施落地的過程中，數(shù)據(jù)團隊不但要建設(shè)公共數(shù)據(jù)層，形成數(shù)據(jù)中臺，還要承擔(dān)著巨?的新需求的壓?。?且，往往需求的優(yōu)先級都?于建設(shè)公共數(shù)據(jù)層的優(yōu)先級，導(dǎo)致中臺建設(shè)的進(jìn)度難以保障。    

對這個問題，你有什么解決?法呢？

比如：

1、先滿?需求（活下去），再研發(fā)公共數(shù)據(jù)層（構(gòu)建美好未來）。

2、獲得?層領(lǐng)導(dǎo)的?持，以獲得更多的研發(fā)資源。

3、在滿?業(yè)務(wù)需求的過程中，根據(jù)業(yè)務(wù)需求不斷對公共數(shù)據(jù)層進(jìn)?迭代和優(yōu)化。

4、隨著時間的推移，越來越多的?常業(yè)務(wù)需求可以?公共數(shù)據(jù)層（中臺來完成）。

5、?常業(yè)務(wù)需求開發(fā)和公共數(shù)據(jù)層構(gòu)建是相互促進(jìn)的循環(huán)。

另外，為了保障數(shù)據(jù)中臺的推進(jìn)速度，可以嘗試成?專?團隊，這些?的?標(biāo)明確就是中臺構(gòu)建，模型的重構(gòu)和整合，指標(biāo)的梳理。這些?不接業(yè)務(wù)需求，這樣可以避免?常業(yè)務(wù)需求對數(shù)據(jù)團隊的中臺建設(shè)的?擾；合理設(shè)置KPI和KPI權(quán)重，給予充足的中臺建設(shè)的動?。