資料工程管線架構設計

– 15 分鐘閱讀

從資料消費者需求出發，逐步推演資料管線架構設計。首先釐清資料分析師、資料科學家和業務使用者的資料使用方式及工具，接著盤點 MySQL、Salesforce 和行動應用程式等資料來源，並考量擷取頻率和潛在工具。後續將原始資料轉換為 Parquet 格式，進行資料標準化、品品檢查、分割槽、反正規化等最佳化，最後載入資料集市，供不同資料消費者使用。白板會議有助於凝聚共識，並收集更詳細的設計資訊，例如標準化欄位定義、業務後設資料需求、資料分割槽策略和合適的轉換引擎等。

架構資料工程管線

在瞭解了資料工程的基本原則、核心概念和可用的AWS工具後，我們現在可以將這些知識結合起來，形成一個資料管線。資料管線是一個從多個來源擷取資料、最佳化和轉換資料，並使其可供資料消費者使用的過程。資料工程角色的一個重要職責是設計或架構這些管線。

在本章中，我們將涵蓋以下主題：

  • 處理資料管線架構任務的方法
  • 識別資料消費者並瞭解他們的需求
  • 識別資料來源並擷取資料
  • 識別資料轉換和最佳化
  • 將資料載入資料集市
  • 完成白板會議
  • 實作 - 架構一個範例管線

技術需求

在本實驗的實作部分，我們將設計一個高層級的管線架構。您可以在實際的白板、紙張上或使用名為diagrams.net的免費線上工具來完成此活動。如果您想使用此線上工具，請確保您可以存取http://diagrams.net。

處理資料管線架構

在探討將納入架構的各個元件的細節之前，先對我們要做的事情有一個高層級的瞭解是非常有幫助的。

在開始一個新的資料工程專案時，一個常見的錯誤是試圖一次性完成所有事情，並建立一個涵蓋所有使用案例的解決方案。更好的方法是識別一個初始的、特定的使用案例，並在關注該結果的同時開始專案，但同時要牢記更大的圖景。

這可能是一個重大的挑戰，但正確處理這種平衡非常重要。雖然您需要專注於可以在合理時間內完成的、可實作的結果，但您還需要確保在能夠用於未來專案的框架內進行構建。如果每個業務部門獨立處理資料分析的挑戰，而沒有公司範圍內的分析計劃，那麼很難釋放公司範圍內資料的價值。

圖表1：資料管線架構的高階檢視

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title 圖表1：資料管線架構的高階檢視

rectangle "擷取" as node1
rectangle "載入" as node2
rectangle "分析" as node3

node1 --> node2
node2 --> node3

@enduml

此圖示展示了資料管線的基本流程，從資料來源到資料消費者。

理想的專案將包括來自組織最高層的支援，但將確定一個有限範圍的專案來建立初始框架。這個專案完成後，可以用作內部案例研究，以推動其他分析專案。

在1989年的電影《夢幻成真》中，一位農民（由凱文·科斯納飾演）聽到一個聲音說：“如果你建造了它，他就會來。”

在商業中，一個常見的信條已經變成：“如果你建造了它，他們就會來。”這意味著如果你建造了真正好的東西，你就會找到客戶。但這不是建立資料分析解決方案的推薦方法。

一些組織可能有數百甚至數千個資料來源，其中許多可能對集中式分析有用。但這並不意味著我們應該立即將它們全部擷取到我們的分析平台中，以便我們可以看到業務如何使用它們。當組織採取這種方法時，往往會失敗。

內容解密：

上述圖表展示了一個基本的資料管線架構，包括四個主要部分：

  1. 資料來源：這是資料的原始出處，可能包括資料函式庫、日誌檔案、外部API等。
  2. 資料轉換：這一步驟涉及對原始資料進行處理和轉換，使其更適合分析。
  3. 資料集市：這是經過轉換後的資料被載入的地方，用於支援分析和報告。
  4. 資料消費者：這指的是使用經過處理的資料進行決策、分析或其他業務用途的人員或系統。

相反，一旦獲得了執行層的支援並確定了一個有限範圍的初始專案，資料工程師就可以開始設計該專案的資料管線。

架構房屋與架構管線

如果你要建造一棟新房子，你會先確定一塊合適的土地，然後僱請一位建築師與你合作來制定建築計劃。建築師會做以下幾件事：

  • 與你討論你的需求（你希望如何使用這棟房子，你想要什麼材料，多少臥室、浴室等）。
  • 收集有關你要建造房子的土地的資訊（土地的大小、坡度等）。
  • 確定最適合該環境的建築材料型別。

作為此過程的一部分，建築師可能會建立一個粗略的草圖，顯示高層級的計劃。一旦該高層級計劃獲得批准，建築師就可以收集更多詳細資訊，然後建立詳細的架構計劃。該計劃將包括房間的佈局，然後是淋浴、馬桶、燈等的佈置，並根據此確定管道和電線的佈局。

內容解密：

上述段落透過類別比建造房屋來說明架構資料管線的重要性。主要步驟包括：

  1. 瞭解需求：明確專案的需求和目標。
  2. 收集資訊：收集有關可用資源和限制的資訊。
  3. 制定計劃：根據收集到的資訊，制定一個詳細的計劃。

透過這種類別比，我們可以看到架構一個成功的資料管線需要仔細規劃和對需求的深入理解。

資料工程管線架構設計

資料工程師在建立資料管線的架構時，可以採用類別似的方法：

  • 從專案發起人和資料消費者那裡收集他們的需求資訊。瞭解他們的目標是什麼，他們想要使用什麼工具來消費資料，需要什麼樣的資料轉換等等。
  • 收集有關可用資料來源的資訊。這可能包括儲存原始資料的系統、資料的格式、系統和資料的所有者等。
  • 決定哪些型別的工具可用且最適合這些需求。

白板會議作為資訊收集工具

與相關利益相關者進行白板會議，可以幫助資料工程師制定資料管線的高階計劃，並收集開始進行詳細設計所需的資訊。白板會議的目的不是要解決所有的技術細節並最終確定將要使用的特定服務和工具。相反，其目的是與利益相關者達成對管線整體方法的共識，並收集詳細設計所需的資訊。

本文中，我們將採用一種架構方法，將資料引入根據 Amazon S3 的資料湖中。資料最初被引入原始區域，然後我們使用多種工具對資料進行轉換和最佳化，將資料移動到不同的資料湖區域。正如我們在第2章《用於分析的資料管理架構》中所介紹的，資料湖有多個區域，資料會在這些區域中移動。通常，這些區域包括原始、轉換、規範和豐富等，但也可能包括暫存和推斷（用於資料科學目的）等區域。資料湖所需的區域數量沒有特定的規定，因為區域應該根據業務需求而定，但為了我們的白板會議，我們將展示三個區域。

根據資料消費需求，我們可能會將資料的子集載入到各種資料集市中（如 Amazon Redshift，一種雲端資料倉儲服務），透過各種服務使資料可供資料消費者使用。

資料管線架構設計方法

在設計管線時，我們可以採用以下順序（也反映在前面的圖表中）：

  1. 瞭解業務目標和資料消費者的身份及其需求
  2. 確定資料消費者將用來存取資料的工具型別
  3. 瞭解可能可用的潛在資料來源
  4. 確定將用於引入資料的工具集型別
  5. 在高層次上了解所需的資料轉換，以將原始資料準備好供資料消費者使用

正如您所看到的，在設計管線時，我們應該始終從後往前推。即，我們應該從資料消費者及其需求開始，然後從那裡開始設計我們的管線。

進行白板會議

一旦確定了初始專案，資料工程師就應該召集相關利益相關者參加研討會，以白板形式討論高階方法。理想情況下，所有利益相關者都應親自出席，準備一個白板，並計劃半天的研討會。利益相關者應該包括能夠回答以下問題的一組人員：

  • 誰是執行發起人，專案的業務價值和目標是什麼？
  • 誰將直接使用資料（資料消費者）？ 資料消費者可能會使用什麼型別的工具來存取資料？
  • 相關的原始資料來源是什麼？
  • 在高層次上，需要什麼型別的轉換來轉換和最佳化原始資料？

識別資料消費者並瞭解他們的需求

一個典型的組織可能有多個不同的類別或型別的資料消費者。在白板會議期間，資料工程師應該詢問問題以瞭解所識別專案的資料消費者是誰。同時，瞭解每個資料消費者可能想要使用什麼型別的工具來存取資料也很重要。

資料消費者型別

  • 業務使用者：業務使用者通常希望透過互動式儀錶板和其他視覺化型別存取資料。例如，銷售經理可能希望檢視按業務代表、地理區域或熱門產品類別劃分的上週銷售額圖表。
  • 業務應用程式：在某些使用案例中，資料工程師構建的資料管線將用於為其他業務應用程式提供動力。例如，Spotify 這樣的串流媒體音樂應用程式，會為使用者提供應用內總結他們在過去一年中的聆聽習慣（最喜歡的歌曲、型別、總播放時長等）。
  • 資料分析師：資料分析師通常負責進行更複雜的資料分析，深入挖掘大型資料集以回答特定問題。例如，您可能想知道不同年齡或社會經濟人口統計中最受歡迎的產品是什麼。
  • 資料科學家：資料科學家負責建立機器學習模型，可以識別大型資料集中的非明顯模式，或根據歷史資料預測未來行為。

白板圖示範例

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title 白板圖示範例

rectangle "使用儀錶板" as node1
rectangle "呼叫API" as node2
rectangle "使用SQL查詢" as node3
rectangle "存取原始資料" as node4

node1 --> node2
node2 --> node3
node3 --> node4

@enduml

此圖示說明瞭不同型別的資料消費者如何存取資料。

  • 業務使用者透過儀錶板存取資料
  • 業務應用程式透過API呼叫存取資料
  • 資料分析師使用SQL查詢存取資料
  • 資料科學家直接存取原始資料

內容解密：

此圖示呈現了不同型別的資料消費者與資料存取之間的關係。每種型別的消費者都有不同的資料存取需求和方式，圖中清晰地展示了這些不同的存取路徑和方式。

資料工程管線的架構設計

在這個範例中，我們已經識別出三個不同的資料消費者——資料分析團隊、資料科學團隊和各種業務使用者。同時，我們也瞭解到以下需求：

  • 資料分析師希望使用即席SQL查詢來存取資料
  • 資料科學團隊希望同時使用即席SQL查詢和專門的機器學習工具來存取資料
  • 業務使用者希望使用商業智慧（BI）資料視覺化工具來存取資料

詢問是否存在企業標準工具供資料消費者使用是很有用的，但目前並不需要最終確定工具集。例如，我們應該記錄團隊是否已經有使用Tableau（常見的BI應用程式）的經驗，以及他們是否希望將其用於資料視覺化報告。但如果他們尚未確定將使用的特定工具集，可以在稍後階段再最終確定。

一旦我們對專案的資料消費者及其希望使用的工具型別有了深入的瞭解，就可以進入白板討論的下一個階段，即檢查可用的資料來源和資料擷取方法。

識別資料來源和擷取資料

瞭解專案的整體業務目標並識別出資料消費者後，我們可以開始探索可用的資料來源。大多數資料來源將是組織內部的，但某些專案可能需要用第三方資料來源來豐富組織擁有的資料。如今，有許多資料市場可以訂閱多樣化的資料集，或者在某些情況下，可以免費存取。在討論資料來源時，應同時考慮內部和外部資料集。

參與工作坊的團隊應包括瞭解專案所需資料來源的人員。資料工程師需要收集的有關這些資料來源的資訊包括：

  • 包含資料的來源系統的詳細資訊（資料是否儲存在資料函式庫中、伺服器上的檔案中、Amazon S3上的現有檔案中、來自串流來源等）？
  • 如果這是內部資料，誰是業務中來源系統的所有者？誰是資料的所有者？
  • 需要以什麼頻率擷取資料（連續串流/複製、每隔幾小時載入資料、每天載入一次資料）？
  • 可選地，討論一些可能用於資料擷取的潛在工具。
  • 資料的原始/擷取格式是什麼（CSV、JSON、原生資料函式庫格式等）？
  • 資料來源是否包含個人識別資訊或其他受治理控制的資料型別？如果是，需要採取什麼控制措施來保護資料？

在收集資訊的過程中，可以將其捕捉到白板上，如下圖所示：

圖示：白板上的資料來源和資料擷取

此圖示呈現了白板上記錄的各種資料來源和相關資訊，包括來源系統、所有者和擷取頻率等。

在這個範例中，我們已經識別出三個不同的資料來源——來自MySQL資料函式庫的客戶資料、來自Salesforce的機會資訊和來自組織行動應用程式的近乎實時的銷售指標。同時，我們也瞭解到以下資訊：

  • 擁有每個來源系統的業務團隊和擁有資料的業務團隊
  • 擷取資料的速度（每個資料來源需要被擷取的頻率）
  • 可用於擷取資料的潛在服務

在討論擷取工具時，如果對可能適合的工具有很好的瞭解，那麼捕捉潛在工具可能是值得的。然而，本次會議的目的不是提出最終架構和對所有技術元件的決定。後續會議（正如本文後面所討論的）將用於根據需求徹底評估潛在的工具集，並且應該與來源系統所有者密切協商後進行。

在本次白板會議中，我們一直以倒序方式進行，首先識別出資料消費者，然後識別出我們計劃使用的資料來源。現在，我們可以進入白板討論的下一個階段，即檢查我們計劃用來最佳化資料以進行分析的一些資料轉換。

識別資料轉換和最佳化

在典型的資料分析專案中，我們從多個資料來源中擷取資料，然後對這些資料集進行轉換，以最佳化它們以滿足所需的分析需求。在第7章《轉換資料以最佳化分析》中，我們將更深入地探討典型的轉換和最佳化，但我們將在此提供最常見轉換的高階概述。

檔案格式最佳化

CSV、XML、JSON和其他型別的純文字檔案通常用於儲存結構化和半結構化資料。這些檔案格式在手動瀏覽資料時很有用，但在根據電腦的分析中，使用更好的二進位制檔案格式會更有效率。一個常見的針對讀取密集型分析進行最佳化的二進位制格式是Apache Parquet格式。常見的轉換是將純文字檔案轉換為最佳化的格式，例如Apache Parquet。

-- 將CSV檔案轉換為Apache Parquet格式
CREATE TABLE my_parquet_table
STORED AS PARQUET
AS SELECT * FROM my_csv_table;

內容解密：

此SQL命令展示瞭如何將CSV檔案轉換為Apache Parquet格式。首先，建立一個名為my_parquet_table的新表，並指定儲存格式為Parquet。然後，使用AS SELECT * FROM my_csv_table將my_csv_table中的所有資料插入到新表中。這樣，資料就被轉換為Parquet格式，適用於高效能的分析查詢。

在資料工程管線中，識別出合適的資料轉換和最佳化策略至關重要。這不僅能提高分析效率，還能更好地滿足業務需求。因此，在設計資料工程管線時，必須充分考慮資料轉換和最佳化的需求，以實作最佳效能。

資料轉換與最佳化策略在資料工程管線中的關鍵作用

在建立資料工程管線時，資料轉換與最佳化是至關重要的環節。這些過程不僅能提升資料的品質和可用性，還能顯著改善分析查詢的效能。本篇文章將探討資料標準化、資料品品檢查、資料分割槽、資料反正規化以及資料目錄建立等關鍵策略，並闡述如何在白板會議中有效地規劃這些轉換過程。

資料標準化：統一資料格式與欄位名稱

當從多個不同的資料來源載入資料時，每個來源可能使用不同的命名慣例來指代相同的專案。例如，代表個人出生日期的欄位可能被命名為 DOB、dateOfBirth 或 birth_date，而日期格式也可能有所不同，如 mm/dd/yy 或 dd/mm/yyyy。為了最佳化資料以供分析使用，標準化欄位名稱、型別和格式是必要的步驟。

透過建立企業級的分析程式，可以在整個組織內的所有分析專案中採用標準化的定義。這不僅能提高資料的一致性，還能簡化後續的資料處理和分析工作。

資料品品檢查：確保資料的可靠性和準確性

在進行資料轉換時，驗證資料品質並突出不符合預期品質標準的資料是一個重要的方面。透過實施嚴格的資料品品檢查，可以確保進入分析系統的資料是準確、完整且可靠的。

資料分割槽：提升查詢效能

對於分析工作負載，一種常見的最佳化策略是根據查詢中經常使用的欄位對資料進行物理儲存層的分割槽。例如，如果資料經常按照日期範圍進行查詢，那麼可以按照日期欄位對資料進行分割槽。如果儲存銷售資料，所有特定月份的銷售交易將被儲存在同一個 Amazon S3 字首（類別似於目錄）中。當執行查詢選取特定日期的資料時，分析引擎只需要讀取儲存相關月份資料的目錄中的資料。

# 以日期欄位對銷售資料進行分割槽的範例
import pandas as pd

# 假設 sales_data 是包含銷售交易資料的 DataFrame
sales_data = pd.read_csv('sales_data.csv')

# 將 sales_data 按照日期欄位進行分割槽儲存
sales_data['date'] = pd.to_datetime(sales_data['date'])
sales_data['year_month'] = sales_data['date'].dt.strftime('%Y-%m')

# 按照 year_month 欄位進行分割槽儲存
for year_month, data in sales_data.groupby('year_month'):
    data.to_parquet(f'sales_data/{year_month}.parquet', index=False)

內容解密：

  1. 日期欄位的處理：首先，將 date 欄位轉換為 datetime 格式，以便後續處理。
  2. 建立分割槽欄位：建立 year_month 欄位，用於表示資料所屬的年份和月份，方便後續的分割槽儲存。
  3. 分割槽儲存：使用 groupby 方法按照 year_month 欄位對資料進行分組，並將每組資料儲存為獨立的 Parquet 檔案，檔名包含對應的年份和月份。
  4. Parquet 格式：選擇 Parquet 格式儲存資料，因為它是一種高效的列式儲存格式，適合於分析工作負載。

資料反正規化：提升查詢效能

在傳統的關聯式資料函式庫系統中，資料通常是正規化的，這意味著每個表格包含特定主題的資訊，而相關資訊則儲存在單獨的表格中。這些表格可以透過外部索引鍵相互連結。

然而，在資料湖中，將多個表格的資料合併到單一表格中往往可以提高查詢效能。資料反正規化涉及將兩個或多個表格的資料合併成一個新的表格。

-- 將客戶資訊和訂單資訊反正規化為一個表格的範例
SELECT 
    c.customer_id,
    c.name,
    c.email,
    o.order_id,
    o.order_date,
    o.total_amount
INTO 
    customer_orders
FROM 
    customers c
JOIN 
    orders o ON c.customer_id = o.customer_id;

內容解密：

  1. 選擇合適的欄位：從 customers 和 orders 表格中選取需要的欄位，包括客戶資訊和訂單資訊。
  2. JOIN 操作：使用 INNER JOIN 將 customers 和 orders 表格按照 customer_id 欄位進行連線，合併相關的客戶和訂單資訊。
  3. 建立新表格：將合併後的結果儲存到新的 customer_orders 表格中，實作資料的反正規化。
  4. 提升查詢效能：透過將相關資訊儲存在單一表格中，可以減少查詢時所需的 JOIN 操作，從而提高查詢效能。

資料目錄建立：提升資料可發現性

在我們的管線架構中的轉換部分，另一個重要的組成部分是對資料集進行目錄建立。在此過程中，我們確保資料湖中的所有資料集都在資料目錄中有參考記錄，並可以新增額外的業務後設資料。

白板會議規劃資料轉換

在白板會議中，我們不需要確定所有所需的轉換細節，但對於高層次的管線設計，達成主要轉換的共識是有用的。資料工程師需要收集有關預期資料轉換的一些資訊，包括：

  • 是否存在可參考的標準化列名定義和格式？如果沒有，誰將負責建立這些標準定義？
  • 應該為資料集捕捉哪些額外的業務後設資料？例如，資料所有者、成本分配標籤、資料敏感性等。
  • 最佳化的檔案應該以何種格式儲存？Apache Parquet是一種常見的格式，但需要驗證資料消費者使用的工具是否能夠處理Apache Parquet格式的檔案。
  • 是否有明顯的欄位可以用於資料分割槽？
  • 目前是否明顯需要其他資料轉換？例如，如果正在攝取來自關聯式資料函式庫的資料，是否應該對資料進行反正規化？
  • 團隊具備哪些資料轉換引擎/技能？例如，團隊是否具有使用PySpark建立Spark作業的經驗？

透過在白板會議上收集和記錄這些資訊，可以有效地規劃和設計資料轉換過程，為建立高效、可靠的資料工程管線奠定基礎。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。