數據倉庫進階之路

貓耳朵 /一個數據人的自留地
做者介紹

@貓耳朵

數據產品經理萌新。

開發經驗豐富，專一於數據產品。

—————— BEGIN ——————

本文主要圍繞架構、分層、建模三個方面，進一步加深對數倉的瞭解。

1 數據倉庫的架構
從總體上來看，數據倉庫體系架構可分爲：數據採集層、數據計算層、數據服務層和數據應用層，以下圖。

1）數據採集層

數據採集層的任務就是把數據從各類數據源中採集和存儲到數據庫上，期間有可能會作一些 ETL（即抽取、轉換、裝載）操做。

其中，日誌所佔份額最大，存儲在備份服務器上的業務數據庫中，如 Mysql 中的數據。其餘數據的話，如 Excel 等須要手工錄入的數據。

實時採集不是一條一條採集，而是根據一些限制條件，通常是數據大小限制（如 512KB 寫一批）、時間閾值限制（如 30 秒寫一批）。

採集的數據須要數據採集系統分發給下游，通常選取 Flume、Sqoop 等。

2）數據處理層

從數據採集系統出來的數據，分發給下游的數據處理平臺，通常有 Hive、MapReduce、Spark Streaming、Storm 以及新興的 Flink 等，阿里巴巴內部使用的是 StreamCompute。

3）數據服務層

數據服務層，經過接口服務化方式對外提供數據服務，以保證更好的性能和體驗。針對不一樣的需求和數據應用場景，數據服務層的數據源架構在不一樣的數據庫上，如 Mysql、HBase、MongoDB 等。實時的存儲且須要支持高併發的話，就選擇 HBase。

數據服務層可使應用對底層數據存儲透明，將海量數據方便高效地開放給各業務使用。

4）數據應用層

數據已經準備好，須要經過合適的應用提供給用戶，讓數據最大化地發揮價值。數據應用表如今各個方面，如報表展現、數據分析、數據挖掘、數據可視化等。

2 數據倉庫分層
2.1 爲啥要分層？
做爲一名數據產品經理，筆者確定但願本身的數據可以有秩序地流轉，數據的整個生命週期可以清晰明確地被設計者和使用者感知到。可是，隨着業務的發展，頻繁迭代和跨部門的業務變得愈來愈多。這就容易致使數據倉庫出現以下問題：

1）缺少統一的業務和技術標準，如：開發規範、指標口徑不統一。

2）缺少統一數據質量監控，如：字段數據不完整和不許確等。

3）業務知識體系散亂，致使數據研發人員開發成本增長。

4）數據架構不合理，數據層之間分工不明顯，數據流向混亂。

5）缺失統一維度和指標管理。

所以，筆者須要一套行之有效的方法來讓本身的數據倉庫更有秩序，這就須要對數據進行分層，以下圖。

2.2 數據分層設計
按照數據操做的流程，筆者將數據模型分爲三層：數據操做層（ODS）、數據倉庫層（DW）和數據應用層（APP），以下圖。簡單來說，ODS 層存放的是接入的原始數據，DW 層存放的是數據倉庫中的數據，APP 層存放的是面向業務定製的應用數據。

1）數據操做層（ODS）

數據操做層又叫數據運營層，英文：Opertional Data Source。數據操做層是最接近數據源中數據的一層，數據源中的數據，通過 ETL（即抽取、轉換、裝載），裝入本層。本層中的數據，大可能是按照源業務系統的分類方式而分類的。

因爲該層是最接近數據源的，因此不建議對該層數據作過多的數據清洗工做，原封不動地接入原始數據就行，至於數據的去噪、去重、去異常值等操做能夠放在後面的 DWD 層來作。

2）數據倉庫層（DW）

數據倉庫層，英文：Data Warehouse，是筆者在設計數據倉庫時要核心設計的一層。在這裏，從 ODS 層得到的數據按照主題創建各類的數據模型。DW 層又要細分爲 DWD（Data Warehouse Detail）層、DWM（Data Warehouse Middle）層和 DWS（Data Warehouse Service）層，以下圖。

（1）數據明細層（DWD）

數據明細層，英文：Data Warehouse Detail，該層和 ODS 層通常保持同樣的數據粒度，而且提供必定的數據質量保證。同時，爲了提升數據明細層的易用性，該層會採用一些維度退化的方法，將維度退化至事實表，減小事實表和維表的關聯。

另外，在該層也會作一部分的數據聚合，將相同主題的數據聚集到一張表中，提升數據的可用性。

（2）數據中間層（DWM）

數據中間層，英文：Data Warehouse Middle，該層會在 DWD 層的數據基礎上，對數據作輕度的聚合，生成一系列的中間表，提高公共指標的複用性，減小重複加工。直觀來說，就是對通用的核心維度進行聚合操做，算出相應的統計指標。

（3）數據服務層（DWS）

數據服務層又叫數據集市或寬表，英文：Data Warehouse Service。按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用於提供後續的業務查詢、OLAP 分析、數據分發等。

通常來說，該層的數據表會相對比較少，一張表會涵蓋比較多的業務內容，因爲其字段較多，所以通常也會稱爲該層的表爲寬表。

在實際計算中，若是直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大而且維度太少的問題，所以通常的作法是，在 DWM 層先計算出多個小的中間表，而後再拼接成一張 DWS 的寬表。因爲寬和窄的界限不易界定，也能夠去掉 DWM 這一層，只留 DWS 層，將全部的數據放在 DWS 亦可。

3）數據應用層（APP）

數據應用層，英文：Application，該層主要提供給數據產品和數據分析使用的數據。該層的數據通常會存放在 Redis、PostgreSql 等共線上系統使用的系統，也可能會存放在 Hive、Druid 中供數據分析和數據挖掘使用，好比報表數據就能夠存放在 Hive 中。

4）維度層（DIM）

維度層，英文：Dimension。創建一致數據分析維表，能夠下降數據計算口徑和算法不統一風險。以維度做爲建模驅動，基於每一個維度的業務含義，經過定義維度及維度主鍵，添加維度屬性、關聯維度等定義計算邏輯和雪花模型，完成屬性定義的過程並創建一致的數據分析維表。同時筆者能夠定義維度主子關係，子維度的屬性將合併至主維度使用，進一步保證維度的一致性和便捷使用性。

維度層包含兩個部分：

（1）高基數維度數據：通常是用戶資料表、商品資料表相似的資料表，數據量能夠上千萬甚至上億。

（2）低基數維度數據：通常是配置表，好比枚舉值對應的中文含義，或者日期維度表，數據量大概在幾千到幾萬之間。

3 數據倉庫建模
3.1 數倉建模目標
大數據的數據倉庫建模須要經過建模的方法更好地組織、存儲數據，以便在性能、成本、效率和數據質量之間找到最佳平衡點。具體的建模目標，以下圖。

3.2 數倉建模方法
接下來，就聊聊數據倉庫中幾種經典的數據模型，如關係建模、維度建模、DataVault模型。在實際工做中，一般會根據業務場景選擇一種或幾種模型。

3.2.1 關係建模

關係建模，是數據倉庫之父 Inmon 推崇的，被稱爲 「實體-關係」 模型，以一種 「標準化」 的方式存在，強調數據之間非冗餘，知足 3NF 。關係建模是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係抽象。它更多用於數據的整合和一致性質量。

3.2.2 維度建模

維度建模，Ralph Kimball 博士最早提出這一律念。其最簡單的描述就是，按照事實表、維表來構建數據倉庫、數據集市。這種方法不少人稱之爲星形模型。之因此稱爲星形模型是由於它的表示方法是以一顆 「星」 爲中心，周圍圍繞着其餘數據結構，以下圖。

星形模型的中心是一張事實表。事實表是包含大量數據值的一種結構。事實表的周圍是維表，用來描述事實表的某個重要方面。維表裏的數據量要比事實表裏的少。

星形模型之因此普遍被使用，在於針對各個維做了大量的預處理，好比按照維進行了預先的排序、分類、統計等。經過這些預處理，可以極大地提高數據倉庫的處理能力。特別是針對 3NF 的建模方法，星形模型在性能上佔據明顯的優點。所以，星形模型僅適用於小範圍數據（如一個部門或甚至一個子部門）。

一般星形模型只包含一張事實表。可是在數據庫設計中要建立一種雪花結構的複合結構，須要多張事實表結合。以下圖，描繪了一個雪花模型。

在雪花模型中，不一樣的事實表經過共享一個或多個公共維錶鏈接起來。有時稱這些共享的維表爲一致維表。

維度建模的最大優勢在於訪問的高效性。若是設計適當，經過星形鏈接將數據傳遞給最終用戶是很是高效的。爲了提升傳遞信息的效率，必須收集並吸取最終用戶的請求。最終用戶使用數據的過程是要定義什麼樣的多維結構的核心。一旦清楚了最終用戶的請求，這些請求就能夠用來最終肯定星形模型，造成最理想的結構。

所以筆者認爲，維度建模主要適用於數據集市層，它的最大做用實際上是爲了解決數據倉庫建模中的性能問題。維度建模很難提供一個完整地描述真實業務實體之間的複雜關係的抽象方法。

3.3 Data Vault 模型
Data Vault 是另外一種數據倉庫建模方法，是 Dan Linstedt 在 20 世紀 90 年代提出的，主要用於企業級的數據倉庫建模。

Data Vault 須要跟蹤全部數據的來源，所以其中每一個數據行都要包含數據來源和裝載時間屬性，用以審計和跟蹤數據值對應的源系統。

Data Vault 不區分數據在業務層面的正確與錯誤，它保留操做型系統的全部時間的全部數據，裝載數據時不作數據驗證、清洗等工做，這點明顯有別於其餘數據倉庫建模方法。

Data Vault是對 ER 模型更近一步的規範化，因爲對數據的拆解更偏向於基礎數據組織，在處理分析類場景時相對複雜，適合數據倉庫底層構建，目前實際應用場景較少。

1）Data Vault模型定義

Dan Linstedt 將 Data Vault 模型定義爲：Data Vault 是面向細節的，可追蹤歷史的，一組由鏈接關係的規範化的表的集合。這些表能夠支持一個或多個業務功能。它是一種綜合了第三範式和星型模型特色的建模方法。

Data Vault 只按照業務數據的原樣保存數據，不作任何解釋、過濾、清洗、轉換。即便從不一樣數據源來的數據是自相矛盾的，好比：同一個客戶有不一樣的地址，Data Vault 模型會存儲多個不一樣版本的地址數據。

2）Data Vault 模型的特色

（1）全部數據都基於時間來存儲，即便數據是低質量的，也不能在 ETL 過程當中處理掉。

（2）與源系統越獨立越好。

（3）能夠適應源系統中數據的各類變化，並能夠靈活的實現模型擴展。

（4）數據的來源能夠徹底追蹤，而且數據處理做業能夠支持重載。

（5）ETL 做業能夠重複執行。

3）Data Vault 模型組成

Data Vault 模型由中心表（Hub）、連接表（Link）、附屬表（Satellite）三個主要組成部分。其中，中心表是核心，用於存儲業務主鍵，連接表記錄業務關係，附屬表記錄業務描述。

（1）中心表

中心表用來存儲企業每一個業務實體的業務主鍵，業務主鍵惟一標識某個業務實體。中心表和源系統是相互獨立的，即不管業務主鍵是否用於多個業務系統，它在 Data Vault 中只保留一份，其餘的組件都連接到這一個業務主鍵上。

出於設計上的考慮，中心表通常由主鍵、業務主鍵、裝載時間戳、數據來源系統四個字段組成。其中主鍵是系統生成的代理鍵，僅供內部使用。

（2）連接表

連接表是不一樣中心表的連接。一個連接表通常在兩個或多箇中心表之間有關聯。一個連接表一般是一個外鍵，表示一種業務關係，好比：交易表、客戶關聯帳戶等。

連接表主要包括主鍵、外鍵一、……、外鍵n、裝載時間戳、數據來源系統等字段構成，其中主鍵對應多個外鍵的惟一組合，通常是與業務無關的序列數值。

（3）附屬表

附屬表用來保存中心表和連接表的描述屬性，包含全部歷史變化數據，附屬表有且僅有一個惟一外鍵關聯到中心表或連接表。

附屬表主要包括主鍵、外鍵、屬性一、……、屬性n、裝載時間、失效時間、數據來源系統，主鍵用於惟一標識附屬表中的一行記錄，通常是與業務無關的序列數值。

4）Data Vault 模型設計

根據 Data Vault 模型體系構成，Data Vault 模型設計由此也分紅三大部分。

（1）設計中心表

明確企業數據倉庫要涵蓋的業務範圍。

按業務範圍劃分爲若干原子業務實體，好比客戶、產品、品類等。

從各個業務實體中抽象出業務主鍵，該業務主鍵要在整個業務的生命週期內不會發生變化。

由該業務主鍵生成中心表。

（2）設計連接表

分析各個中心表表明的業務實體之間的業務關係，並識別對應的中心表，這些業務關係能夠是1對一、1對多，或者多對多的。

按業務關係涉及的中心表，提取中心表主鍵，這些主鍵將被加入到連接表中，並肯定連接表的主鍵。

在生成連接表的同時，連接表內能夠保存交易數據，有兩種方法，一是採用加權連接表，二是給連接表加上附屬表來處理交易數據。

（3）設計附屬表

附屬表包含了各個業務實體與業務關聯的詳細的上下文描述信息。主要是從中心表、連接表出發，提取與中心表、連接表相關的上下文描述信息。

因爲同一業務實體的各個描述信息不具備穩定性，會常常發生變化，所以須要按變化頻率不一樣的信息分割開來，爲一箇中心表創建幾個附屬表，而後提取主鍵，做爲描述該中心表的附屬表的主鍵。

（4）設計必要的 PIT 表

爲了訪問數據的方便，可能就用到 PIT 表，PIT 表不是必須的，但若是一箇中心表或者連接表有多個附屬表，就有可能用到 PIT 表。PIT 表的主鍵是由附屬表關聯的中心表提取出來的，有幾個附屬表就會有幾個字段用於記錄附屬表的變化時間戳。

一個數據人的自留地是一個助力數據人成長的你們庭，幫助對數據感興趣的夥伴們明確學習方向、精準提高技能。關注我，帶你探索數據的神奇奧祕

一、回「數據產品」，獲取<大廠數據產品面試題>

二、回「數據中臺」，獲取<大廠數據中臺資料>

三、回「商業分析」，獲取<大廠商業分析面試題>；

四、回「交個朋友」，進交流羣，認識更多的數據小夥伴。