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

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

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

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

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

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

表1：

表2：

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

表1

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

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

表2

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

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

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

如何衡量完善度

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

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

跨層引?率越低越好，在數(shù)據(jù)中臺(tái)模型設(shè)計(jì)規(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層的查詢占所有查詢的?例。

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

如何衡量復(fù)?度

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

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

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

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

如何衡量規(guī)范度

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

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

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

經(jīng)驗(yàn)和建議：

1. 可以拿著這些指標(biāo)去評(píng)估?下，??的數(shù)倉(cāng)現(xiàn)狀如何。2. 然后制訂?些針對(duì)性的改進(jìn)計(jì)劃，?如把這些不規(guī)范命名的表消滅掉，把主題域覆蓋的表?例提?到90%以上。

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

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

如何從煙囪式的?數(shù)倉(cāng)到共享的數(shù)據(jù)中臺(tái)

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

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

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

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

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

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

主題域是業(yè)務(wù)過(guò)程的抽象集合?？赡苓@么講，稍微有點(diǎn)?抽象，但其實(shí)業(yè)務(wù)過(guò)程就是企業(yè)經(jīng)營(yíng)過(guò)程中?個(gè)個(gè)不可拆分的?為事件，?如倉(cāng)儲(chǔ)管理??有?庫(kù)、出庫(kù)、發(fā)貨、簽收，都是業(yè)務(wù)過(guò)程，抽象出來(lái)的主題域就是倉(cāng)儲(chǔ)域。

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

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

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

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

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

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

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

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

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

第四，事實(shí)表整合。

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

?個(gè)事實(shí)表中。來(lái)看?個(gè)例?：

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

對(duì)于倉(cāng)儲(chǔ)部?和供應(yīng)鏈部?都有的庫(kù)存明細(xì)表，因?yàn)閭}(cāng)儲(chǔ)部?的統(tǒng)計(jì)粒度是商品加倉(cāng)庫(kù)，?供應(yīng)鏈部?的只有商品，所以原則上兩個(gè)表是不能合并，?是應(yīng)該獨(dú)?存在。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)倉(cāng)建模?具EasyDesign

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

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

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

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

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

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

總結(jié)

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

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

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

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

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