讀資料工程之道：設計和構建健壯的資料系統26資料建模

躺柒發表於2024-11-03

1. 資料建模

1.1. 良好的資料架構必須反映出使用這些資料的組織的業務目標和業務邏輯

1.2. 資料湖1.0、NoSQL和大資料系統的興起，使工程師們有時是為了合理的效能提升去忽略傳統的資料建模

1.3. 資料在企業中的地位急劇上升，人們越來越認識到，建模對於實現資料科學需求層次金字塔中更高層次的價值至關重要

2. 資料模型

2.1. 資料模型代表了資料與現實世界的聯絡方式

2.2. 反映了資料需要如何結構化和標準化才能最好地反映你的組織的流程、定義、工作流和邏輯

2.3. 一些資料專家認為資料建模是乏味的，是“大企業”才會做的事情

2.4. 對資料進行建模的關鍵是要關注如何將模型轉化為業務成果

  • 2.4.1. 一個好的資料模型要關聯到商業決策的影響

  • 2.4.2. 一個好的資料模型包含前後一致的定義

2.5. 資料建模的思想就是從抽象的建模概念移動到具體的實現

2.6. 主要的資料模型

  • 2.6.1. 概念模型

    • 2.6.1.1. 包含業務邏輯和規則，描述系統的資料，如模式、表和欄位（名稱和型別）​

    • 2.6.1.2. 使用實體關係(Entity-Relationship，ER)圖中對其進行視覺化通常是有幫助的，實體關係圖是一個用於視覺化資料中各種實體（訂單、客戶、產品等）之間的關係的標準工具

  • 2.6.2. 邏輯模型

    • 2.6.2.1. 透過新增更多的細節來詳細說明概念模型在實踐中如何實現

  • 2.6.3. 物理模型

    • 2.6.3.1. 定義了邏輯模型如何在資料庫系統中實現

    • 2.6.3.2. 將為邏輯模型新增具體的資料庫、模式和表，包括配置細節

2.7. 成功的資料建模在過程的開始階段就引入業務利益相關者

  • 2.7.1. 資料建模應該是一項全接觸式的活動，目標是為企業提供高質量的資料，最終獲得可操作的洞見和智慧自動化

2.8. 資料建模的另一個重要考慮因素是資料的粒度，也就是資料的儲存和查詢的最小單元

  • 2.8.1. 粒度通常位於表中的主鍵的層級（如客戶ID、訂單ID和產品ID）​，它通常伴隨著一個日期或時間戳以提精確性

2.9. 應該努力將你的資料建模維持在儘可能低的粒度層級

  • 2.9.1. 很容易對這個高度細化的資料集做彙總

  • 2.9.2. 反之則不然，通常也不可能從彙總的資料還原回明細

3. 正規化化

3.1. 正規化化是一種對資料庫中的表和列的關係進行嚴格控制的資料建模實踐

3.2. 正規化化的目標是消除資料庫中的冗餘資料，並確保參照完整性

3.3. 是在資料庫中實踐“不要重複自己”(Don't Repeat Yourself，DRY)的原則

3.4. 由關聯式資料庫的先驅Edgar Codd在20世紀70年代初首次提出的

3.5. 四個主要目標

  • 3.5.1. 把關係集合從不合適的插入、更新和刪除依賴中解放出來

  • 3.5.2. 當新的資料型別被引入時，儘可能減少關係集合的重組，從而增加應用程式的壽命

  • 3.5.3. 使得關係模型對使用者來說更有資訊價值

  • 3.5.4. 使得關係集合對於查詢統計是中立的，這些統計可能會隨著時間的推移而改變

3.6. 正規化是有順序的，每個正規化都包含了之前正規化的條件

  • 3.6.1. 無正規化

    • 3.6.1.1. 沒有正規化化

    • 3.6.1.2. 允許巢狀和冗餘的資料

  • 3.6.2. 第一正規化(First Normal Form, 1NF)

    • 3.6.2.1. 每一列都是唯一的，有一個單一的值

    • 3.6.2.2. 該表有一個唯一主鍵

      3.6.2.2.1. 唯一主鍵是一個單一的欄位或多個欄位的組合，它唯一地確定了表中的行

      3.6.2.2.2. 每個鍵值最多出現一次，否則一個值會對映到表中的多條記錄

  • 3.6.3. 第二正規化(Second Normal Form, 2NF)

    • 3.6.3.1. 滿足第一正規化的要求，並移除部分依賴

      3.6.3.1.1. 部分依賴是指完全由唯一主鍵（複合鍵）中的一個子集決定的非鍵列

      3.6.3.1.2. 部分依賴只有在主鍵是複合鍵時才會出現

      3.6.3.1.3. 當複合鍵中的一個欄位子集可以用來確定表中的一個非鍵列時，就會出現部分依賴

  • 3.6.4. 第三正規化(Third Normal Form, 3NF)

    • 3.6.4.1. 滿足第二正規化的要求，再加上每個表只包含與其主鍵相關的欄位，並且沒有傳遞依賴

    • 3.6.4.2. 當一個非鍵欄位依賴於另一個非鍵欄位時，就會出現傳遞依賴

3.7. 儘管去正規化化看起來像是一種反模式，但它在許多儲存半結構化資料的OLAP系統中很常見

4. 建模技術

4.1. 星型模式

  • 4.1.1. 在資料集市中對資料進行建模的另一個流行方式是星型模式，理論上任何訪問方便簡單的資料模型也都是滿足要求的

  • 4.1.2. 代表了企業的資料模型

  • 4.1.3. 與高度正規化化的資料建模方法不同，星型模式是被必要維度包圍的事實表

    • 4.1.3.1. 使得星型模式需要比其他資料模型更少的連線操作，從而加快了查詢效能

  • 4.1.4. 星型模式的另一個優點是它可以更容易被業務使用者理解和使用

4.2. Inmon

  • 4.2.1. 資料倉儲之父Bill Inmon在1989年提出了他的資料建模方法

  • 4.2.2. 在資料倉儲之前，分析往往直接發生在源系統內部，其明顯的副作用是長時查詢造成了生產環境事務資料庫的效能問題

  • 4.2.3. 資料倉儲的目標是將源系統與分析系統分離

  • 4.2.4. 資料倉儲的四個關鍵部分

    • 4.2.4.1. 面向主題的

      4.2.4.1.1. 資料倉儲專注於一個特定的主題域

    • 4.2.4.2. 整合的

      4.2.4.2.1. 來自不同資料來源的資料會被整合並正規化化

    • 4.2.4.3. 非易失的

      4.2.4.3.1. 資料儲存在資料倉儲後保持不變

    • 4.2.4.4. 反映歷史變化的

      4.2.4.4.1. 不同的時間範圍的資料都可以被查詢到

  • 4.2.5. 在Inmon資料倉儲，整個組織的資料都被整合到一個細粒度、高度正規化化的並且注重ETL的實體關係模型中

  • 4.2.6. 資料從優先順序最高的業務領域開始被逐步引入

4.3. Kimball模型

  • 4.3.1. 由Ralph Kimball在20世紀90年代初建立，這種資料建模方法不太注重正規化化，在某些情況下還接受去正規化化

  • 4.3.2. Kimball方法有效地使資料集市成為資料倉儲本身

    • 4.3.2.1. 這也會使迭代和建模的速度比Inmon更快，但代價是潛在的更鬆散的資料整合、資料冗餘和重複

  • 4.3.3. 資料被建模為兩種型別的表：事實和維度

    • 4.3.3.1. 事實表

      4.3.3.1.1. 可以把事實表看作一個數字表

      4.3.3.1.2. 星型模式中的第一種表是事實表，它包含了事實的、定量的和與事件相關的資料

      4.3.3.1.3. 事實表中的資料是不可改變的，因為事實與事件有關

      4.3.3.1.3.1. 事實表只能做追加而不會被更新

      4.3.3.1.4. 事實表通常又窄又長，意味著它們沒有很多列，但有很多代表事件的行

      4.3.3.1.5. 事實表應該是儘可能細粒度的

    • 4.3.3.2. 維度表B

      4.3.3.2.1. 維度表則是引用事實的定性資料

      4.3.3.2.2. 維度表以一種叫作星型模式的關係圍繞著一個事實表

      4.3.3.2.3. 維度表為儲存在事實表中的事件提供參考資料、屬性和關係上下文

      4.3.3.2.4. 維度表比事實表小（形狀相反）​，通常是寬而短

      4.3.3.2.5. 緩慢變化維度表(Slowly Changing Dimension，SCD)

      4.3.3.2.5.1. 第一類

4.3.3.2.5.1.1. 覆蓋現有的維度記錄

4.3.3.2.5.1.2. 很簡單的但是這意味著你無法訪問被刪除的歷史維度記錄

4.3.3.2.5.1.3. 是大多數資料倉儲的預設行為

  >   4.3.3.2.5.2. 第二類

4.3.3.2.5.2.1. 保留完整的歷史維度記錄

4.3.3.2.5.2.2. 是我們在實踐中最常看到的一種

  >   4.3.3.2.5.3. 第三類

4.3.3.2.5.3.1. 第三類緩慢變化維度與第二類相似，但是在第三類中不是建立一個新行，而是建立一個新的欄位

  • 4.3.4. Kimball方法允許冗餘資料的存在，但是要避免複製相同的維度表，以避免業務定義和資料完整性的漂移

  • 4.3.5. 只適合於批處理資料而不適合於流處理資料

4.4. Data Vault模型

  • 4.4.1. Kimball和Inmon專注於資料倉儲中的業務邏輯結構，而Data Vault則提供了一種不同的資料建模方法

  • 4.4.2. 由Dan Linstedt在20世紀90年代建立的Data Vault方法將源系統資料的結構與屬性分離

  • 4.4.3. Data Vault不是用事實、維度或高度正規化化的表來表示業務邏輯，而是簡單地將資料從源系統直接載入到少數幾個特製的表中，只需插入即可

  • 4.4.4. 目標是使資料儘可能地與業務保持一致，甚至在業務資料的演進過程中

  • 4.4.5. 三種主要型別的表組成：中心表、連結表和衛星表

    • 4.4.5.1. 中心表儲存業務主鍵

      4.4.5.1.1. 查詢通常涉及透過業務主鍵進行搜尋

    • 4.4.5.2. 連結表維護業務主鍵之間的關係

      4.4.5.2.1. 跟蹤中心表之間的業務主鍵的關係

      4.4.5.2.2. 最好以最細的粒度來連線中心表

    • 4.4.5.3. 衛星表表示業務主鍵的屬性和上下文

      4.4.5.3.1. 衛星表中唯一需要的欄位是一個由父級中心表的業務鍵組成的主鍵和一個載入日期

      4.4.5.3.2. 一個衛星表可以包含多個有意義的屬性

  • 4.4.6. 使用者將查詢中心表，它將連結到一個包含查詢的相關屬性的衛星表

4.5. 去正規化化的寬表

  • 4.5.1. 雲端計算的普及意味著儲存是非常便宜的

    • 4.5.1.1. 儲存資料的成本已經低到不值得花時間去尋找最省空間的方式

  • 4.5.2. 巢狀資料（JSON和類似的）的流行意味著模式在源和分析系統中是靈活的

  • 4.5.3. 寬表就像它聽起來那樣，是一個常在列式資料庫中建立的、高度去正規化化的、包含許多欄位的集合

    • 4.5.3.1. 一個寬表有可能有成千上萬個列，而關聯式資料庫中的表通常少於100列

    • 4.5.3.2. 寬表一般是透過模式演化產生的，工程師隨著時間的推移逐漸增加欄位

  • 4.5.4. 對寬表的分析查詢往往比對需要許多連線的高度正規化化的資料執行得快

  • 4.5.5. 寬表包含了你在一個更嚴格的建模方法中加入的所有資料，且事實和維度在同一張表

5. 流資料的建模

5.1. 由於流資料的無界性和連續性，將Kimball這樣的批處理技術轉化為流正規化是很困難的，甚至是不可能的

5.2. 存在兩種主要型別的流：事件流和變更資料捕獲

5.3. 建議預測源資料的變化，並保持一個靈活的模式

相關文章