資料工程管線架構設計與資料擷取

– 14 分鐘閱讀

資料工程管線的設計需考量多種因素，包含資料的多樣性、數量、速度以及資料消費者的需求。白板會議能有效促進團隊溝通，釐清專案目標並凝聚共識。針對不同型別的資料，需要選擇合適的擷取工具和策略。例如，關係型資料函式庫適用 DMS 進行批次擷取，而網站日誌等串流資料則可利用 Kinesis 進行即時擷取。此外，資料的格式也影響著後續的處理流程，結構化資料可以直接載入資料湖，而半結構化和非結構化資料則可能需要額外的轉換步驟。

資料工程管線架構設計：白板會議的實踐

在進行資料工程管線的架構設計時，白板會議（whiteboarding session）是一個至關重要的步驟。這個過程的目的不是要解決所有的技術細節，而是要建立一個高層次的管線概覽。在前面的圖表中，我們並沒有明確指出將使用AWS Glue作為轉換引擎。我們知道AWS Glue可能是一個合適的選擇，但現在做出這個決定並不重要。

決定資料轉換和分割策略

我們已經指出了一個根據日期的潛在分割策略，但這也需要進一步的驗證。要確定最佳的分割策略，需要對將對資料集執行的查詢有深入的瞭解。在白板會議中，不太可能有時間探討這些細節，但在初步討論後，這似乎是一種分割資料的好方法，因此我們將其納入考量。

將資料載入到資料集市

許多工具可以直接與資料湖中的資料一起工作，如第3章《AWS資料工程師工具包》中所述。這些工具包括用於臨時SQL查詢（Amazon Athena）、資料處理工具（如Amazon EMR和AWS Glue），甚至是專門的機器學習工具（如Amazon SageMaker）。這些工具直接從Amazon S3讀取資料，但在某些情況下，可能需要更低的延遲、更高的效能來讀取資料。或者，在某些情況下，使用高度結構化的模式可能最符合分析需求。在這些情況下，將資料從資料湖載入到資料集市是有意義的。

在分析環境中，資料集市通常是一個資料倉儲系統（如Amazon Redshift），但也可能是一個關聯式資料函式庫系統（如Amazon RDS MySQL），具體取決於使用案例的需求。無論哪種情況，系統都將具有本地儲存（通常是高速快閃記憶體驅動器）和本地計算能力，在需要跨大型資料集查詢時提供最佳效能，特別是在需要跨多個表進行連線查詢時。

白板會議後的預期成果
  • 對該專案的資料消費者有深入的瞭解
  • 對每類別資料消費者使用的工具型別有深入的瞭解（SQL、視覺化工具等）
  • 對將使用的內部和外部資料源有深入的瞭解
  • 對每個資料源的資料攝取頻率需求有深入的瞭解（例如，每日、每小時或近實時流式傳輸）
  • 對每個資料源的所有權有深入的瞭解，包括資料所有者和源系統所有者
  • 對可能的資料轉換有高層次的瞭解
  • 對是否需要將部分資料載入到資料倉儲或其他資料集市有深入的瞭解

最終的高層次架構圖

根據本章所探討的場景，最終的高層次架構圖可能如下所示：

此圖示展示了管線的主要組成部分及其相互關係。

圖示說明：
  1. 資料來源：內部和外部資料源。
  2. 資料攝取：不同頻率的資料攝取方式。
  3. 資料湖：儲存原始資料的位置。
  4. 資料轉換：使用適當工具進行的資料轉換。
  5. 資料集市：根據需要載入到資料倉儲或其他系統。

在白板會議期間，我們還會記錄與各種架構元件相關的註解。對於本章所討論的場景，記錄的註解可能如下所示：

這些註解提供了有關架構設計決策和假設的重要細節。

實踐白板會議

現在您已經瞭解瞭如何進行白板會議的理論，接下來是時候獲得一些實際的操作經驗了。下一節將提供有關一個虛構白板會議的詳細資訊，並讓您練習白板會議的技能。

實作：設計範例資料管線

在本章的實作部分，您將審閱 GP Widgets Inc. 這家虛擬公司所舉行的白板會議詳細紀錄。在閱讀這些紀錄時，您應該建立一個白板架構，可以實際在白板上或是在海報板上建立。或者，您也可以使用免費的線上設計工具，例如 http://diagrams.net 提供的工具來建立白板。

作為白板會議的起點，您可以使用以下範本。您可以重新建立這個範本在您的白板或海報板上，或者您可以透過本文的 GitHub 網站存取 diagrams.net 的範本：

圖 5.7 - 通用白板範本

請注意，範本中包含的三個區域（原始區、清理區和精選區）通常用於資料湖。然而，一些資料湖可能只有兩個區域，而其他的可能有四個或更多的區域。區域的數量並不是一個硬性規定，而是根據您正在設計的案例需求而定。

在閱讀會議紀錄時，請填寫範本的相關部分。除了繪製管線的元件和流程外，您還應該捕捉與白板元件相關的註解，如圖 5.6 中的範例所示。在本章結束時，您可以將您建立的白板與 GP Widgets 的資料工程師負責人所建立的白板進行比較。

透過完成這個練習，您將獲得實際經驗來設計資料管線，並學習如何識別有關資料消費者、資料來源和所需轉換的關鍵點。

GP Widgets, Inc.「Bright Light」專案白板會議詳細紀錄

與會者

  • Ronna Parish，市場行銷副執行長
  • Chris Taylor，企業銷售副執行長
  • Terry Winship，資料分析團隊經理
  • James Dadd，資料科學團隊經理
  • Owen McClave，資料函式庫團隊經理
  • Natalie Rabinovich，網頁伺服器團隊經理
  • Shilpa Mehta，資料工程師負責人

會議紀錄

Shilpa（SM）首先要求所有人自我介紹，然後總結了會議的目標：

  • 為新的專案規劃高階架構，以改善市場行銷團隊的分析能力。在討論過程中，Shilpa 將在白板上繪製高階架構。
  • 他們強調並非所有的技術細節都將在本次會議中解決，但取得所有利益相關者對高階方法和設計的共識至關重要。
  • 已經達成共識，專案將在 AWS 雲端上建立。

Shilpa 請 Ronna（市場行銷經理）概述市場行銷團隊對「Bright Light」專案的需求：

  • 「Bright Light」專案旨在透過資料分析提高市場行銷團隊對即時客戶行為和長期客戶趨勢的可見度。
  • 市場行銷團隊希望為市場行銷專員提供即時洞察公司電子商務網站上的互動情況。一些視覺化的例子包括熱力圖，以顯示不同地理位置的網站活動；按產品類別兌換的優惠券；頂級廣告活動推薦，以及前一期與當前期間按 ZIP 碼劃分的支出。

內容解密：

此段落描述了「Bright Light」專案的主要目標和需求，包括即時資料分析和視覺化的要求。

資料分析團隊需求

資料分析團隊將支援市場行銷部門進行更複雜的當前和歷史趨勢調查：

  • 識別過去 x 天內消費最高的 10% 客戶，並找出他們最常購買的產品類別，以用於市場行銷促銷。
  • 確定客戶平均在網站上花費的時間，以及他們瀏覽的產品數量與購買的產品數量之比。
  • 識別過去一天/月/週內退貨最多的產品。
  • 比較本月與去年同月按 ZIP 碼劃分的銷售額，並按產品類別分組。
  • 為每位客戶保持一個累計總計，包括他們購買的小工具數量（按類別分組）、每次銷售的平均支出、每月的平均支出、使用的優惠券數量和優惠券總價值。

內容解密：

此段落詳細描述了資料分析團隊的需求，包括複雜的資料分析和報告要求。

資料科學團隊需求

資料科學團隊將建立一個機器學習模型，以根據特定地點的天氣預測小工具的熱門程度：

  • 研究表明，天氣可以影響電子商務銷售和特定產品的銷售；例如，顧客在晴天與寒冷雨天可能購買的小工具型別不同。
  • 市場行銷團隊希望根據特定 ZIP 碼的當前和預測天氣來最佳化廣告活動和即時市場行銷活動。
  • 由於我們定期向產品目錄中新增新的小工具，因此模型必須至少每天更新一次，以反映最新的天氣和銷售資訊。
  • 除了幫助市場行銷外，製造和物流團隊也對此模型感興趣，以幫助最佳化不同倉函式庫的物流和庫存，根據 7 天天氣預報。

內容解密：

此段落描述了資料科學團隊的需求，包括建立機器學習模型以預測產品熱門程度，並根據天氣預報最佳化業務營運。

白板架構設計

根據上述會議紀錄，請使用提供的範本設計一個白板架構，包括以下元件：

  1. 資料來源：電子商務網站、客戶資料、產品資料、天氣資料等。
  2. 資料處理：使用 AWS 服務進行資料處理和轉換。
  3. 資料儲存：使用 AWS 服務進行資料儲存和管理。
  4. 資料分析：使用 AWS 服務進行資料分析和視覺化。
  5. 機器學習：使用 AWS 服務建立機器學習模型。

圖示：此圖示呈現了「Bright Light」專案的高階架構

內容解密：

此圖示呈現了「Bright Light」專案的高階架構，包括資料來源、資料處理、資料儲存、資料分析和機器學習等元件。AWS Kinesis 用於即時資料串流，AWS Glue 用於資料轉換，AWS S3 用於資料儲存，AWS Redshift 用於資料分析，AWS SageMaker 用於建立機器學習模型。

專案Bright Light的資料工程管線架構設計

在專案Bright Light的會議中，Shilpa與多位團隊成員進行了深入的討論，針對資料科學和資料分析團隊的需求進行了詳細的規劃。以下是會議內容的重點整理和架構設計的詳細說明。

會議重點整理

  1. 資料需求：

    • 資料科學團隊需要臨時存取過去一年的氣象資料、網站點選流日誌和銷售資料。
    • 資料分析團隊需要存取客戶、產品、退貨和銷售資料函式庫，以及網站伺服器日誌的點選流資料。

  2. 資料來源：

    • 氣象資料：透過AWS Data Exchange取得每日更新的CSV格式資料。
    • 資料函式庫資料：所有資料函式庫均在本地執行，使用Microsoft SQL Server 2016 Enterprise Edition。
    • 網站點選流日誌：目前執行在本地Linux伺服器上的Apache HTTP Server，每個伺服器本地儲存日誌檔案。

  3. 技術需求：

    • 資料科學團隊使用SparkML進行機器學習專案，希望採用雲端工具加速交付和協作。
    • 資料分析團隊專注於使用SQL查詢資料，對於資料湖技術持開放態度，只要能使用SQL查詢資料即可。

架構設計

根據會議內容，Shilpa提出了以下架構設計：

  1. 資料擷取：

    • 使用AWS Database Migration Service（DMS）將本地Microsoft SQL Server資料函式庫的資料複製到Amazon S3。
    • 使用Kinesis Agent讀取Apache HTTP Server日誌檔案，並將其轉換為JSON格式後傳輸到Kinesis Firehose。

  2. 資料轉換和儲存：

    • 將來自AWS Data Exchange的CSV格式氣象資料直接載入到資料湖的原始區。
    • 使用DMS將資料函式庫資料載入到資料湖的原始區，儲存為Parquet格式。
    • Kinesis Firehose對日誌資料進行基本驗證（使用Lambda），轉換為Parquet格式後寫入資料湖的清理區。

  3. 資料處理和最佳化：

    • 初始轉換：對資料進行基本品品檢查，新增上下文資訊（如擷取時間），並寫入資料湖的清理區。
    • 第二階段轉換：對清理區的資料進行反正規化、表連線、資料豐富化等業務邏輯處理，結果寫入資料湖的精選區。

  4. 資料查詢和分析：

    • 使用Amazon Athena對資料湖中的資料進行SQL查詢。
    • 將資料新增到資料目錄，並新增業務後設資料，如資料所有者、來源系統、資料敏感度等。

圖表說明

下圖展示了專案Bright Light的整體架構設計：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 資料工程管線架構設計與資料擷取

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

此圖示展示了從本地資料函式庫、AWS Data Exchange和Apache HTTP Server日誌到S3資料湖的資料流，以及如何透過不同的AWS服務進行資料轉換和查詢。

內容解密：

  1. DMS的使用：AWS DMS用於將本地資料函式庫的資料遷移到S3，簡化了資料遷移過程並減少了對本地資料函式庫的影響。
  2. Kinesis Agent和Firehose的作用：Kinesis Agent負責讀取日誌檔案並傳輸到Firehose，而Firehose則對資料進行驗證和格式轉換，最終寫入S3。
  3. 資料湖的分割槽策略：根據查詢模式對資料進行分割槽，如按天（yyyy/mm/dd）或小時（yyyy/mm/dd/hh）分割槽，以最佳化查詢效能和成本。

資料工程管線的架構設計與資料擷取

在前一章中，我們已經完成了資料工程管線的高階架構設計。本章將探討資料擷取的相關主題，包括批次資料和串流資料的擷取。

資料來源的多樣性

過去十年中，每年產生的資料量和種類別都有顯著的增加。今日，行業分析師以澤字（ZB）為單位來衡量全球每年產生的資料量，1澤字等於10億兆位元組（TB）。根據估計，2012年全球資料量剛超過1澤字，而到2020年底，全球資料消耗量預計將達到59澤字。

在我們的管線白板會議中（在第5章《資料工程管線的架構設計》中討論），我們已經確定了多個需要擷取和轉換的資料來源。對於每個在白板會議中確定的資料來源，我們需要了解其多樣性、數量、速度、正確性和價值。

資料多樣性

過去十年中，用於資料分析專案的資料種類別大大增加。如果所有資料都只是關係型資料函式庫中的資料（曾經幾乎所有資料都是如此），那麼將其轉移到資料分析解決方案中將相對容易。但如今，組織透過分析其他型別的資料（網頁伺服器日誌檔、照片、影片和其他媒體、地理位置資料、感測器和其他物聯網資料等）來發現價值和競爭優勢。

對於管線中的每個資料來源，資料工程師需要確定將要擷取的資料型別。資料通常被歸類別為以下三種型別之一，如下小節所述。

結構化資料

結構化資料是指按照資料模型組織的資料，以一系列列和行的形式表示。每行代表一筆記錄，而列則構成每筆記錄的欄位。

結構化資料檔案中的每個欄位都包含特定型別的資料（例如字串或數字），並且每行都有相同數量和型別的欄位。定義每個記錄中包含哪些欄位以及每個欄位的資料型別，被稱為資料綱要。

常見的包含結構化資料的資料來源包括：

  • 關係型資料函式倉管理系統（RDBMS），如MySQL、PostgreSQL、SQL Server和Oracle
  • 分隔檔案，如逗號分隔值（CSV）檔案或分頁符號分隔值（TSV）檔案
  • 試算表，如xls格式的Microsoft Excel檔案
  • 線上表單中的資料

下表所示為結構化資料的一個例子。在本例中，它是來自美國MyPyramid食品原始資料的幾種食物的卡路里含量資料，可在https://catalog.data.gov/dataset/mypyramid-food-raw-data 獲得。該資料提取已按卡路里含量從高到低排序：

食物名稱卡路里含量
……

結構化資料可以輕易地被擷取到分析系統中，包括根據Amazon S3的資料湖和像Amazon Redshift這樣的資料倉儲。

半結構化資料

半結構化資料與結構化資料有許多相同的屬性，但其結構或綱要不需要嚴格定義。通常，半結構化資料包含內部標籤來標識資料元素，但每個記錄可能包含不同的元素或欄位。

半結構化資料中的某些資料型別可能是強型別的，例如整數值，而其他元素可能包含自由格式的文字等專案。常見的半結構化格式包括JSON和XML檔案格式。

以下是一個半結構化JSON格式檔案的部分內容，用於產品庫存。在本例中，我們可以看到兩種商品：一組電池和一條牛仔褲：

[{
  "sku": 10001,
  "name": "Duracell - Copper Top AA Alkaline Batteries - long lasting, all-purpose 16 Count",
  "price": 12.78,
  ...
}]

程式碼實戰：使用Amazon DMS擷取資料函式庫來源的資料

在實際操作部分，我們將使用Amazon DMS服務從資料函式庫來源擷取資料。首先，您需要具備建立RDS資料函式庫、EC2例項、DMS例項以及新的IAM角色和策略的IAM許可權。

import boto3

# 建立DMS客戶端
dms_client = boto3.client('dms')

# 定義DMS例項
replication_instance_arn = 'your-replication-instance-arn'

# 定義來源和目標端點
source_endpoint_arn = 'your-source-endpoint-arn'
target_endpoint_arn = 'your-target-endpoint-arn'

# 建立DMS任務
task_response = dms_client.create_replication_task(
    ReplicationTaskIdentifier='your-task-identifier',
    SourceEndpointArn=source_endpoint_arn,
    TargetEndpointArn=target_endpoint_arn,
    ReplicationInstanceArn=replication_instance_arn,
    MigrationType='full-load',
    TableMappings='your-table-mappings'
)

# 列印DMS任務ARN
print(task_response['ReplicationTask']['ReplicationTaskArn'])

內容解密：

  1. 首先，我們匯入了boto3函式庫，這是用於與AWS服務進行互動的Python SDK。
  2. 然後，我們建立了一個DMS客戶端，用於與DMS服務進行互動。
  3. 定義了DMS例項、來源和目標端點的ARN，這些是建立DMS任務所需的引數。
  4. 使用create_replication_task方法建立了一個新的DMS任務，並指定了必要的引數，如任務識別符號、來源和目標端點ARN、複製例項ARN、遷移型別和表格對映。
  5. 最後，列印預出了建立的DMS任務ARN。

使用Amazon Kinesis擷取串流資料

在實際操作部分，我們還將使用Amazon Kinesis來擷取串流資料。首先，您需要具備建立Kinesis Data Firehose例項以及佈署CloudFormation範本的IAM許可權。

import boto3

# 建立Kinesis Firehose客戶端
firehose_client = boto3.client('firehose')

# 定義Firehose傳遞流名稱
delivery_stream_name = 'your-delivery-stream-name'

# 建立Firehose傳遞流
response = firehose_client.create_delivery_stream(
    DeliveryStreamName=delivery_stream_name,
    S3DestinationConfiguration={
        'RoleARN': 'your-role-arn',
        'BucketARN': 'your-bucket-arn'
    }
)

# 列印Firehose傳遞流名稱
print(response['DeliveryStreamARN'])

內容解密：

  1. 首先，我們匯入了boto3函式庫。
  2. 然後，我們建立了一個Kinesis Firehose客戶端。
  3. 定義了Firehose傳遞流的名稱。
  4. 使用create_delivery_stream方法建立了一個新的Firehose傳遞流，並指定了必要的引數，如傳遞流名稱和S3目標組態。
  5. 最後，列印預出了建立的Firehose傳遞流ARN。
玄貓 BlackCat

玄貓 BlackCat

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