Amazon DEA-C01: 數據轉換與處理 — 學習指南

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

屬於 Amazon Data Engineer Associate DEA-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

此領域涵蓋用於大規模清理、轉換和準備資料以進行分析和機器學習的 AWS 服務與模式。其重點是根據資料量、延遲要求和成本限制，選擇正確的運算資源和工具 (Glue、Lambda、EMR、DataBrew)。要建立可靠的增量管線，了解服務限制、任務組態的可調參數，以及資料格式和目錄如何互動至關重要。

AWS Glue ETL 任務 (Spark 和 Python shell)

Glue Spark 任務是進行大規模、分散式 ETL 的首選：它們在 AWS Glue 管理的 Apache Spark 上執行，使用 GlueContext，並操作 DynamicFrame 和 Spark DataFrame 類型。可透過主控台或 CLI 進行設定，指定任務類型為 “glueetl”、workerType (G.1X、G.2X、G.4X) 和 NumberOfWorkers；使用 CLI 啟動：aws glue start-job-run –job-name my-spark-job –arguments ‘–execution-class=STANDARD’。當您需要彈性結構描述的轉換、內建轉換 (Relationalize、Unnest) 以及自動處理半結構化資料時，請使用 DynamicFrame API (create_dynamic_frame.from_options、apply_mapping)；當您需要 Spark SQL、更高性能的 join 操作或自訂 UDF 時，請使用 dyf.toDF() 將其轉換為 Spark DataFrame。

Glue Python shell 任務使用 “pythonshell” 任務類型，適用於輕量級腳本和控制平面任務。它們是單一 DPU (1 DPU)，平行處理能力有限，最適合用於小型檔案操作、中繼資料更新或流程協調。可透過 aws glue create-job –name my-pyjob –command ‘{“Name”:“pythonshell”,“PythonVersion”:“3”}’ 進行設定，並使用 aws glue start-job-run 啟動。請注意，Python shell 任務有 1 DPU 的限制——處理大型資料集時應使用 Spark。

Glue 任務書籤 (job bookmarks) 透過追蹤先前已處理的 S3 物件和分割區來實現增量處理。在任務組態中或啟動任務時啟用書籤：aws glue start-job-run –job-name my-job –job-bookmark-option job-bookmark-enable。書籤適用於使用內建連接器的 S3 來源；JDBC 來源預設不支援書籤，需要自訂浮水印 (watermarking) 或狀態儲存。

Glue 現在支援 ExecutionClass FLEX，適用於成本最佳化、非緊急的任務。使用 aws glue start-job-run –job-name my-job –execution-class FLEX 啟動，以允許 Glue 在較寬鬆的啟動時間 SLA 下，以較低成本排程任務。將 FLEX 用於批次資料回填和對延遲不敏感的工作負載；對於需要可預測延遲的場景，則使用 STANDARD。

決策標準 — 快速比較：

• DynamicFrame vs Spark DataFrame

  • 當擷取有結構描述漂移 (schema drift) 的半結構化 JSON/Parquet、利用 apply_mapping、relationalize 和 glue 轉換時，請使用 DynamicFrame。
  • 當您需要 Spark SQL 的效能、複雜的 join、視窗函數 (window functions) 和第三方 Spark 函式庫時，請使用 Spark DataFrame。
  • 透過 DynamicFrame.fromDF(df, glueContext, “name”) 和 dyf.toDF() 在兩者之間進行轉換。

• Glue Spark vs Python shell

  • 對於大型資料集上的多節點、分散式 ETL，以及大規模使用 Glue Catalog 整合時，請選擇 Spark。
  • 對於可在 1 DPU 內完成的小型、快速任務或流程協調步驟，請選擇 Python shell。

使用 AWS Lambda 進行輕量級轉換

Lambda 非常適合由 S3、Kinesis 或 EventBridge 直接觸發的事件驅動、低延遲、輕量級的轉換。典型用途包括檔案驗證、中繼資料提取、小檔案的 JSON 轉 CSV，或記錄的串流處理。使用 aws lambda update-function-configuration –function-name myFunc –memory-size 2048 –timeout 300 來設定記憶體和逾時時間。對於延遲敏感的串流管線，可以使用 aws lambda put-provisioned-concurrency-config 設定預置並行 (Provisioned Concurrency) 以緩解冷啟動問題。

請注意 Lambda 在資料處理方面的限制：最長執行時間 15 分鐘、記憶體 10 GB (10,240 MB)，以及只有 512 MB 的暫時性 /tmp 儲存空間。對於較大的檔案處理，可採用鏈式處理 (分割檔案)、將檔案暫存到 S3 並調用 Glue 或 EMR 任務，或使用 AWS Step Functions 進行多部分處理。使用環境變數來儲存小型組態，並使用嚴格授予最小權限的 IAM 角色政策。

決策標準 — 何時選擇 Lambda：

• 當每次調用的處理都符合 15 分鐘、10 GB 記憶體和 512 MB /tmp 的限制，且需要亞秒級到秒級的延遲時，請使用 Lambda。
• 避免使用 Lambda 進行大型、長時間執行或重度記憶體密集型的轉換；應改用 Glue Spark 或 EMR。

Amazon EMR 用於大規模處理

EMR 是處理可自訂、大規模大數據（Spark、Hadoop、Presto、Flink）的首選，特別是在需要叢集層級控制、自訂引導操作或特殊函式庫的場景。可透過 CLI 使用 aws emr create-cluster 建立叢集，並選擇 --instance-groups 或 --instance-fleets。Instance fleets 提供彈性的執行個體類型組合以及 Spot/On-Demand 組合；instance groups 則較為簡單，是固定大小的群組。

可考慮的 EMR 叢集模式：

• 暫時性叢集：以 --auto-terminate 啟動並提交步驟，讓叢集在步驟完成後終止。這有助於成本控制，但短暫的 HDFS 和本地狀態會在終止時遺失。
• 長時間運行的叢集：不自動終止；用於互動式工作負載、持久性 HDFS，或當許多小型任務能從 JVM 預熱中受益時。如果預期叢集會終止，應將關鍵資料持久化到 S3 或由 EBS 支援的 Hadoop 儲存中。

設定範例：

• Instance group CLI：

undefined

• Instance fleet CLI 使用 --instance-fleets，搭配 OnDemand/Spot 分配和多種執行個體類型，以實現彈性和成本最佳化。

當您需要對 Hadoop 生態系元件的完全控制、自訂 bootstrap 指令碼或用於中繼資料的持久性 HDFS 時，請使用 EMR；否則，對於與 Glue Data Catalog 整合的託管式 Spark ETL，Glue Spark 是更簡單的選擇。

Glue DataBrew 與視覺化轉換

Glue DataBrew 是一個視覺化、無程式碼/低程式碼的工具，專為資料分析師和工程師進行互動式工作而設計，用於資料剖析、清理和轉換。您可以從 S3 或 Glue Catalog 建立資料集，在主控台中建立一個轉換配方 (recipe)，在樣本上預覽，然後執行任務以大規模套用配方。可以排程 DataBrew 任務，或透過 CLI 使用 aws databrew start-job-run --name my-databrew-job 來執行。

DataBrew 專為資料準備任務進行了最佳化，例如標準化、重複資料刪除、類型轉換以及使用內建函數進行的欄位層級轉換。它與 Glue Catalog 整合，並將輸出寫入 S3。當業務使用者需要自助式清理和快速剖析時，請選擇 DataBrew；對於繁重的轉換邏輯、複雜的 join 或非常大的資料集，則偏好使用 Glue Spark 或 EMR。

視覺化與程式碼型轉換的比較：

• Glue DataBrew
  • 優點：快速剖析、基於配方 (recipe-based)、非開發人員也能建立管線、整合排程。
  • 缺點：不適用於非常大型或高度複雜的分散式 join 和自訂函式庫。
• Glue Spark / EMR
  • 優點：完全的程式化控制、能處理巨量資料集、支援第三方函式庫。
  • 缺點：需要開發人員技能和更多設定。

常見陷阱與決策標準

• 假設 Glue job bookmarks 對 JDBC 來源有效 — bookmarks 僅追蹤 S3 物件/分割區的狀態；對於 JDBC 增量載入，請使用水位標記欄位 (watermark columns)、異動資料擷取 (change-data-capture)，或將進度儲存在 DynamoDB/S3 中。
• 將暫時性 EMR 叢集視為有狀態的系統 — 暫時性叢集在步驟完成後會終止並遺失 HDFS；請將中繼資料持久化到 S3 或使用 EBS 磁碟區進行持久儲存。
• 在串流管線中忽略 Lambda 的冷啟動 — 冷啟動會增加延遲；可透過為關鍵路徑設定 provisioned concurrency 來緩解，或對嚴格的低延遲需求使用長時間運行的運算資源。
• 在 Glue Python shell 中執行大型轉換 — Python shell 任務限制為 1 個 DPU；對於大型資料集，請使用具有適當 workerType/NumberOfWorkers 的 Glue Spark 任務。
• 錯誤設定 EMR 執行個體類型：選擇 instance fleets 以利用 spot instances 獲得成本效益和彈性；當您需要可預測的執行個體組成時，請使用 instance groups。
• 對於緊急的工作負載過度使用 Glue Flex — FLEX 可降低成本，但可能延遲啟動時間；對於可預測的啟動和執行時間，請使用 STANDARD。

實務問題：使用案例情境

AcmeRetail 公司每晚處理點擊流 Parquet 檔案，將其整合成一個統一的客戶活動表，並希望進行增量處理以避免重新處理數個月的資料，同時為非緊急的回填作業保持低成本。

1. 使用 S3 分割區佈局 (例如 year=/month=/day=) 並在 Glue Data Catalog 中註冊資料集。
2. 建立一個 Glue Spark 任務 (glueetl)，它會讀取 DynamicFrame.from_catalog 以獲得結構彈性，套用對應，轉換為 DataFrame 以進行複雜的 join，然後將分割區化的 Parquet 寫回 S3。
3. 為夜間執行啟用 Glue job bookmarks (job-bookmark-enable) 以僅處理新的分割區；對於 JDBC 擴充資料來源，實作持久化在 DynamoDB 中的水位標記欄位 (watermark columns)，以追蹤已處理的最大時間戳。
4. 對於例行的夜間執行，使用 ExecutionClass=STANDARD；對於非緊急的歷史資料重新處理，提交執行時使用 --execution-class FLEX 以節省成本。
5. 使用 CloudWatch 指標進行監控，並為任務失敗設定警報；對於非常大的規模或需要自訂函式庫的情況，可考慮使用 EMR 暫時性叢集，將中繼結果寫入 S3 並自動終止。

基本原理：此方法利用 Glue 的託管式 Spark 進行可擴展的轉換，並使用 DynamicFrames 處理半結構化輸入，使用 job bookmarks 進行 S3 增量處理，並使用 FLEX 降低回填成本——在成本、可靠性和操作簡易性之間取得平衡。

← 數據編目與中繼資料管理 · 所有領域 · 數據編排與工作流程管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →