資料屬性與擷取策略

– 12 分鐘閱讀

資料工程的基礎在於理解資料來源的特性，包含資料型別、資料量、資料速度、資料真實性以及資料價值。不同型別的資料，例如結構化、半結構化和非結構化資料，需要不同的處理方式。資料量和資料速度則影響著我們選擇批次處理或串流處理，以及相關工具的規模和預算。確保資料的真實性與準確性是資料處理流程中不可或缺的一環。最後，所有資料處理的最終目標都是為了挖掘資料價值，為企業帶來實質效益。在實際應用中，從關聯式資料函式庫匯入資料到資料湖是一個常見的需求。AWS 提供了多種工具，例如 AWS DMS 和 AWS Glue，可以協助我們完成這個任務。AWS DMS 適合一次性匯入歷史資料或持續複製資料函式庫中的資料，而 AWS Glue 則是一個更通用的 ETL 工具，可以連線到多種資料來源，並進行資料轉換和載入。除了 AWS 服務外，還有其他商業工具和資料函式庫原生工具可以選擇，例如 Oracle GoldenGate。選擇合適的工具需要考量資料函式庫大小、資料函式庫負載以及資料擷取頻率等因素。對於大型資料函式庫，建議使用 CDC 機制來同步資料更新，以減少對來源系統的負擔。最後，與資料函式庫團隊的溝通和協作至關重要，確保技術方案的相容性和可行性，避免專案延誤。

資料來源的五大屬性：深入瞭解資料特性

在進行資料擷取與處理之前，瞭解資料來源的屬性至關重要。資料屬性主要涵蓋五大導向：資料型別、資料量、資料速度、資料真實性以及資料價值。以下將逐一探討這五大屬性的重要性及其在實際應用中的考量。

資料型別：結構化、半結構化與非結構化資料

資料型別是決定資料處理方式的關鍵因素。常見的資料型別包括結構化、半結構化以及非結構化資料。

結構化資料

結構化資料具有明確的格式與組織，通常儲存在關聯式資料函式庫中，例如客戶資訊、交易記錄等。這類別資料易於搜尋、整理和分析。

半結構化資料

半結構化資料則介於結構化與非結構化之間，具備一定的組織結構，但不像結構化資料那樣嚴格遵循固定的格式。JSON 檔案是一種典型的半結構化資料範例，其層級式結構提供了極大的靈活性，能夠輕鬆處理不同屬性的資料記錄。

[
  {
    "sku": 10001,
    "name": "Duracell MN2400B4Z AAA Batteries",
    "type": "Electronics",
    "price": 9.99,
    "category": [
      {
        "id": "5443",
        "name": "Home Goods"
      }
    ],
    "manufacturer": "Duracell",
    "model": "MN2400B4Z"
  },
  {
    "sku": 10002,
    "name": "Levi's Men's 505 Jeans Fit Pants",
    "type": "Clothing",
    "price": 39.99,
    "fit_type": [
      {
        "id": 855,
        "description": "Regular"
      },
      {
        "id": 902,
        "description": "Big and Tall"
      }
    ],
    "category": [
      {
        "id": 3821,
        "name": "Jeans"
      },
      {
        "id": 6298,
        "name": "Men's Fashion"
      }
    ],
    "manufacturer": "Levi",
    "model": "00505-4891"
  }
]

非結構化資料

非結構化資料則缺乏明確的格式與組織，例如文字檔案、圖片、影片和語音檔案等。雖然這類別資料無法直接進行分析，但可以透過特定工具進行處理，例如使用影像辨識技術提取中繼資料，或利用自然語言處理技術分析文字內容。

資料量：歷史資料與未來增長預測

瞭解資料量對於規劃資料擷取和處理至關重要。需要評估歷史資料的總量以及未來的增長趨勢。例如，一個包含十年歷史資料的資料函式庫總量達到 2.2 TB，每月新增約 30 GB 的資料。根據這些資訊，可以決定是否需要使用 Amazon Snowball 等裝置來傳輸大量歷史資料，並據此規劃 AWS 服務的初始規模和預算。

資料速度：批次處理與串流處理

資料速度決定了資料擷取和處理的方式。批次處理適用於按排程定期擷取的資料，而串流處理則適用於持續不斷產生的即時資料。例如，BMW集團利用AWS服務從數百萬輛汽車中擷取遙測資料，每天處理數TB 的資料。根據業務需求選擇適當的處理方式，例如使用 Amazon Kinesis 進行串流處理，或排程執行 Glue Jobs 處理批次資料。

資料真實性：確保資料品質與準確性

資料真實性關注於資料的品質、完整性和準確性。由於資料來源多樣，可能存在缺失或不一致的情況。例如，IoT 感測器資料可能因裝置離線而缺失部分資料，而使用者表單資料可能包含錯誤或缺失值。因此，需要採用適當的工具和技術來檢測和修正這些問題，例如使用平均值填補缺失資料或檢測無效資料欄位。

資料價值：最終目標與業務價值

最終，所有資料擷取和處理的目的都是為了從資料中挖掘價值，為企業帶來新的洞察和收益。即使我們能夠擷取和處理大量的資料，如果最終的資料產品無法為企業帶來價值，那麼所有的努力都將付諸東流。因此，在整個資料處理流程中，必須時刻關注最終目標，確保每一步驟都能朝著提供業務價值的方向邁進。

綜上所述，深入瞭解資料來源的五大屬性對於成功進行資料擷取和處理至關重要。透過掌握這些屬性，可以更好地規劃和執行資料相關專案，為企業創造更大的價值。

從關聯式資料函式庫匯入資料

在考慮要匯入的資料時，我們需要確保從整體的角度出發，不僅要確認匯入資料的價值，還要了解這些資料如何為企業帶來現在或將來的價值。

需要提出的問題

在第5章「設計資料工程管線」中，我們曾經舉辦了一個工作坊，識別出一些可能需要的資料來源以支援我們的資料分析專案。但是現在，我們需要更深入地收集額外的資訊。

我們需要識別出每個計劃匯入的資料來源的擁有者，然後與資料來源擁有者進行深入的討論，提出以下問題：

  • 資料的格式是什麼（關聯式資料函式庫、NoSQL 資料函式庫、半結構化資料如 JSON 或 XML、非結構化資料等）？
  • 有多少歷史資料可用？
  • 歷史資料的總大小是多少？
  • 每天/每週/每月會產生多少新的資料？
  • 資料目前是否被串流到某個地方，如果是，我們是否可以接入這個資料串流？
  • 資料更新的頻率是多少（不斷更新，如資料函式庫或串流來源，或按排程更新，如每天結束時或收到合作夥伴的每日更新）？
  • 這個資料來源將如何為企業帶來現在或將來的價值？

瞭解更多關於資料的資訊，將有助於我們決定使用哪種服務來匯入資料，並協助初始服務規模的評估和預算的估計。

從關聯式資料函式庫匯入資料

對於分析專案來說，一個常見的資料來源是來自關聯式資料函式庫系統，如 MySQL、PostgreSQL、SQL Server 或 Oracle 資料函式庫。許多組織都有多個孤立的資料函式庫，他們希望將這些不同資料函式庫中的資料集中到一個位置進行分析。

AWS Database Migration Service (DMS)

AWS 提供的主要用於從資料函式庫匯入資料的服務是 AWS Database Migration Service (DMS)，儘管還有其他方法可以從資料函式庫來源匯入資料。作為一名資料工程師，我們需要評估來源和目標，以確定哪種匯入工具最合適。

AWS DMS 主要用於一次性匯入歷史資料或持續複製關聯式資料函式庫中的資料。使用 AWS DMS 時，目標可以是不同的資料函式庫引擎或根據 Amazon S3 的資料湖。在本文中，我們將重點介紹如何從關聯式資料函式庫匯入資料到根據 Amazon S3 的資料湖。

程式碼示例：使用 AWS DMS 設定複製任務

import boto3

dms = boto3.client('dms')

# 設定複製任務
response = dms.create_replication_task(
    ReplicationTaskIdentifier='my-replication-task',
    SourceEndpointArn='arn:aws:dms:REGION:ACCOUNT_ID:endpoint:ENDPOINT_ID',
    TargetEndpointArn='arn:aws:dms:REGION:ACCOUNT_ID:endpoint:ENDPOINT_ID',
    ReplicationInstanceArn='arn:aws:dms:REGION:ACCOUNT_ID:rep:REPLICATION_INSTANCE_ID',
    MigrationType='full-load',  # 或 'cdc' 用於變更資料擷取
    TableMappings='file://table-mappings.json'
)

print(response)

內容解密：

  1. boto3.client('dms')：建立一個與 AWS DMS 服務互動的客戶端。
  2. create_replication_task：建立一個新的複製任務，用於定義從來源到目標的資料遷移過程。
  3. ReplicationTaskIdentifier：指定複製任務的唯一識別符號。
  4. SourceEndpointArn 和 TargetEndpointArn：分別指定來源和目標端點的 ARN。
  5. ReplicationInstanceArn：指定用於執行複製任務的複製例項 ARN。
  6. MigrationType：定義遷移型別，可以是 full-load（一次性完整載入）或 cdc（變更資料擷取，用於持續複製）。
  7. TableMappings：指定一個 JSON 檔案，定義了哪些表需要被遷移以及如何遷移。

AWS Glue

AWS Glue 是另一個可以用來從資料函式庫匯入資料的服務。它是一個 Spark 處理引擎，可以連線到多種不同的資料來源，包括 JDBC 資料來源，從而能夠連線到多種不同的資料函式庫引擎，並透過這些連線傳輸資料進行進一步處理。

程式碼示例：使用 AWS Glue 從資料函式庫匯入資料

from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

# 初始化 Glue 環境
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# 從 MySQL 資料函式庫讀取資料
datasource = glueContext.create_dynamic_frame.from_catalog(
    database="my_database",
    table_name="my_table",
    transformation_ctx="datasource"
)

# 將資料寫入 S3
datasink = glueContext.write_dynamic_frame.from_options(
    frame=datasource,
    connection_type="s3",
    connection_options={"path": "s3://my-bucket/my-path/"},
    format="parquet",
    transformation_ctx="datasink"
)

job.commit()

內容解密：

  1. getResolvedOptions：解析 Glue 作業引數。
  2. GlueContext 和 SparkContext：初始化 Glue 和 Spark 環境。
  3. create_dynamic_frame.from_catalog：從 Glue 資料目錄中讀取指定的 MySQL 資料表。
  4. write_dynamic_frame.from_options：將動態框架寫入 S3，指定輸出格式為 Parquet。

其他從資料函式庫匯入資料的方法

除了 AWS DMS 和 AWS Glue 之外，還有多種其他方法可以將資料從資料函式庫匯入到根據 Amazon S3 的資料湖中。這些方法各有其優缺點和適用場景。選擇最合適的方法取決於具體的需求和限制。

從關聯式資料函式庫匯入資料至資料湖

Amazon EMR 提供了一種簡便的方式來佈署多個常見的 Hadoop 框架工具，其中一些工具對於從資料函式庫匯入資料非常有用。例如，您可以在 Amazon EMR 上執行 Apache Spark，並使用 JDBC 驅動程式連線到關聯式資料函式庫，以將資料載入資料湖（與我們討論使用 AWS Glue 連線資料函式庫的方式類別似）。或者，在 Amazon EMR 中，您可以佈署 Apache Sqoop，一個在關聯式資料函式庫系統和 Hadoop 之間傳輸資料的流行工具。

使用 RDS 功能匯出資料函式庫快照

如果您在 Amazon Relational Database Service（RDS）上執行 MariaDB、MySQL 或 PostgreSQL，您可以使用 RDS 的功能將資料函式庫快照匯出到 Amazon S3。這是一個完全託管的流程，將快照中的所有表格以 Apache Parquet 格式寫入 Amazon S3。如果您在 RDS 上使用支援的資料函式庫引擎，這是將資料移至 Amazon S3 的最簡單方法。

商業工具的應用

還有許多第三方商業工具，其中包含進階功能，可以用於將資料從關聯式資料函式庫移至 Amazon S3（雖然這些工具通常價格較高）。這包括 Qlik Replicate（以前稱為 Attunity）等工具，它是一種眾所周知的工具，用於在多種來源和目標之間行動資料（包括關聯式資料函式庫、資料倉儲、串流來源、企業應用程式、雲端供應商和舊式平台，如 DB2、RMS 等）。

資料函式庫引擎的匯出工具

您可能會發現您的資料函式庫引擎包含直接匯出資料到平面格式的工具，然後可以將這些資料傳輸到 Amazon S3。一些資料函式庫引擎還具有更進階的工具，例如 Oracle GoldenGate，一種可以產生變更資料擷取（CDC）資料作為 Kafka 串流的解決方案。然而，請注意，這些工具通常需要單獨授權，並可能增加顯著的額外費用。有關使用 Oracle GoldenGate 產生 CDC 資料並將其載入 S3 資料湖的範例，請搜尋 AWS 部落格文章《Extract Oracle OLTP data in real time with GoldenGate and query from Amazon Athena》。

變更資料擷取（CDC）提醒

我們在第三章《The AWS Data Engineer’s Toolkit》中介紹了 CDC 的概念，但這是一個重要的概念，因此在此提醒。當關聯式資料函式庫中的列被刪除或更新時，使用標準資料函式庫查詢工具（例如 SQL）無法捕捉這些變更。但是，當將資料從資料函式庫複製到新的來源時，識別這些變更非常重要，以便將它們應用到目標。這個識別和捕捉變更（新插入、更新和刪除）的過程被稱為 CDC。

決定從資料函式庫匯入的最佳方法

雖然所有這些工具都可以用於從資料函式庫匯入資料，但在決定特定使用案例的最佳方法時，有幾個需要考慮的要點。

資料函式庫大小

如果您要載入的資料函式庫表格總大小很大（數十 GB 或更大），那麼進行完整的夜間載入不是一個好方法。完整的載入可能需要大量的時間來執行，並且在執行期間對來源系統造成沉重的負擔。在這種情況下，更好的方法是從資料函式庫進行初始載入，然後使用 CDC 不斷同步來源的更新。

對於非常大的資料函式庫，您可以使用 AWS DMS 和 Amazon Snowball 裝置將資料載入您資料中心的 Snowball 裝置。一旦資料被載入，您將裝置退回給 AWS，他們將把它載入 Amazon S3。AWS DMS 將在 Snowball 裝置被傳回 AWS 期間捕捉所有 CDC 變更，以便一旦資料被載入，您就可以建立一個 ETL 任務來將變更應用到完整資料載入。

對於較小的資料函式庫，您不需要近乎實時地捕捉變更，可以考慮使用 AWS Glue（或原生資料函式庫工具）按照排程將整個資料函式庫載入 Amazon S3。這通常是最簡單和最具成本效益的方法，但並非適用於每種使用案例。

資料函式庫負載

如果您有一個始終保持一致生產負載的資料函式庫，您將希望最小化對伺服器造成的額外負載，以同步到資料湖。在這種情況下，您可以使用 DMS 進行初始完整載入，理想情況下是從您的資料函式庫的讀取副本（如果它被 DMS 支援作為來源）。對於持續複製，DMS 可以使用資料函式庫日誌檔案來識別 CDC 變更，這對資料函式庫資源造成的負載較小。

無論何時您從資料函式庫進行完整載入（無論您使用的是 AWS DMS、AWS Glue 還是其他解決方案），都需要對資料函式庫進行完整讀取，這將對資料函式庫造成較大的負載。您需要考慮這個負載，並盡可能使用您的資料函式庫的副本進行完整載入。

如果一個較小的資料函式庫正在 Amazon RDS 上執行，最好的解決方案是使用 RDS 的快照匯出到 S3 的功能，如果您的資料函式庫引擎支援的話。這個解決方案對您的來源資料函式庫不會造成任何負載。

資料擷取頻率與技術需求分析

在分析型專案中，資料擷取的頻率取決於具體的應用場景。有些分析任務適合固定排程的資料擷取，例如每晚更新資料；而有些任務則需要盡快取得最新資料。

資料函式庫來源的即時資料擷取

若您的分析任務需要即時或接近即時地存取來自資料函式庫來源的新資料，使用AWS DMS（Database Migration Service）等服務來擷取CDC（Change Data Capture）資料是一種理想的方法。CDC資料僅記錄了資料的變更（例如新增、更新或刪除行），因此仍需要一個處理程式將這些變更應用到現有資料中，以實作最新狀態的查詢。

對於允許定期排程更新的任務，例如每晚更新，可以進行排程的全量載入（如果資料函式庫的大小和效能允許），或執行每晚處理程式來應用當天收集的CDC資料到前一日的資料快照中。

在第7章「Transforming Data to Optimize for Analytics」中，我們將探討多種將CDC資料應用到現有資料集的方法。

技術需求與相容性評估

在評估不同工具和方法來從資料函式庫來源擷取資料時，必須事先讓資料函式庫擁有者和管理團隊參與進來，以技術角度評估所提出的解決方案。

資料工程團隊可能會根據其需求和對來源系統相容性的大致瞭解，事先決定特定的工具集。然而，在實施時，他們可能會發現來源資料函式庫團隊反對某些安全或技術要求，這可能導致專案的重大延誤。

例如，AWS DMS支援多個MySQL版本的CDC，但需要啟用二進位日誌並進行特定的組態設定。又如，AWS DMS不支援SQL Server 2008/2008 R2作為來源時的伺服器層級稽核，某些相關命令會導致DMS失敗。

在最終確定解決方案之前，取得資料函式庫擁有者和管理團隊的支援至關重要。所有這些需求和限制都在AWS DMS的檔案中有詳細說明（其他解決方案或產品也應有類別似的檔案說明其需求）。與管理團隊詳細檢視這些需求對於專案的成功至關重要。

玄貓 BlackCat

玄貓 BlackCat

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