數據中臺模型設計系列(一):維度建模初探

一、與幾個概念的關係

操做型業務系統
對於這個概念你們都不陌生。企業業務賴以運轉的交易系統就屬於操做型業務系統。所以它是爲了保障業務正常運轉,可以更快的處理事務。架構

可是由於它是針對某一特定的意圖(例如知足交易業務),它不須要承諾與其餘業務系統共享公共數據。所以就出現了適合於企業中交叉應用的ERP、主數據系統。固然對於有建設業務中臺的企業來講,基於微服務架構的各個服務中心,能更好的提供可複用統一的公共數據。微服務

不論是面向業務的業務系統、通過數據統一後的主數據系統或者基於微服務架構的服務中心的數據,都是做爲數據中臺的數據輸入源頭。咱們經過批量同步、歸檔日誌採集等方式,能將數據採集進數據中臺,做爲ODS層原始數據的一部分。性能

ETL
英文Extract-Transform-Load的縮寫,用來描述將數據歷來源端通過抽取(extract)、轉換(transform)、加載(load)至目的端的過程。在ODS層的原始數據,須要經過加工處理後,才能進入到構建好的數據模型中。spa

在模型設計時,須要考慮ETL加工流程,根據邏輯判斷,作模型的合理設計。一樣對於下游使用數據模型的ETL元數據,也是做爲模型設計的輸入,可基於下游應用方式作模型的橫向和縱向的拆分設計,這就是「元數據驅動模型設計」的理論來源。翻譯

所以,沒法理解數據開發的模型設計師是不合格的。設計

數據應用
數據中臺提供多種數據應用的形式,包括數據報表、智能數據產品等。將統一彙總加工後的數據或者明細原子數據提供給數據應用,爲業務提供數據支撐。日誌

更加合理的數據模型設計,可以給更寬泛的應用提供數據支撐,也可以讓業務方更準確無疑義的使用好數據。orm

二、幾種企業常見的建設現狀

煙囪式
也許你們都不肯意認可,可是絕大部分的企業當前是沒有統1、標準、公共、全局的模型設計的,而僅僅是把數據同步上來,而後基於業務需求作煙囪式的數據開發。這種方式也許從短時間來看是效率最高的,可是從長期看,不只僅形成計算存儲資源的極大浪費、沒有統一可用的數據、大量的重複性的工做。企業的數據就像一團亂麻,根本沒法管理。事件

三範式+數據集市事務

一些傳統大型企業,因爲歷史緣由,原子數倉中以三範式的模型設計方式構建,在各個應用的數據集市中以維度建模方式構建。經過這種方式,在原子數據設計過程當中,須要投入較大的資源。

對於業務來講,三範式模型太複雜,用戶難以理解和檢索。而且對於業務頻繁變化的企業,模型的維護成本極高。

企業級維度模型

基於企業全局的角度去構建業務總線矩陣,在此基礎上完成維度模型的設計,是當前衆多企業選擇的方向。從衆多互聯網企業的數據中臺實踐經驗來看,這也是一個絕佳的各因素平衡後的選擇。

後面,咱們將從各個角度來思考如何基於維度模型構建企業級數據中臺。

三、維度建模初探

優點
在數據中臺建設經驗中,企業級維度模型設計從理解性、擴展性、高性能上都是更適應當前的技術和業務環境的。

首先因爲計算和存儲成本逐步降低,模型更重要的變成了易於理解,當易用性放在模型設計的重要位置時,維度模型可理解的優點就顯現出來了,維度建模一直就是以業務的視角來描述數據。

另外,當新的業務出現時,新的模型不會對已有模型造成衝擊,能夠無影響的產出新的模型數據。

維度建模會設計部分數據的冗餘,經過冗餘換來數據檢索的高性能。對於數據量極具膨脹的今天,高性能給用戶帶來了高價值。

事實表

所謂的事實表,就是企業的業務過程事件的度量信息。例如對於支付這個業務過程來講,須要度量支付的商品數、金額等度量。所以,企業的業務過程數據以事實表的形式在模型中呈現出來。

事實表每行都對應了一個度量事件,每行數據是一個特定級別的細節數據。事實表中每一個度量都必須是相同的粒度級別。

事實表中的度量的可加性也相當重要,由於業務方每每須要將事實表的數據基於某些維度進行彙總,在度量上須要可以作彙總累加。

事實表仍是稀疏的,它僅僅會將發生的業務過程數據放入其中。
**
維度表**

維度表是事實表不可或缺的組成成分,它描述了事實表業務過程度量的環境。用於描述「誰、什麼、哪裏、什麼時候、如何、爲何」有關的事件。

維度屬性是做爲查詢約束、分組、標識的主要來源,所以它的好壞直接決定了數據的可分析性的差別。維度屬性須要是可理解的,所以須要儘可能避免「0,1」之類的代碼,將代碼翻譯成更易理解的字符避免業務的誤解。

一樣,會有一些數值型的可做爲維度屬性。例如:也許有人會問商品標價適合在事實表仍是維度表中?

當用於計算度量時,它應該存在於事實表中;可是當它用於作約束、分組、標識分析時,則須要存在於維度表中。在維度表中,咱們每每會把連續的數據換成離散的數值存儲,例如:將標價變爲價格區間段。這是要根據對業務的理解作進一步設計的。

雪花模型與星型模型

所謂的雪花模型,是當有一個或多個維表沒有直接鏈接到事實表上,而是經過其餘維錶鏈接到事實表上時,其圖解就像多個雪花鏈接在一塊兒,故稱雪花模型。

而星型模型則是全部維表都直接鏈接到事實表上,整個圖解就像星星同樣,故將該模型稱爲星型模型。

雪花模型是對星型模型的擴展。

星型模型是一種非正規化的結構,多維數據集的每個維度都直接與事實表相連,不存在漸變維度,因此數據有必定冗餘。由於有冗餘,因此不少統計不須要作外部的關聯查詢,所以通常狀況下效率比雪花模型高。

可是從可理解性上看,雪花模型是更容易讓業務理解的。由於業務能夠從模型上看出維度與維度之間的關係。

所以如何平衡查詢效率和業務理解?咱們在後面的文章中再細細道來。

**總線矩陣
**
總線矩陣,維護的是企業的各個業務過程與一致性維度的關係。是以企業的高度實現的頂層設計。它的存在對於數據中臺項目相當重要。

若是數據中臺的模型設計就是一本書,那麼總線矩陣就是這本書的目錄,能從總體上對每一個模型有統一的定義。

從項目協調上看,總線矩陣在大型項目中起到舉足輕重的地位,整個項目組都能基於這個目錄清晰的明白本身在作什麼,別人已經作了什麼,極大程度上的避免了信息溝通不順暢致使的重複定義。

從項目管理上看,也能夠基於總線矩陣對模型設計和開發進行有效的優先級排期。

最後,總線矩陣是共同業務人員和技術人員的橋樑,經過總線矩陣在項目溝通中達成一致的語言。

結語

經過這篇文章,初淺的對數據中臺模型設計發表了一些觀點。  在後面的章節中,咱們將繼續圍繞模型設計的技術細節、結合行業的模型設計案例,和數據同仁們作進一步的分享和交流 。

相關文章
相關標籤/搜索