⼤多數公司的分析師會結合業務做⼀些資料分析(需要⽤到⼤量的數倉模型),透過報表的⽅式服務於業務部⻔的運營。但是在資料中臺構建之前,分析師經常發現⾃⼰沒有可以復⽤的資料,不得不使⽤原始資料進⾏清洗、加⼯、計算指標。
由於他們⼤多是⾮技術專業出⾝,寫的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權重,給予充足的中臺建設的動⼒。