訂閱
糾錯
加入自媒體

一文了解數倉建設及數據治理

2021-07-21 10:21
園陌
關注

進入主頁,點擊右上角“設為星標”

比別人更快接收好文章

本文分為兩大節(jié)介紹,第一節(jié)是數倉建設,第二節(jié)是數據治理,內容較長,還請耐心閱讀!

在談數倉之前,先來看下面幾個問題:

數倉為什么要分層?

用空間換時間,通過大量的預處理來提升應用系統(tǒng)的用戶體驗(效率),因此數據倉庫會存在大量冗余的數據;不分層的話,如果源業(yè)務系統(tǒng)的業(yè)務規(guī)則發(fā)生變化將會影響整個數據清洗過程,工作量巨大。

通過數據分層管理可以簡化數據清洗的過程,因為把原來一步的工作分到了多個步驟去完成,相當于把一個復雜的工作拆成了多個簡單的工作,把一個大的黑盒變成了一個白盒,每一層的處理邏輯都相對簡單和容易理解,這樣我們比較容易保證每一個步驟的正確性,當數據發(fā)生錯誤的時候,往往我們只需要局部調整某個步驟即可。

數據倉庫之父 Bill Inmon對數據倉庫做了定義——面向主題的、集成的、相對穩(wěn)定的、反映歷史變化的數據集合,用于支持管理決策。從定義上來看,數據倉庫的關鍵詞為面向主題、集成、穩(wěn)定、反映歷史變化、支持管理決策,而這些關鍵詞的實現就體現在分層架構內。

一個好的分層架構,有以下好處:

清晰數據結構:每一個數據分層都有對應的作用域,在使用數據的時候能更方便的定位和理解。

數據血緣追蹤:提供給業(yè)務人員或下游系統(tǒng)的數據服務時都是目標數據,目標數據的數據來源一般都來自于多張表數據。若出現目標數據異常時,清晰的血緣關系可以快速定位問題所在。而且,血緣管理也是元數據管理重要的一部分。

減少重復開發(fā):數據的逐層加工原則,下層包含了上層數據加工所需要的全量數據,這樣的加工方式避免了每個數據開發(fā)人員都重新從源系統(tǒng)抽取數據進行加工。

數據關系條理化:源系統(tǒng)間存在復雜的數據關系,比如客戶信息同時存在于核心系統(tǒng)、信貸系統(tǒng)、理財系統(tǒng)、資金系統(tǒng),取數時該如何決策呢?數據倉庫會對相同主題的數據進行統(tǒng)一建模,把復雜的數據關系梳理成條理清晰的數據模型,使用時就可避免上述問題了。

屏蔽原始數據的影響:數據的逐層加工原則,上層的數據都由下一層的數據加工獲取,不允許跳級取數。而原始數據位于數倉的最底層,離應用層數據還有多層的數據加工,所以加工應用層數據的過程中就會把原始數據的變更消除掉,保持應用層的穩(wěn)定性。

數倉分幾層最好?

目前市場上主流的分層方式眼花繚亂,不過看事情不能只看表面,還要看到內在的規(guī)律,不能為了分層而分層,沒有最好的,只有適合的。

分層是以解決當前業(yè)務快速的數據支撐為目的,為未來抽象出共性的框架并能夠賦能給其他業(yè)務線,同時為業(yè)務發(fā)展提供穩(wěn)定、準確的數據支撐,并能夠按照已有的模型為新業(yè)務發(fā)展提供方向,也就是數據驅動和賦能。

如何搭建一個好的數倉?

穩(wěn)定:數據產出穩(wěn)定且有保障。

可信:數據干凈、數據質量高。

豐富:數據涵蓋的業(yè)務足夠廣泛。

透明:數據構成體系足夠透明。

數倉設計

數倉設計的3個維度:

功能架構:結構層次清晰。

數據架構:數據質量有保障。

技術架構:易擴展、易用。

數倉架構

按照數據流入流出的過程,數據倉庫架構可分為:源數據、數據倉庫、數據應用。

數據倉庫

數據倉庫的數據來源于不同的源數據,并提供多樣的數據應用,數據自下而上流入數據倉庫后向上層開放應用,而數據倉庫只是中間集成化數據管理的一個平臺。

源數據:此層數據無任何更改,直接沿用外圍系統(tǒng)數據結構和數據,不對外開放;為臨時存儲層,是接口數據的臨時存儲區(qū)域,為后一步的數據處理做準備。

數據倉庫:也稱為細節(jié)層,DW層的數據應該是一致的、準確的、干凈的數據,即對源系統(tǒng)數據進行了清洗(去除了雜質)后的數據。

數據應用:前端應用直接讀取的數據源;根據報表、專題分析需求而計算生成的數據。

數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動都可以認為是ETL(抽取Extra, 轉化Transfer, 裝載Load)的過程,ETL是數據倉庫的流水線,也可以認為是數據倉庫的血液,它維系著數據倉庫中數據的新陳代謝,而數據倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩(wěn)定。

建設數據倉庫猶如創(chuàng)造一條新的生命,分層架構只是這條生命的邏輯骨架而已。想要在骨架上長出血肉,就必須進行合適的數據建模,數據倉庫的強壯還是孱弱,健美還是丑陋,就取決于建模的結果。

數倉建模方法

數據倉庫的建模方法有很多種,每一種建模方法代表了哲學上的一個觀點,代表了一種歸納、概括世界的一種方法。常見的有 范式建模法、維度建模法、實體建模法等,每種方法從本質上將是從不同的角度看待業(yè)務中的問題。

1. 范式建模法

范式建模法其實是我們在構建數據模型常用的一個方法,該方法的主要由 Inmon 所提倡,主要解決關系型數據庫的數據存儲,利用的一種技術層面上的方法。目前,我們在關系型數據庫中的建模方法,大部分采用的是三范式建模法。

范式 是符合某一種級別的關系模式的集合。構造數據庫必須遵循一定的規(guī)則,而在關系型數據庫中這種規(guī)則就是范式,這一過程也被稱為規(guī)范化。目前關系數據庫有六種范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce-Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。

在數據倉庫的模型設計中,一般采用第三范式。一個符合第三范式的關系必須具有以下三個條件 :

每個屬性值唯一,不具有多義性 ;

每個非主屬性必須完全依賴于整個主鍵,而非主鍵的一部分 ;

每個非主屬性不能依賴于其他關系中的屬性,因為這樣的話,這種屬性應該歸到其他關系中去。

范式建模

根據 Inmon 的觀點,數據倉庫模型的建設方法和業(yè)務系統(tǒng)的企業(yè)數據模型類似。在業(yè)務系統(tǒng)中,企業(yè)數據模型決定了數據的來源,而企業(yè)數據模型也分為兩個層次,即主題域模型和邏輯模型。同樣,主題域模型可以看成是業(yè)務模型的概念模型,而邏輯模型則是域模型在關系型數據庫上的實例化。

2. 實體建模法

實體建模法并不是數據倉庫建模中常見的一個方法,它來源于哲學的一個流派。從哲學的意義上說,客觀世界應該是可以細分的,客觀世界應該可以分成由一個個實體,以及實體與實體之間的關系組成。那么我們在數據倉庫的建模過程中完全可以引入這個抽象的方法,將整個業(yè)務也可以劃分成一個個的實體,而每個實體之間的關系,以及針對這些關系的說明就是我們數據建模需要做的工作。

雖然實體法粗看起來好像有一些抽象,其實理解起來很容易。即我們可以將任何一個業(yè)務過程劃分成 3 個部分,實體,事件,說明,如下圖所示:

實體建模

上圖表述的是一個抽象的含義,如果我們描述一個簡單的事實:“小明開車去學校上學”。以這個業(yè)務事實為例,我們可以把“小明”,“學校”看成是一個實體,“上學”描述的是一個業(yè)務過程,我們在這里可以抽象為一個具體“事件”,而“開車去”則可以看成是事件“上學”的一個說明。

3. 維度建模法

維度模型是數據倉庫領域另一位大師Ralph Kimall所倡導,他的《數據倉庫工具箱》是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發(fā)構建模型,構建的數據模型為分析需求服務,因此它重點解決用戶如何更快速完成分析需求,同時還有較好的大規(guī)模復雜查詢的響應性能。

星形模型

典型的代表是我們比較熟知的星形模型(Star-schema),以及在一些特殊場景下適用的雪花模型(Snow-schema)。

維度建模中比較重要的概念就是 事實表(Fact table)和維度表(Dimension table)。其最簡單的描述就是,按照事實表、維度表來構建數據倉庫、數據集市。

目前在互聯(lián)網公司最常用的建模方法就是維度建模。

維度建模怎么建:

在實際業(yè)務中,給了我們一堆數據,我們怎么拿這些數據進行數倉建設呢,數倉工具箱作者根據自身60多年的實際業(yè)務經驗,給我們總結了如下四步。

數倉工具箱中的維度建模四步走:

維度建模四步走

這四步是環(huán)環(huán)相扣,步步相連。下面詳細拆解下每個步驟怎么做

1、選擇業(yè)務過程

維度建模是緊貼業(yè)務的,所以必須以業(yè)務為根基進行建模,那么選擇業(yè)務過程,顧名思義就是在整個業(yè)務流程中選取我們需要建模的業(yè)務,根據運營提供的需求及日后的易擴展性等進行選擇業(yè)務。比如商城,整個商城流程分為商家端,用戶端,平臺端,運營需求是總訂單量,訂單人數,及用戶的購買情況等,我們選擇業(yè)務過程就選擇用戶端的數據,商家及平臺端暫不考慮。業(yè)務選擇非常重要,因為后面所有的步驟都是基于此業(yè)務數據展開的。

2、聲明粒度

先舉個例子:對于用戶來說,一個用戶有一個身份證號,一個戶籍地址,多個手機號,多張銀行卡,那么與用戶粒度相同的粒度屬性有身份證粒度,戶籍地址粒度,比用戶粒度更細的粒度有手機號粒度,銀行卡粒度,存在一對一的關系就是相同粒度。為什么要提相同粒度呢,因為維度建模中要求我們,在同一事實表中,必須具有相同的粒度,同一事實表中不要混用多種不同的粒度,不同的粒度數據建立不同的事實表。并且從給定的業(yè)務過程獲取數據時,強烈建議從關注原子粒度開始設計,也就是從最細粒度開始,因為原子粒度能夠承受無法預期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要的,所以對于有明確需求的數據,我們建立針對需求的上卷匯總粒度,對需求不明朗的數據我們建立原子粒度。

3、確認維度

維度表是作為業(yè)務分析的入口和描述性標識,所以也被稱為數據倉庫的“靈魂”。在一堆的數據中怎么確認哪些是維度屬性呢,如果該列是對具體值的描述,是一個文本或常量,某一約束和行標識的參與者,此時該屬性往往是維度屬性,數倉工具箱中告訴我們牢牢掌握事實表的粒度,就能將所有可能存在的維度區(qū)分開,并且要確保維度表中不能出現重復數據,應使維度主鍵唯一

4、確認事實

事實表是用來度量的,基本上都以數量值表示,事實表中的每行對應一個度量,每行中的數據是一個特定級別的細節(jié)數據,稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重復計算度量的問題。有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量,這種情況下該列往往是事實。

其中粒度是非常重要的,粒度用于確定事實表的行表示什么,建議從關注原子級別的粒度數據開始設計,因為原子粒度能夠承受無法預估的用戶查詢,而且原子數據可以以各種可能的方式進行上卷,而一旦選擇了高粒度,則無法滿足用戶下鉆細節(jié)的需求。

事實是整個維度建模的核心,其中雪花模型或者星型模型都是基于一張事實表通過外健關聯(lián)維表進行擴展,生成一份能夠支撐可預知查詢需求的模型寬表,而且最后的查詢也是落在事實表中進行。

1  2  下一頁>  
聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權或其他問題,請聯(lián)系舉報。

發(fā)表評論

0條評論,0人參與

請輸入評論內容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續(xù)

暫無評論

暫無評論

    人工智能 獵頭職位 更多
    掃碼關注公眾號
    OFweek人工智能網
    獲取更多精彩內容
    文章糾錯
    x
    *文字標題:
    *糾錯內容:
    聯(lián)系郵箱:
    *驗 證 碼:

    粵公網安備 44030502002758號