關於數倉建設及數據治理的超全概括

• 2021 年 7 月 22 日
• 筆記
• 大數據, 數據倉庫, 數據治理

本文分為兩大節介紹，第一節是數倉建設，第二節是數據治理，內容較長，還請耐心閱讀！

在談數倉之前，先來看下面幾個問題：

數倉為什麼要分層？

1. 用空間換時間，通過大量的預處理來提升應用系統的用戶體驗（效率），因此數據倉庫會存在大量冗餘的數據；不分層的話，如果源業務系統的業務規則發生變化將會影響整個數據清洗過程，工作量巨大。

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

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

一個好的分層架構，有以下好處：

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

2. 數據血緣追蹤：提供給業務人員或下游系統的數據服務時都是目標數據，目標數據的數據來源一般都來自於多張表數據。若出現目標數據異常時，清晰的血緣關係可以快速定位問題所在。而且，血緣管理也是元數據管理重要的一部分。

3. 減少重複開發：數據的逐層加工原則，下層包含了上層數據加工所需要的全量數據，這樣的加工方式避免了每個數據開發人員都重新從源系統抽取數據進行加工。

4. 數據關係條理化：源系統間存在複雜的數據關係，比如客戶信息同時存在於核心系統、信貸系統、理財系統、資金系統，取數時該如何決策呢？數據倉庫會對相同主題的數據進行統一建模，把複雜的數據關係梳理成條理清晰的數據模型，使用時就可避免上述問題了。

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

數倉分幾層最好？

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

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

如何搭建一個好的數倉？

1. 穩定：數據產出穩定且有保障。

2. 可信：數據乾淨、數據質量高。

3. 豐富：數據涵蓋的業務足夠廣泛。

4. 透明：數據構成體系足夠透明。

數倉設計

數倉設計的3個維度：

• 功能架構：結構層次清晰。

• 數據架構：數據質量有保障。

• 技術架構：易擴展、易用。

數倉架構

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

數據倉庫的數據來源於不同的源數據，並提供多樣的數據應用，數據自下而上流入數據倉庫後向上層開放應用，而數據倉庫只是中間集成化數據管理的一個平台。

源數據：此層數據無任何更改，直接沿用外圍系統數據結構和數據，不對外開放；為臨時存儲層，是接口數據的臨時存儲區域，為後一步的數據處理做準備。

數據倉庫：也稱為細節層，DW層的數據應該是一致的、準確的、乾淨的數據，即對源系統數據進行了清洗（去除了雜質）後的數據。

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

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

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

數倉建模方法

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

1. 範式建模法

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

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

在數據倉庫的模型設計中，一般採用第三範式。一個符合第三範式的關係必須具有以下三個條件 :

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

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

• 每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。

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

2. 實體建模法

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

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

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：「小明開車去學校上學」。以這個業務事實為例，我們可以把「小明」，「學校」看成是一個實體，「上學」描述的是一個業務過程，我們在這裡可以抽象為一個具體「事件」，而「開車去」則可以看成是事件「上學」的一個說明。

3. 維度建模法

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

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

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

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

維度建模怎麼建：

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

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

這四步是環環相扣，步步相連。下面詳細拆解下每個步驟怎麼做

1、選擇業務過程

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

2、聲明粒度

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

3、確認維度

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

4、確認事實

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

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

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

實際業務中數倉分層

數倉分層要結合公司業務進行，並且需要清晰明確各層職責，要保證數據層的穩定又要屏蔽對下游影響，一般採用如下分層結構：

數據層具體實現

使用四張圖說明每層的具體實現

• 數據源層ODS

數據源層主要將各個業務數據導入到大數據平台，作為業務數據的快照存儲。

• 數據明細層DW

事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。

維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重複數據，否則和事實表關聯會出現數據發散問題。

有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值並作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性。但是還是要結合業務進行最終判斷是維度還是事實。

• 數據輕度匯總層DM

此層命名為輕匯總層，就代表這一層已經開始對數據進行匯總，但是不是完全匯總，只是對相同粒度的數據進行關聯匯總，不同粒度但是有關係的數據也可進行匯總，此時需要將粒度通過聚合等操作進行統一。

• 數據應用層APP

數據應用層的表就是提供給用戶使用的，數倉建設到此就接近尾聲了，接下來就根據不同的需求進行不同的取數，如直接進行報表展示，或提供給數據分析的同事所需的數據，或其他的業務支撐。

一張圖總結下數據倉庫的構建整體流程：

數據治理

數倉建設真正的難點不在於數倉設計，而在於後續業務發展起來，業務線變的龐大之後的數據治理，包括資產治理、數據質量監控、數據指標體系的建設等。

其實數據治理的範圍很⼴，包含數據本⾝的管理、數據安全、數據質量、數據成本等。在DAMA 數據管理知識體系指南中，數據治理位於數據管理「車輪圖」的正中央，是數據架構、數據建模、數據存儲、數據安全、數據質量、元數據管理、主數據管理等10大數據管理領域的總綱，為各項數據管理活動提供總體指導策略。

數據治理之道是什麼

1. 數據治理需要體系建設

為發揮數據價值需要滿足三個要素：合理的平台架構、完善的治理服務、體系化的運營手段。

根據企業的規模、所屬行業、數據量等情況選擇合適的平台架構；治理服務需要貫穿數據全生命周期，保證數據在採集、加工、共享、存儲、應用整個過程中的完整性、準確性、一致性和實效性；運營手段則應當包括規範的優化、組織的優化、平台的優化以及流程的優化等等方面。

2. 數據治理需要夯實基礎

數據治理需要循序漸進，但在建設初期至少需要關注三個方面：數據規範、數據質量、數據安全。規範化的模型管理是保障數據可以被治理的前提條件，高質量的數據是數據可用的前提條件，數據的安全管控是數據可以共享交換的前提條件。

3. 數據治理需要IT賦能

數據治理不是一堆規範文檔的堆砌，而是需要將治理過程中所產生的的規範、流程、標準落地到IT平台上，在數據生產過程中通過「以終為始」前向的方式進行數據治理，避免事後稽核帶來各種被動和運維成本的增加。

4. 數據治理需要聚焦數據

數據治理的本質是管理數據，因此需要加強元數據管理和主數據管理，從源頭治理數據，補齊數據的相關屬性和信息，比如：元數據、質量、安全、業務邏輯、血緣等，通過元數據驅動的方式管理數據生產、加工和使用。

5. 數據治理需要建管一體化

數據模型血緣與任務調度的一致性是建管一體化的關鍵，有助於解決數據管理與數據生產口徑不一致的問題，避免出現兩張皮的低效管理模式。

淺談數據治理方式

如上面所說，數據治理的範圍非常廣，其中最重要的是數據質量治理，而數據質量涉及的範圍也很廣，貫穿數倉的整個生命周期，從數據產生->數據接入->數據存儲->數據處理->數據輸出->數據展示，每個階段都需要質量治理，評價維度包括完整性、規範性、一致性、準確性、唯一性、關聯性等。

在系統建設的各個階段都應該根據標準進行數據質量檢測和規範，及時進行治理，避免事後的清洗工作。

質量檢測可參考以下維度：

下面是根據美團的技術文章總結的幾點具體治理方式：

1. 規範治理

規範是數倉建設的保障。為了避免出現指標重複建設和數據質量差的情況，統一按照最詳細、可落地的方法進行規範建設。

(1) 詞根

詞根是維度和指標管理的基礎，劃分為普通詞根與專有詞根，提高詞根的易用性和關聯性。

• 普通詞根：描述事物的最小單元體，如：交易-trade。

• 專有詞根：具備約定成俗或行業專屬的描述體，如：美元-USD。

(2) 表命名規範

通用規範

• 表名、字段名採用一個下劃線分隔詞根（示例：clienttype->client_type）。

• 每部分使用小寫英文單詞，屬於通用字段的必須滿足通用字段信息的定義。

• 表名、字段名需以字母為開頭。

• 表名、字段名最長不超過64個英文字符。

• 優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），定期Review新增命名的不合理性。

• 在表名自定義部分禁止採用非標準的縮寫。

表命名規則

• 表名稱 = 類型 + 業務主題 + 子主題 + 表含義 + 存儲格式 + 更新頻率 +結尾，如下圖所示：

(3) 指標命名規範

結合指標的特性以及詞根管理規範，將指標進行結構化處理。

1. 基礎指標詞根，即所有指標必須包含以下基礎詞根：

2. 業務修飾詞，用於描述業務場景的詞彙，例如trade-交易。

3.日期修飾詞，用於修飾業務發生的時間區間。

4.聚合修飾詞，對結果進行聚集操作。

5.基礎指標，單一的業務修飾詞+基礎指標詞根構建基礎指標 ，例如：交易金額-trade_amt。

6.派生指標，多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性，例如：安裝門店數量-install_poi_cnt。

7.普通指標命名規範，與字段命名規範一致，由詞彙轉換即可以。

2. 架構治理

(1) 數據分層

優秀可靠的數倉體系，往往需要清晰的數據分層結構，即要保證數據層的穩定又要屏蔽對下游的影響，並且要避免鏈路過長，一般的分層架構如下：

(2) 數據流向

穩定業務按照標準的數據流向進行開發，即ODS–>DWD–>DWA–>APP。非穩定業務或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP兩個模型數據流。在保障了數據鏈路的合理性之後，又在此基礎上確認了模型分層引用原則：

• 正常流向：ODS>DWD->DWT->DWA->APP，當出現ODS >DWD->DWA->APP這種關係時，說明主題域未覆蓋全。應將DWD數據落到DWT中，對於使用頻度非常低的表允許DWD->DWA。

• 盡量避免出現DWA寬表中使用DWD又使用（該DWD所歸屬主題域）DWT的表。

• 同一主題域內對於DWT生成DWT的表，原則上要盡量避免，否則會影響ETL的效率。

• DWT、DWA和APP中禁止直接使用ODS的表， ODS的表只能被DWD引用。

• 禁止出現反向依賴，例如DWT的表依賴DWA的表。

3. 元數據治理

元數據可分為技術元數據和業務元數據：

技術元數據為開發和管理數據倉庫的IT 人員使用，它描述了與數據倉庫開發、管理和維護相關的數據，包括數據源信息、數據轉換描述、數據倉庫模型、數據清洗與更新規則、數據映射和訪問權限等。

常見的技術元數據有：

• 存儲元數據：如表、字段、分區等信息。

• 運行元數據：如大數據平台上所有作業運行等信息：類似於 Hive Job 日誌，包括作業類型、實例名稱、輸入輸出、 SQL 、運行參數、執行時間，執行引擎等。

• 數據開發平台中數據同步、計算任務、任務調度等信息：包括數據同步的輸入輸出表和字段，以及同步任務本身的節點信息：計算任務主要有輸入輸出、任務本身的節點信息 任務調度主要有任務的依賴類型、依賴關係等，以及不同類型調度任務的運行日誌等。

• 數據質量和運維相關元數據：如任務監控、運維報警、數據質量、故障等信息，包括任務監控運行日誌、告警配置及運行日誌、故障信息等。

業務元數據為管理層和業務分析人員服務，從業務角度描述數據，包括商務術語、數據倉庫中有什麼數據、數據的位置和數據的可用性等，幫助業務人員更好地理解數據倉庫中哪些數據是可用的以及如何使用。

• 常見的業務元數據有維度及屬性(包括維度編碼，字段類型，創建人，創建時間，狀態等)、業務過程、指標(包含指標名稱,指標編碼，業務口徑，指標類型，責任人，創建時間，狀態，sql等)，安全等級，計算邏輯等的規範化定義，用於更好地管理和使用數據。數據應用元數據，如數據報表、數據產品等的配置和運行元數據。

元數據不僅定義了數據倉庫中數據的模式、來源、抽取和轉換規則等，而且是整個數據倉庫系統運行的基礎，元數據把數據倉庫系統中各個鬆散的組件聯繫起來，組成了一個有機的整體。

元數據治理主要解決三個問題：

1. 通過建立相應的組織、流程和工具，推動業務標準的落地實施，實現指標的規範定義，消除指標認知的歧義；

2. 基於業務現狀和未來的演進方式，對業務模型進行抽象，制定清晰的主題、業務過程和分析方向，構建完備的技術元數據，對物理模型進行準確完善的描述，並打通技術元數據與業務元數據的關係，對物理模型進行完備的刻畫；

3. 通過元數據建設，為使用數據提效，解決「找數、理解數、評估」難題以及「取數、數據可視化」等難題。

4. 安全治理

圍繞數據安全標準，首先要有數據的分級、分類標準，確保數據在上線前有着準確的密級。第二，針對數據使用方，要有明確的角色授權標準，通過分級分類和角色授權，來保障重要數據拿不走。第三，針對敏感數據，要有隱私管理標準，保障敏感數據的安全存儲，即使未授權用戶繞過權限管理拿到敏感數據，也要確保其看不懂。第四，通過制定審計標準，為後續的審計提供審計依據，確保數據走不脫。

5. 數據生命周期治理

任何事物都具有一定的生命周期，數據也不例外。從數據的產生、加工、使用乃至消亡都應該有一個科學的管理辦法，將極少或者不再使用的數據從系統中剝離出來，並通過核實的存儲設備進行保留，不僅能夠提高系統的運行效率，更好的服務客戶，還能大幅度減少因為數據長期保存帶來的儲存成本。數據生命周期一般包含在線階段、歸檔階段（有時還會進一步劃分為在線歸檔階段和離線歸檔階段）、銷毀階段三大階段，管理內容包括建立合理的數據類別，針對不同類別的數據制定各個階段的保留時間、存儲介質、清理規則和方式、注意事項等。

從上圖數據生命周期中各參數間的關係中我們可以了解到，數據生命周期管理可以使得高價值數據的查詢效率大幅提升，而且高價格的存儲介質的採購量也可以減少很多；但是隨着數據的使用程度的下降，數據被逐漸歸檔，查詢時間也慢慢的變長；最後隨着數據的使用頻率和價值基本沒有了之後，就可以逐漸銷毀了。

參考鏈接：

//mp.weixin.qq.com/s/h6HnkROzljralUj2aZyNUQ

//zhuanlan.zhihu.com/p/137454121

//www.infoq.cn/article/KJzDGU6IkWKyaPZXbFkB

//blog.csdn.net/MeituanTech/article/details/102617733

//baijiahao.baidu.com/s?id=1699535513357258268

//tech.meituan.com/2020/03/12/delivery-data-governance.html