資料建模星型雪花DataVault模組化應用

在資料倉儲的建構過程中，選擇合適的資料建模方法至關重要。本文比較了星型結構、雪花結構和 Data Vault 2.0 三種建模方法，並以實際案例說明它們的應用場景和優缺點。同時，本文也討論了模組化資料模型的優勢，以及如何利用 dbt 工具構建模組化資料模型，提升資料處理效率和可維護性。此外，文章也分析了傳統單體資料模型的不足，例如難以維護、擴充套件性差等問題，並強調了模組化設計在解決這些問題上的重要性。最後，透過一個 SQL 查詢範例，展示了模組化設計如何提升程式碼的可讀性和可維護性，並說明瞭如何利用 CTE 等技巧簡化複雜查詢邏輯。

資料建模與分析：星型結構的應用

在進行資料分析時，資料建模是一項至關重要的步驟。星型結構（Star Schema）是一種常見且有效的資料建模方法，能夠幫助企業高效地進行複雜分析並獲得有價值的洞察。

星型結構的基本概念

星型結構是一種由事實表（Fact Table）和維度表（Dimension Table）組成的資料模型。事實表用於儲存與業務相關的量化資料或事件，而維度表則描述了與這些事實相關的屬性或上下文。

事實表的粒度

事實表的粒度由其維度鍵列中的值決定。例如，如果銷售目標事實表中的日期列儲存的是每月的第一天，那麼該表的粒度就是在月份和產品層級。這意味著事實表捕捉的是每月特定產品的銷售目標資料。

建立星型結構

以 books 表為例，我們將按照建模步驟開發一個簡單的星型結構模型。首先，我們需要識別維度表。在我們的例子中，books 表包含了三個實體：書籍、作者和型別。

維度表的建立

-- 建立維度表
CREATE TABLE dimBooks (
    book_id INT PRIMARY KEY,
    title VARCHAR(100)
);

CREATE TABLE dimAuthors (
    author_id INT PRIMARY KEY,
    author VARCHAR(100)
);

CREATE TABLE dimGenres (
    genre_id INT PRIMARY KEY,
    genre VARCHAR(50)
);

事實表的建立

-- 建立事實表
CREATE TABLE factBookPublish (
    book_id INT,
    author_id INT,
    genre_id INT,
    publication_year INT,
    FOREIGN KEY (book_id) REFERENCES dimBooks (book_id),
    FOREIGN KEY (author_id) REFERENCES dimAuthors (author_id),
    FOREIGN KEY (genre_id) REFERENCES dimGenres (genre_id)
);

星型結構的優點

透過建立星型結構模型，我們可以輕鬆地進行各種分析操作並提取有價值的洞察。星型結構的維度設計使得查詢和匯總資料變得直觀高效，能夠從不同角度探索資料。

查詢範例

-- 檢索特定型別的總出版數量
SELECT COALESCE(dg.genre, 'Not Available') AS genre,
       COUNT(*) AS total_publications
FROM factBookPublish bp
LEFT JOIN dimGenres dg ON dg.genre_id = bp.genre_id
GROUP BY dg.genre;

左連線（LEFT JOIN）的應用

在將事實表與維度表連線時，通常使用左連線以確保事實表中的所有記錄都被包含在結果中。這種做法考慮到並非所有事實記錄都一定有對應的維度記錄。

COALESCE 運算元的使用

為了處理可能的缺失對應，我們使用 COALESCE 運算元設定預設值，如 -1 或 Not Available。

圖表說明：星型結構模型

圖表翻譯： 此圖示展示了星型結構模型的架構，其中 factBookPublish 事實表與 dimBooks、dimAuthors 和 dimGenres 維度表相關聯。這種結構使得資料分析更加直觀和高效。

資料倉儲的維度資料建模

在資料倉儲的設計中，維度資料建模扮演著至關重要的角色。它主要分為兩種常見的模式：星形架構（Star Schema）與雪花架構（Snowflake Schema）。這兩種模式各有其優缺點和適用場景。

星形架構（Star Schema）

星形架構是一種簡單且有效的資料建模技術，其特點是將事實表（Fact Table）與維度表（Dimension Table）進行分離。事實表包含主要的業務資料，而維度表則包含描述性的資訊，如時間、地點等。

星形架構的優點

• 簡單易懂：星形架構的設計直觀，易於理解和維護。
• 高效查詢：由於維度表的冗餘設計，查詢時所需的 JOIN 操作較少，從而提高了查詢效率。
• 適合報表和分析：星形架構非常適合用於生成各種報表和分析結果，如銷售趨勢、暢銷書籍等。

程式碼範例：星形架構的位置維度表

CREATE TABLE dimLocation (
    locationID INT PRIMARY KEY,
    country VARCHAR(50),
    city VARCHAR(50),
    state VARCHAR(50)
);

內容解密：

1. locationID 是主鍵，用於唯一標識每一個位置記錄。
2. country、city 和 state 分別代表國家、城市和州的資訊，這些欄位直接儲存在 dimLocation 表中，體現了星形架構的冗餘設計特點。

雪花架構（Snowflake Schema）

雪花架構是對星形架構的進一步規範化，透過將維度表拆分成多個相關的表來減少資料冗餘。

雪花架構的優點

• 更好的資料完整性：透過規範化設計，雪花架構能夠更好地維護資料的完整性。
• 減少資料冗餘：將維度表拆分可以減少資料的重複儲存。

程式碼範例：雪花架構的位置維度表

CREATE TABLE dimLocation (
    locationID INT PRIMARY KEY,
    locationName VARCHAR(50),
    cityID INT
);

CREATE TABLE dimCity (
    cityID INT PRIMARY KEY,
    city VARCHAR(50),
    stateID INT
);

CREATE TABLE dimState (
    stateID INT PRIMARY KEY,
    state VARCHAR(50),
    countryID INT
);

CREATE TABLE dimCountry (
    countryID INT PRIMARYKEY,
    country VARCHAR(50)
);

內容解密：

1. dimLocation、dimCity、dimState 和 dimCountry 表共同組成了雪花架構下的位置維度。
2. 每個表透過主鍵和外部索引鍵建立關聯，例如 dimLocation 中的 cityID 與 dimCity 中的 cityID 相關聯。
3. 這種設計允許更細緻的資料管理和更少的資料冗餘，但查詢時需要更多的 JOIN 操作。

資料函式庫建模選擇

選擇星形架構還是雪花架構取決於具體的需求和應用場景。如果需要簡單高效的查詢，星形架構可能是更好的選擇；如果需要更好的資料完整性和靈活性，則雪花架構更為合適。

Data Vault 建模

Data Vault 2.0 是一種結合了第三正規化（3NF）和維度建模的企業級資料倉儲建模方法。它提供了靈活且可擴充套件的模式，能夠處理結構化、半結構化和非結構化的資料。

Data Vault 的特點

• 模組化和增量式：Data Vault 模型是模組化和增量式的，便於維護和擴充套件。
• 支援多種資料型別：能夠處理各種型別的資料，包括結構化、半結構化和非結構化資料。

Data Vault 建模提供了一種靈活且可擴充套件的方法來建立企業級資料倉儲，尤其是在需要處理多樣化資料和不斷變化的業務需求時。

資料函式庫建模技術：Data Vault 與單一資料建模

在資料倉儲的設計中，Data Vault 是一種特殊的建模技術，能夠有效地整合原始資料並根據業務鍵進行組織。這種方法確保了資料倉儲能夠適應不斷變化的業務需求和演變的資料集。

Data Vault 建模技術的優勢

Data Vault 建模技術提供了可擴充套件和靈活的資料倉儲和分析解決方案，旨在處理大量資料、變化的業務需求和不斷演變的資料來源。其模型由三個主要元件組成：Hubs、Links 和 Satellites。

• Hubs（中心）：代表業務實體，作為儲存唯一識別碼（業務鍵）的中心點。每個 Hub 對應於一個特定的實體，例如客戶、產品或地點。Hub 表包含業務鍵欄位以及與實體相關的描述性屬性。
• Links（連結）：捕捉業務實體之間的關係，用於表示多對多關係或複雜的關聯。Link 表包含參與 Hub 的外部索引鍵，形成連線實體之間的橋樑。
• Satellites（衛星）：儲存與 Hubs 和 Links 相關的上下文特定屬性，包含不屬於業務鍵但提供實體有價值上下文的額外描述性資訊。Satellites 透過外部索引鍵與對應的 Hubs 或 Links 相關聯，從而實作時間變化的資料儲存和歷史記錄的儲存。

Data Vault 的應使用案例項

讓我們回到 books 表的例子，按照 Data Vault 建模的三個步驟來開發一個簡單的 Data Vault 模型。

步驟 1：識別業務鍵並建立相應的 Hub 和 Satellite 表

在這個例子中，我們只有一個業務實體，因此不會使用 Links。範例 2-12 展示了 books 表的 Data Vault 建模。

-- 原始表結構
CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(100),
    author VARCHAR(100),
    publication_year INT,
    genre VARCHAR(50)
);

步驟 2：建立 Hub 表

-- 建立 Hub 表
CREATE TABLE hubBooks (
    bookKey INT PRIMARY KEY,
    bookHashKey VARCHAR(50),
    Title VARCHAR(100)
);

#### 內容解密：

在 hubBooks 表中，bookKey 是主要的唯一識別碼，而 bookHashKey 用於穩定性。Title 欄位包含了書籍的描述性資訊。

步驟 3：建立 Satellite 表

-- 建立 Satellite 表
CREATE TABLE satBooks (
    bookKey INT,
    loadDate DATETIME,
    author VARCHAR(100),
    publicationYear INT,
    genre VARCHAR(50),
    PRIMARY KEY (bookKey, loadDate),
    FOREIGN KEY (bookKey) REFERENCES hubBooks(bookKey)
);

#### 內容解密：

satBooks 表用於捕捉書籍的額外細節並維護歷史變更。透過將核心書籍資訊儲存在 hubBooks 表中，並將歷史細節儲存在 satBooks 表中，我們能夠在不修改現有記錄的情況下捕捉屬性變更。

單一資料建模（Monolith Data Modeling）

傳統的資料建模方法通常圍繞著建立廣泛的 SQL 指令碼。這種方法中，一個單一的 SQL 檔案往往包含了整個資料建模過程。為了實作更複雜的工作流程，開發者可能會將檔案分成多個 SQL 指令碼或儲存過程，並透過 Python 指令碼按順序執行。

#### 內容解密：

這種單一資料建模方法存在多個挑戰，包括缺乏版本控制、難以管理檢視之間的依賴關係，以及為了重複使用而從原始資料來源到最終報告階段建立新的檢視或表。此外，大型表的冪等性並未得到統一應用，從而導致冗餘和複雜的回填操作。

Data Vault 與單一資料建模的比較

Data Vault 建模技術透過其可擴充套件性和靈活性，為資料倉儲和分析提供了堅實的基礎。相比之下，單一資料建模方法由於其緊密耦合的特性，難以除錯和實施變更，可能會對整個資料管道造成幹擾。

開發模組化資料模型

在單體資料模型中，所有元件緊密相連，使得識別和隔離問題成為一項艱鉅的任務。從本質上來說，這種傳統的資料系統設計方法往往將整個系統統一成一個單一的，儘管並不總是具有凝聚力的，單元。

這種模型的相互連線性意味著看似無關的變更可能會對整個系統產生意想不到的後果。這種複雜性不僅使故障排除更加困難，也增加了引入錯誤或忽略關鍵依賴關係的風險。所有的資料和功能都如此緊密地整合和相互依賴，以至於很難修改或更新系統的任何一部分而不影響整個系統。

此外，資料模型缺乏模組化阻礙了適應不斷變化的業務需求的能力。在資料需求不斷變化、來源不斷變化的動態環境中，單體模型成為進步的瓶頸。整合新的資料來源、擴充套件基礎設施或整合新技術和框架變得越來越具有挑戰性。

此外，對單體資料模型的維護和更新變得耗時且資源密集。由於系統內複雜的依賴關係，每次變更都帶有更多的風險。擔心無意中破壞關鍵元件導致過於謹慎的方法，從而減慢開發週期並抑制創新。

單體資料模型在當今資料工程領域所帶來的挑戰是巨大的。相互依賴的風險、缺乏靈活性以及維護和擴充套件的困難需要向模組化資料模型轉變。透過採用模組化，資料工程師可以在其資料基礎設施中實作更大的靈活性、強健性和適應性，以管理快速演變的資料生態系統的複雜性。透過擺脫單體結構，組織可以充分發揮其資料的潛力，推動創新，並在我們生活的資料驅動世界中獲得競爭優勢。

dbt 在採取模組化方法和克服單體模型的挑戰方面發揮了重要作用。它透過將單一資料模型分解為獨立的模組，每個模組都有自己的 SQL 程式碼和依賴關係，從而提高可維護性、靈活性和可擴充套件性。這種模組化結構使我們能夠獨立地處理各個模組，從而更容易開發、測試和除錯資料模型的特定部分。這消除了意外變更影響整個系統的風險，使引入變更和更新更加安全。

建立模組化資料模型的優勢

前面的例子強調了 dbt 和資料模型模組化通常可以為更好的資料開發過程做出多大貢獻。然而，為什麼這對資料工程師和科學家來說不是理所當然的呢？事實上，在過去幾十年中，軟體開發領域的工程師和架構師選擇了新的方法來採用模組化作為簡化其編碼過程的一種手段。模組化不是一次處理一大塊程式碼，而是將編碼過程分解為多個步驟。這種方法比其他策略具有多個優勢。

提升可管理性

模組化的主要優勢之一是其增強可管理性的能力。在開發大型軟體程式時，很難專注於單一的程式碼片段。然而，透過將其分解為個別任務，工作變得更加易於管理。這有助於開發人員保持正軌，避免被專案的規模所壓倒。

支援團隊程式設計

模組化的另一個優勢是其對團隊程式設計的支援。與其將大任務分配給單個程式設計師，不如將其分配給團隊。每個程式設計師都被分配了作為整體程式的一部分的特定任務。最後，所有程式設計師的工作被合併以建立最終的程式。這種方法加速了開發過程，並允許團隊內部分工。

提高程式碼品質

模組化還有助於提高程式碼品質。將程式碼分解為小部分並將責任分配給個別程式設計師，可以提高每個部分的品質。當程式設計師專注於他們分配的部分而不必擔心整個程式時，他們可以確保自己的程式碼沒有缺陷。因此，當所有部分整合在一起時，整體程式就不太可能包含錯誤。

程式碼重用

此外，模組化使得已經被證明有效的程式碼模組的重用成為可能。透過將程式分解為模組，基本方面被分解。如果某一特定的程式碼片段對於特定任務運作良好，則無需重新發明它。相反，可以重用相同的程式碼，從而為程式設計師節省時間和精力。每當需要類別似功能時，都可以在整個程式中重複使用這一點，從而進一步簡化開發。

提高可讀性

此外，模組化程式碼具有高度的組織性，從而提高了其可讀性。透過根據任務組織程式碼，程式設計師可以根據其組織方案輕鬆找到和參考特定部分。這提高了多個開發人員之間的協作，因為他們可以遵循相同的組織方案並更有效地理解程式碼。

增強可靠性

模組化的所有優點最終都提高了可靠性。更容易閱讀、除錯、維護和分享的程式碼執行錯誤較少。這使得依賴於模組化的資料模型更加穩定和可靠，能夠滿足不斷變化的業務需求。

-- 定義一個簡單的模組化 SQL 查詢
WITH 
  sales_data AS (
    SELECT 
      region,
      SUM(sales_amount) AS total_sales
    FROM 
      sales
    GROUP BY 
      region
  ),
  region_ranking AS (
    SELECT 
      region,
      total_sales,
      RANK() OVER (ORDER BY total_sales DESC) AS sales_rank
    FROM 
      sales_data
  )
SELECT 
  region,
  total_sales,
  sales_rank
FROM 
  region_ranking;

內容解密：

1. CTE（公用表表達式）：查詢使用了兩個 CTE，分別是 sales_data 和 region_ranking。CTE 使得查詢邏輯更加清晰，將複雜查詢分解為易於管理的部分。
2. sales_data CTE：計算每個地區的總銷售額，將結果按地區分組。這一步驟獨立且可重用。
3. region_ranking CTE：對 sales_data 的結果進行排名，使用視窗函式 RANK() 按銷售額降序排列。這使得每個地區根據銷售額獲得一個排名。
4. 最終查詢：從 region_ranking 中選擇所需的欄位，直接輸出結果。
5. 模組化優勢：透過將查詢分解為多個 CTE，每個部分都專注於特定的任務，使得整個查詢易於理解和維護。如果需要變更或最佳化某個部分，只需修改相關的 CTE，而不會影響其他部分。
6. 可讀性和可維護性：查詢結構清晰，每一步都有明確的作用，這使得未來的維護和更新更加方便。
7. 擴充套件性：如果需要新增新的分析邏輯，可以輕鬆地在現有的 CTE 結構上進行擴充套件，例如新增其他的 CTE 或修改現有的邏輯，而不會破壞整體查詢結構。

此圖示呈現了銷售資料處理流程：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 資料建模星型雪花DataVault模組化應用

package "資料建模方法" {
    package "建模結構" {
        component [星型結構] as star
        component [雪花結構] as snowflake
        component [Data Vault] as vault
    }

    package "表格設計" {
        component [事實表] as fact
        component [維度表] as dim
        component [Hub/Link/Satellite] as hls
    }

    package "模組化設計" {
        component [dbt 工具] as dbt
        component [CTE 查詢] as cte
        component [可維護性] as maintain
    }
}

star --> snowflake : 正規化
fact --> dim : 關聯設計
dbt --> cte : 模組化處理

note bottom of vault
  適合歷史
  資料追蹤
end note

collect --> clean : 原始資料
clean --> feature : 乾淨資料
feature --> select : 特徵向量
select --> tune : 基礎模型
tune --> cv : 最佳參數
cv --> eval : 訓練模型
eval --> deploy : 驗證模型
deploy --> monitor : 生產模型

note right of feature
  特徵工程包含：
  - 特徵選擇
  - 特徵轉換
  - 降維處理
end note

note right of eval
  評估指標：
  - 準確率/召回率
  - F1 Score
  - AUC-ROC
end note

@enduml

圖表翻譯： 此圖展示了銷售資料從原始資料到最終輸出的處理過程。首先，原始銷售資料被匯總計算出每個地區的總銷售額。接著，這些資料根據銷售額進行排名，最終輸出包含地區、總銷售額和銷售排名的結果。這種流程化的處理方式使得資料分析更加直觀和高效。