貓耳朵 /一個數據人的自留地
作者介紹
@貓耳朵
數據產品經理萌新。
開發經驗豐富，專注於數據產品。
—————— 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）鏈接表
鏈接表是不同中心表的鏈接。一個鏈接表一般在兩個或多箇中心表之間有關聯。一個鏈接表通常是一個外鍵，表示一種業務關係，比如：交易表、客戶關聯賬戶等。
鏈接表主要包括主鍵、外鍵1、……、外鍵n、裝載時間戳、數據來源系統等字段構成，其中主鍵對應多個外鍵的唯一組合，一般是與業務無關的序列數值。
（3）附屬表
附屬表用來保存中心表和鏈接表的描述屬性，包含所有歷史變化數據，附屬表有且僅有一個唯一外鍵關聯到中心表或鏈接表。
附屬表主要包括主鍵、外鍵、屬性1、……、屬性n、裝載時間、失效時間、數據來源系統，主鍵用於唯一標識附屬表中的一行記錄，一般是與業務無關的序列數值。
4）Data Vault 模型設計
根據 Data Vault 模型體系構成，Data Vault 模型設計由此也分成三大部分。
（1）設計中心表
明確企業數據倉庫要涵蓋的業務範圍。
按業務範圍劃分爲若干原子業務實體，比如客戶、產品、品類等。
從各個業務實體中抽象出業務主鍵，該業務主鍵要在整個業務的生命週期內不會發生變化。
由該業務主鍵生成中心表。
（2）設計鏈接表
分析各個中心表代表的業務實體之間的業務關係，並識別對應的中心表，這些業務關係可以是1對1、1對多，或者多對多的。
按業務關係涉及的中心表，提取中心表主鍵，這些主鍵將被加入到鏈接表中，並確定鏈接表的主鍵。
在生成鏈接表的同時，鏈接表內可以保存交易數據，有兩種方法，一是採用加權鏈接表，二是給鏈接表加上附屬表來處理交易數據。
（3）設計附屬表
附屬表包含了各個業務實體與業務關聯的詳細的上下文描述信息。主要是從中心表、鏈接表出發，提取與中心表、鏈接表相關的上下文描述信息。
由於同一業務實體的各個描述信息不具有穩定性，會經常發生變化，因此需要按變化頻率不同的信息分割開來，爲一箇中心表建立幾個附屬表，然後提取主鍵，作爲描述該中心表的附屬表的主鍵。
（4）設計必要的 PIT 表
爲了訪問數據的方便，可能就用到 PIT 表，PIT 表不是必須的，但如果一箇中心表或者鏈接表有多個附屬表，就有可能用到 PIT 表。PIT 表的主鍵是由附屬表關聯的中心表提取出來的，有幾個附屬表就會有幾個字段用於記錄附屬表的變化時間戳。
一個數據人的自留地是一個助力數據人成長的大家庭，幫助對數據感興趣的夥伴們明確學習方向、精準提升技能。關注我，帶你探索數據的神奇奧祕
1、回“數據產品”，獲取<大廠數據產品面試題>
2、回“數據中臺”，獲取<大廠數據中臺資料>
3、回“商業分析”，獲取<大廠商業分析面試題>；
4、回“交個朋友”，進交流羣，認識更多的數據小夥伴。