在資料驅動決策的時代，企業如何有效地將海量原始數據轉化為具備商業價值的洞察，已成為關鍵競爭力。批次資料處理作為資料工程的基礎，其架構設計直接影響分析效率與數據品質。本文以行銷轉換事件分析為例，從業務需求出發，系統性地介紹兩種核心概念。首先是維度模型（星型模式），它為商業智慧查詢提供了優化的結構基礎。其次是湖倉一體架構，此分層模型規範了資料從攝取、清洗到最終策劃的生命週期。透過結合這兩種理論，資料團隊能建立一個穩健、可擴展的資料管道，將複雜的原始事件轉化為清晰的決策支援依據，實現數據的真正價值。
第十二章：批次資料管道建構實務
理解業務用例與資料特性
- 追蹤社群媒體（Follow social media）：當用戶選擇追蹤社群媒體時，他們選擇接收品牌或個人在
Facebook、X（以前稱為Twitter）或Instagram等社群媒體平台上的更新、貼文和內容。 - 閱讀內容（Read content）：當用戶消費並參與書面或視覺內容時，例如文章、部落格貼文或新聞報導，就會發生閱讀內容事件。
- 下載內容（Download content）：下載內容表示用戶主動檢索數位資產，例如電子書、白皮書或軟體供個人使用。
理解資料
237
玄貓應該始終詢問玄貓的相關者他們想用他們的資料做什麼。行銷部門已經確定了他們希望在資料中追蹤的以下指標：
- 按行銷活動劃分的轉換事件數量
- 按地理位置劃分的轉換事件數量
- 按行銷活動劃分，從高到低排名的哪些轉換事件被驅動最多
讓玄貓繼續了解玄貓的資料，以便玄貓可以確定如何解決這個業務問題。
理解資料
在與玄貓的行銷團隊以及收集玄貓資料的營運團隊交談之後，玄貓現在知道新的傳入資料將是轉換事件資料。玄貓已經擁有關於玄貓地理位置和行銷活動的資料，以及關於玄貓轉換事件的描述性資料。
讓玄貓首先看看玄貓系統中已有的資料。玄貓擁有的第一個表是國家地理表，其綱要如下：
圖12.1 – 國家維度綱要
讓玄貓看看這個表的一些範例資料，以便玄貓知道其中包含什麼：
圖12.2 – 國家維度範例資料
批次資料管道建構實務：Spark與Scala應用
238
在圖12.3中，玄貓有一個轉換事件表。它具有以下綱要：
圖12.3 – 轉換事件維度綱要
讓玄貓看看這個表的一些範例資料，以便玄貓知道其中包含什麼：
圖12.4 – 轉換事件維度範例資料
圖12.5中的表是行銷活動表。它具有以下綱要：
圖12.5 – 行銷活動維度綱要
理解資料
239
讓玄貓看看這個表的一些範例資料，以便玄貓知道其中包含什麼：
圖12.6 – 行銷活動維度範例資料
現在玄貓已經了解了玄貓現有系統中的資料，讓玄貓看看玄貓將要攝取的資料：
{
"country": "GB",
"marketing_campaign": "digital_mkting_02",
"event_info": {
"event_type": "Follow Social Media",
"event_ts": "2021-08-08T17:33:00.000Z"
}
}
上述JSON是來自玄貓營運團隊的資料範例。第一個元素是兩個字元的國家代碼。首先，玄貓需要檢查玄貓是否可以將玄貓的內部資料與玄貓在此資料集中看到的值進行連接。玄貓可以看到玄貓可以使用兩個字元的ISO國家代碼將資料連接到玄貓的國家表。為了將資料連接到玄貓的行銷活動表，玄貓將使用活動代碼列。最後，對於事件類型，玄貓必須從JSON陣列中獲取資料，然後將其連接到玄貓的轉換事件表中的轉換事件列。
批次資料管道建構實務：Spark與Scala應用
240
回顧上一節玄貓的行銷指標：
- 按行銷活動劃分的轉換事件數量
- 按地理位置劃分的轉換事件數量
- 按行銷活動劃分，從高到低排名的哪些轉換事件被驅動最多
現在玄貓已經了解了玄貓的資料結構和值，讓玄貓建立一個維度模型，讓玄貓可以獲得這些指標。
圖12.7 – 轉換事件模型的實體關係圖
圖12.7代表了玄貓將創建的維度模型的實體關係圖（ERD），以滿足行銷部門提供的報告要求。玄貓將使用現有表，接收玄貓的輸入資料，並進行一些轉換和查找以添加正確的維度鍵。該圖表示具有關係的物理資料模型。它顯示了玄貓希望達到的最終狀態，以便為玄貓的相關者提供資料。
現在，讓玄貓談談如何實現這一目標。
此圖示：行銷轉換事件資料模型
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
entity "國家維度 (DimCountry)" as DimCountry {
+ country_id: INT <<PK>>
--
country_code: STRING
country_name: STRING
region: STRING
continent: STRING
}
entity "行銷活動維度 (DimMarketingCampaign)" as DimMarketingCampaign {
+ campaign_id: INT <<PK>>
--
campaign_code: STRING
campaign_name: STRING
campaign_type: STRING
start_date: DATE
end_date: DATE
}
entity "轉換事件維度 (DimConversionEvent)" as DimConversionEvent {
+ event_id: INT <<PK>>
--
event_type_name: STRING
event_description: STRING
}
entity "轉換事件事實表 (FactConversionEvent)" as FactConversionEvent {
+ fact_id: BIGINT <<PK>>
--
+ country_id: INT <<FK>>
+ campaign_id: INT <<FK>>
+ event_id: INT <<FK>>
--
event_timestamp: TIMESTAMP
--
-- 測量指標 --
conversion_count: INT
}
DimCountry ||--o{ FactConversionEvent : "1" 國家對多個轉換事件
DimMarketingCampaign ||--o{ FactConversionEvent : "1" 活動對多個轉換事件
DimConversionEvent ||--o{ FactConversionEvent : "1" 事件類型對多個轉換事件
note right of FactConversionEvent
- 核心事實表，記錄每次轉換事件的發生
- 包含外鍵指向各維度表
- 包含事件時間戳和計數等測量指標
- 用於分析行銷活動效果
end note
note right of DimCountry
- 提供國家相關的描述性資訊
- 方便按地理位置分析
end note
note right of DimMarketingCampaign
- 提供行銷活動的詳細資訊
- 方便按活動類型、時間範圍分析
end note
note right of DimConversionEvent
- 提供轉換事件類型的描述
- 方便按事件類型分析
end note
}
}
}
@enduml
看圖說話：
此圖示展示了一個典型的星型模式（Star Schema）資料模型，專為行銷轉換事件分析而設計。模型由一個核心事實表和三個維度表組成，旨在滿足行銷部門提出的報告需求，即按行銷活動、地理位置和時間追蹤轉換事件數量及排名。
- 核心事實表：FactConversionEvent（轉換事件事實表）
- 這是模型的核心，記錄了每一次行銷轉換事件的發生。
- 它包含一個主鍵（fact_id）和三個外鍵：
country_id、campaign_id和event_id，這些外鍵分別指向三個維度表，建立了事實表與維度表之間的一對多關係。 - 除了外鍵，它還包含事件發生的時間戳（event_timestamp）和一個測量指標（conversion_count），通常為1，表示一次轉換事件。
- 這個事實表將是玄貓進行聚合分析的基礎，例如計算特定行銷活動在特定國家的購買事件數量。
- 維度表：DimCountry（國家維度）
- 此表儲存了所有與國家地理位置相關的描述性資訊，例如
country_code、country_name、region和continent。 - 它透過
country_id與事實表連接，使得分析結果可以按地理位置進行細分。
- 維度表：DimMarketingCampaign（行銷活動維度）
- 此表包含了所有行銷活動的詳細資訊，例如
campaign_code、campaign_name、campaign_type、start_date和end_date。 - 它透過
campaign_id與事實表連接，使得玄貓可以按行銷活動或活動類型來分析轉換效果。
- 維度表：DimConversionEvent（轉換事件維度）
- 此表定義了所有可能的轉換事件類型及其描述，例如
event_type_name（如「購買」、「問卷回應」）和event_description。 - 它透過
event_id與事實表連接，使得玄貓可以按事件類型來分析行銷效果。
這個維度模型的設計目標是提供一個清晰、高效且易於查詢的結構，以便行銷部門能夠快速地從不同維度（活動、地理位置、事件類型和時間）獲取他們所需的行銷指標，從而支持他們的決策制定。整個批次資料管道的任務就是將原始輸入資料（如JSON格式的轉換事件數據）經過清洗、轉換和查找，最終填充到這個維度模型中。
第十二章：批次資料管道建構實務
理解業務用例與資料特性
- 追蹤社群媒體（Follow social media）：當用戶選擇追蹤社群媒體時，他們選擇接收品牌或個人在
Facebook、X（以前稱為Twitter）或Instagram等社群媒體平台上的更新、貼文和內容。 - 閱讀內容（Read content）：當用戶消費並參與書面或視覺內容時，例如文章、部落格貼文或新聞報導，就會發生閱讀內容事件。
- 下載內容（Download content）：下載內容表示用戶主動檢索數位資產，例如電子書、白皮書或軟體供個人使用。
理解資料
237
玄貓應該始終詢問玄貓的相關者他們想用他們的資料做什麼。行銷部門已經確定了他們希望在資料中追蹤的以下指標：
- 按行銷活動劃分的轉換事件數量
- 按地理位置劃分的轉換事件數量
- 按行銷活動劃分，從高到低排名的哪些轉換事件被驅動最多
讓玄貓繼續了解玄貓的資料，以便玄貓可以確定如何解決這個業務問題。
理解資料
在與玄貓的行銷團隊以及收集玄貓資料的營運團隊交談之後，玄貓現在知道新的傳入資料將是轉換事件資料。玄貓已經擁有關於玄貓地理位置和行銷活動的資料，以及關於玄貓轉換事件的描述性資料。
讓玄貓首先看看玄貓系統中已有的資料。玄貓擁有的第一個表是國家地理表，其綱要如下：
圖12.1 – 國家維度綱要
讓玄貓看看這個表的一些範例資料，以便玄貓知道其中包含什麼：
圖12.2 – 國家維度範例資料
批次資料管道建構實務：Spark與Scala應用
238
在圖12.3中，玄貓有一個轉換事件表。它具有以下綱要：
圖12.3 – 轉換事件維度綱要
讓玄貓看看這個表的一些範例資料，以便玄貓知道其中包含什麼：
圖12.4 – 轉換事件維度範例資料
圖12.5中的表是行銷活動表。它具有以下綱要：
圖12.5 – 行銷活動維度綱要
理解資料
239
讓玄貓看看這個表的一些範例資料，以便玄貓知道其中包含什麼：
圖12.6 – 行銷活動維度範例資料
現在玄貓已經了解了玄貓現有系統中的資料，讓玄貓看看玄貓將要攝取的資料：
{
"country": "GB",
"marketing_campaign": "digital_mkting_02",
"event_info": {
"event_type": "Follow Social Media",
"event_ts": "2021-08-08T17:33:00.000Z"
}
}
上述JSON是來自玄貓營運團隊的資料範例。第一個元素是兩個字元的國家代碼。首先，玄貓需要檢查玄貓是否可以將玄貓的內部資料與玄貓在此資料集中看到的值進行連接。玄貓可以看到玄貓可以使用兩個字元的ISO國家代碼將資料連接到玄貓的國家表。為了將資料連接到玄貓的行銷活動表，玄貓將使用活動代碼列。最後，對於事件類型，玄貓必須從JSON陣列中獲取資料，然後將其連接到玄貓的轉換事件表中的轉換事件列。
批次資料管道建構實務：Spark與Scala應用
240
回顧上一節玄貓的行銷指標：
- 按行銷活動劃分的轉換事件數量
- 按地理位置劃分的轉換事件數量
- 按行銷活動劃分，從高到低排名的哪些轉換事件被驅動最多
現在玄貓已經了解了玄貓的資料結構和值，讓玄貓建立一個維度模型，讓玄貓可以獲得這些指標。
圖12.7 – 轉換事件模型的實體關係圖
圖12.7代表了玄貓將創建的維度模型的實體關係圖（ERD），以滿足行銷部門提供的報告要求。玄貓將使用現有表，接收玄貓的輸入資料，並進行一些轉換和查找以添加正確的維度鍵。該圖表示具有關係的物理資料模型。它顯示了玄貓希望達到的最終狀態，以便為玄貓的相關者提供資料。
現在，讓玄貓談談如何實現這一目標。
探索湖倉一體架構
資料攝取、轉換和準備使用的過程是本節的重點。這個過程有許多不同的邏輯模型，具有各種命名約定。然而，Databricks提出了湖倉一體架構（Medallion Architecture），它可以作為玄貓在思考資料工程管道時的一個良好模型。讓玄貓深入探討它。
探索湖倉一體架構
241
湖倉一體架構，如以下圖所示，是一種資料處理架構，它利用多層次方法來組織、精煉和交付資料，以用於分析和決策目的。此架構中的每一層都具有特定的功能，並為整個資料管道做出貢獻。
圖12.8 – 湖倉一體架構
讓玄貓了解此架構中的每一層：
- 青銅層（Bronze layer）：湖倉一體架構的基礎是青銅層。此層負責資料攝取，並充當原始資料的初始著陸區。來自各種來源（例如資料庫、雲端儲存帳戶、事件匯流排或外部API）的原始資料在此青銅層中收集、儲存和編目。它充當一個不可變的資料湖，其中資料以其原始形式保留，保留所有傳入資料的歷史記錄。
- 白銀層（Silver layer）：白銀層是流程中的下一層，專注於資料轉換和精煉。資料工程師和資料科學家使用此層來清洗、重組和轉換原始資料，使其更適合分析。在此階段執行資料品質檢查和驗證，以確保資料的準確性和一致性。一旦資料在白銀層中處理，它就成為下游分析和報告的可靠來源。
- 黃金層（Gold layer）：黃金層代表湖倉一體架構中資料處理的最後階段。在此層中，資料經過策劃和優化，用於商業智慧和報告目的。它具有高度結構化、豐富化和聚合的特性，以支持複雜的分析查詢和儀表板。黃金層提供了一個受信任且業務就緒的資料集，相關者可以自信地使用它來做出關鍵決策。
透過青銅、白銀和黃金層，湖倉一體架構確保了資料從其原始形式到精煉、業務就緒狀態的系統化和受控流動。這種分層方法使組織能夠高效地管理資料、維護資料沿襲並確保資料品質，同時提供靈活性以滿足各種資料處理要求，包括批處理和即時資料處理。
批次資料管道建構實務：Spark與Scala應用
242
上一節中的實體關係圖（ERD）可以視為玄貓的黃金層。玄貓了解玄貓的來源資料和玄貓的服務層或黃金層，所以現在讓玄貓看看玄貓如何從來源經過青銅、白銀，最後到達玄貓的黃金層。
端到端管道的考量
在玄貓編寫任何程式碼之前，玄貓需要考慮以下事項：
- 資料每日載入；玄貓的處理將在此之後運行…玄貓是排程還是觸發玄貓的處理？
- 玄貓需要一種方法來指定玄貓將要處理的日期
- 玄貓需要考慮如果原始資料集出現問題，可能需要重新處理某個日期
- 玄貓是否需要編寫一個機制來處理多於一天的資料？
- 玄貓是否需要編寫一個機制來重新處理整個資料集？
- 應該實施哪些資料品質規則？
- 玄貓將如何以及在哪裡轉換玄貓的資料？
以下是玄貓如何構建玄貓的Spark/Scala應用程式以滿足這些要求的高級概述：
- 排程或觸發：玄貓可以使用
ADF、Argo、Apache Airflow等排程工具。
此圖示：湖倉一體架構與資料流
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "資料來源" as DataSource
database "青銅層 (Bronze Layer)" as Bronze
database "白銀層 (Silver Layer)" as Silver
database "黃金層 (Gold Layer)" as Gold
actor "業務分析師/決策者" as BusinessUser
rectangle "資料攝取 (Ingestion)" as Ingestion
rectangle "資料清洗與轉換 (Cleansing & Transformation)" as CleansingTransformation
rectangle "資料策劃與聚合 (Curated & Aggregated)" as CuratedAggregated
DataSource --> Ingestion : 原始資料流入
Ingestion --> Bronze : 儲存原始資料 (Immutable)
Bronze --> CleansingTransformation : 讀取原始資料
CleansingTransformation --> Silver : 儲存清洗與轉換後的資料 (可靠來源)
Silver --> CuratedAggregated : 讀取精煉資料
CuratedAggregated --> Gold : 儲存業務就緒資料 (優化分析)
Gold --> BusinessUser : 提供分析與決策支援
note left of Bronze
- 原始資料的初始著陸區
- 資料以原始形式保留
- 歷史記錄保存
end note
note left of Silver
- 數據工程師/科學家工作區
- 清洗、重組、轉換
- 數據品質檢查和驗證
end note
note left of Gold
- 最終階段，為 BI 和報告優化
- 高度結構化、豐富和聚合
- 值得信賴的業務就緒數據集
end note
note bottom of BusinessUser
- 進行複雜分析查詢
- 建立儀表板
- 做出關鍵業務決策
end note
@enduml
看圖說話：
此圖示清晰地呈現了湖倉一體架構（Medallion Architecture）的核心概念及其資料流動，這是一種多層次的資料處理架構，旨在將原始資料逐步精煉為業務就緒的分析資料。
整個架構分為三個主要層次：
- 青銅層（Bronze Layer）：
- 這是資料處理流程的起點，充當原始資料的初始著陸區。
- 來自各種資料來源（如資料庫、雲端儲存、事件流等）的原始資料，會透過資料攝取過程直接進入此層。
- 青銅層的特點是資料以其原始形式保留，不做任何修改，確保了資料的不可變性和完整的歷史記錄。這對於資料沿襲追蹤和問題回溯至關重要。
- 白銀層（Silver Layer）：
- 此層是資料轉換和精煉的核心區域。
- 資料工程師和資料科學家會從青銅層讀取原始資料，並在此層進行清洗、重組和轉換。
- 關鍵的步驟包括資料品質檢查和驗證，以確保資料的準確性和一致性。
- 經過白銀層處理的資料變得更加結構化和可靠，成為下游分析和報告的良好來源。
- 黃金層（Gold Layer）：
- 這是資料處理的最終階段，旨在將資料策劃和優化，以滿足商業智慧（BI）和報告的需求。
- 黃金層的資料通常是高度結構化、豐富化和聚合的，專為支持複雜的分析查詢和儀表板而設計。
- 它提供了一個受信任且業務就緒的資料集，業務分析師和決策者可以直接使用這些資料來做出關鍵業務決策。
透過這種分層方法，湖倉一體架構確保了資料從原始形式到精煉、業務就緒狀態的系統化和受控流動。它不僅有助於高效管理資料、維護資料沿襲和確保資料品質，同時也提供了靈活性以適應批處理和即時資料處理等多種資料處理要求。
縱觀現代資料工程的實務挑戰，本章節從業務需求到技術實現的端到端檢視，清晰地揭示了建構一個穩健批次資料管道的核心邏輯。其精髓在於，技術方案的選擇始終服務於明確的商業目標——從行銷部門的分析指標出發，倒推出最適合的維度模型，最終選擇架構來實現此一過程。
深入剖析後可以發現，從原始 JSON 事件到星型維度模型的轉換，不僅是資料格式的改變，更是從混亂到有序的價值提煉。其中，湖倉一體（Medallion）架構扮演了關鍵指導角色，其青銅、白銀、黃金的分層設計，為資料的清洗、驗證與聚合提供了系統性框架，有效應對了資料重處理、品質監控等複雜維運挑戰，確保了最終產出的「黃金層」資料具備高度可信度與業務即用性。
我們預見，這種分層架構不僅是為滿足當前的報告需求，更是為企業打造可信賴、可複用的資料資產奠定基礎。隨著黃金層資料的日益豐富，其應用將從單純的行銷報表，擴展至更複雜的預測分析與機器學習場景。
玄貓認為，一個成功的資料管道，其價值不僅在於程式碼的執行效率，更在於其架構設計的前瞻性與穩健性。對於追求卓越的資料工程師而言，掌握這種從終局（黃金層模型）倒推設計，並以分層架構管理過程的系統方法，將是其從執行者邁向架構師的關鍵一步。