偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

如何避免數(shù)倉模型 “煙囪式” 建設(shè)?

數(shù)據(jù)庫 新聞
本文主要了解了數(shù)據(jù)中臺的模型設(shè)計。從確?設(shè)計?標(biāo),到通過?系列步驟,將?個個分散的、雜亂的、煙囪式的?數(shù)倉逐步規(guī)整到?個可復(fù)?、可共享的數(shù)據(jù)中臺。

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

?多數(shù)公司的分析師會結(jié)合業(yè)務(wù)做?些數(shù)據(jù)分析(需要?到?量的數(shù)據(jù)),通過報表的?式服務(wù)于業(yè)務(wù)部?的運(yùn)營。但是在數(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ù)平臺上運(yùn)?的任務(wù)和分析查詢(Ad-hoc)進(jìn)?的統(tǒng)計。

表1:

圖片

表2:

圖片

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

圖片

表1

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

重點(diǎn)是在已識別分層的讀表任務(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層引?。因?yàn)镈WD以上的層引?的越多,就說明越多的任務(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)驗(yàn)值)。

如何衡量規(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)驗(yàn)和建議:

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ù)中臺團(tuán)隊必須明確職責(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á)成?致,只有中臺團(tuán)隊的賬號才能同步數(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ù)過程的抽象集合??赡苓@么講,稍微有點(diǎn)?抽象,但其實(shí)業(yè)務(wù)過程就是企業(yè)經(jīng)營過程中?個個不可拆分的?為事件,?如倉儲管理??有?庫、出庫、發(fā)貨、簽收,都是業(yè)務(wù)過程,抽象出來的主題域就是倉儲域。

圖片

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

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

圖片

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

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

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

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

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

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

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

圖片

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

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

?個事實(shí)表中。來看?個例?:

圖片

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

圖片

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

圖片

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

除此之外,還應(yīng)該考慮將不全的數(shù)據(jù)補(bǔ)?。對于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ā)階段,需要注意的點(diǎn):

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

況下,后?個任務(wù)被調(diào)度起來,基于錯誤的數(shù)據(jù)空跑,浪費(fèi)資源,同時增加了排查故障的復(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

上述步驟的實(shí)現(xiàn),離不開?個好?的?具作為?撐,為了規(guī)范化數(shù)據(jù)模型的設(shè)計,研發(fā)了EasyDesign的模型設(shè)計產(chǎn)品,讓這些流程實(shí)現(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)品化的?式實(shí)現(xiàn)系統(tǒng)化的管理。最后,再強(qiáng)調(diào)?個點(diǎn):

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

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

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

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

圖片

責(zé)任編輯:張燕妮 來源: 數(shù)倉寶貝庫
相關(guān)推薦

2021-01-31 23:54:23

數(shù)倉模型

2022-08-22 17:46:56

虛擬數(shù)倉Impala

2021-06-11 07:26:16

數(shù)據(jù)倉庫機(jī)器學(xué)習(xí)

2021-09-01 07:21:41

數(shù)倉RFM模型

2021-01-04 05:42:48

數(shù)倉模型設(shè)計

2023-06-28 16:10:09

Dataleap數(shù)倉建設(shè)

2015-04-28 11:41:24

云資源管理信息孤島

2025-04-09 10:24:36

2022-01-13 10:45:48

數(shù)倉對象主題域

2025-04-08 11:30:00

DIM數(shù)據(jù)倉庫架構(gòu)

2024-08-20 08:39:41

大數(shù)據(jù)天穹數(shù)倉數(shù)據(jù)治理

2021-09-28 07:12:08

數(shù)倉開發(fā)工具

2022-07-26 15:38:58

數(shù)據(jù)倉數(shù)據(jù)治理數(shù)據(jù)團(tuán)隊

2022-06-15 11:04:49

數(shù)據(jù)建設(shè)場景

2023-01-03 17:43:39

網(wǎng)易郵箱數(shù)倉

2024-08-13 08:14:55

2023-11-15 13:36:00

數(shù)倉建設(shè)數(shù)據(jù)中臺

2021-12-08 15:34:59

云時代IBM云廠商

2022-03-09 16:53:38

HiveSpark SQL數(shù)據(jù)湖
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號