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.

協同運作與工作流程管理是建立可靠、可維護資料平台的中心要素：它們協調 ETL (extract-transform-load) 任務、管理相依性、處理故障，並整合事件驅動的流程。這個領域涵蓋了 AWS 為批次 ETL、複雜 DAG、無伺服器狀態機和事件排程所提供的受管選項——每種選項都有不同的執行語意、持久性與擴展性的權衡取捨。了解何時該使用 AWS Glue Workflows、MWAA、Step Functions 或 EventBridge Scheduler——以及如何設定錯誤處理與可觀測性——對於建立可預測的管線與控制營運成本至關重要。

AWS Glue Workflows 與觸發器

AWS Glue Workflows 將 Glue 任務、crawlers 和觸發器組合成一個相依性圖表，讓您能夠執行協調的 ETL。您可以透過主控台或 CLI (

undefined

) 建立工作流程。觸發器附加於工作流程，並有三種類型：排程 (scheduled)、隨需 (on-demand) 和條件式 (conditional)。排程觸發器的 CLI 建立範例如下：

undefined

條件式觸發器使用一個參照任務名稱和狀態 (SUCCEEDED, FAILED) 的 Predicate。Predicate JSON 範例：

undefined

。預設情況下，Glue 條件式觸發器會在成功時觸發；若要處理失敗，可設定 State=FAILED 的條件，或建立一個明確的 FAILED 觸發器，將錯誤路由到修復任務或 SNS 警示。

營運模式與決策標準：

• 當您需要原生的 Glue 任務/crawler 協同運作與資料血緣時，請使用 Glue Workflows；選擇觸發器來進行 cron 排程或在任務完成時串連任務。
• 對於臨時性的調用，請使用

undefined

或針對隨需觸發器使用 start-trigger。

• 對於複雜的分支或非 Glue 的任務，建議優先使用 Step Functions 或 MWAA；當管線以 Glue 為核心時，Glue workflows 是最佳選擇。

錯誤處理：新增 FAILED 觸發器、為任務成功/失敗發送 CloudWatch 指標，並透過 Lambda 將失敗推送到 SQS/SNS 的無效字母佇列 (dead-letter queue)，以進行自動重試和調查。

用於複雜 DAG 的 Amazon MWAA (Managed Airflow)

MWAA 提供一個受管的 Apache Airflow 環境，用以表達複雜的 DAG、任務相依性、感測器 (sensors) 和自訂運算子 (operators)。使用

undefined

建立環境，並提供一個 DAG 的 S3 路徑和執行角色。重要的規模調整與網路細節：

• MWAA 需要一個包含私有子網路和用於網際網路存取的 NAT gateway 的 VPC；不支援僅有公有子網路的設定。
• Worker 和 scheduler 的行為是透過在建立環境時提供的 Airflow 組態選項 (AirflowConfigurationOptions) 來控制的。調整 celery.worker_concurrency、celery.worker_autoscale 和 scheduler 設定，以符合任務的並行性與 DAG 的複雜度。
• 監控 CloudWatch 指標 (SchedulerHeartbeat, TasksFailed, TasksRunning, QueuedTasks)，並在觀察到佇列增長時，擴展 worker 的自動擴展規模或增加 max workers。

決策標準：

• 當您需要 Airflow 的功能時，請使用 MWAA：複雜的 DAG、豐富的運算子、跨 DAG 的相依性、SLA/錯失任務的感測器，以及自訂的 Python 邏輯。
• 如果任務是短暫且極高吞吐量的，建議優先使用無伺服器的 Step Functions Express 或 Glue 來進行受管的 ETL 操作。
• 將繁重、長時間執行的任務保留在受管的運算服務中 (Glue/EMR/EKS)，並僅將 MWAA 任務用作協同運作——避免在 MWAA worker 本身執行大規模的資料轉換。

Airflow 中的錯誤處理：在 DAG 定義中使用任務重試 (task retries) 和 retry_delay，設定 on_failure_callback 以進行通知或推送到 SQS 無效字母佇列，並設定任務層級的 SLA 處理來觸發修復用的 DAG。

用於無伺服器協同運作的 AWS Step Functions

Step Functions 使用基於 JSON 的 Amazon States Language 提供有狀態的協同運作，並廣泛整合 AWS 服務。可在 Standard 和 Express 工作流程之間選擇：

• Standard Workflows：專為長時間執行、持久的狀態機（可達數月至數年）而設計，具有「僅執行一次」(exactly-once) 的執行語意、內建的執行歷史記錄，以及每次執行的追蹤/日誌記錄。使用

undefined

啟動。

• Express Workflows：針對高吞吐量、低延遲、短時間的處理進行了優化，並在規模化時具有成本效益；它們使用「至少執行一次」(at-least-once) 的執行語意，因此任務必須是冪等的 (idempotent) 或使用去重複的模式。

使用案例與決策標準：

• 當您需要持久、可稽核，且可能長時間執行並要求「僅執行一次」語意的工作流程時，請使用 Standard。
• 對於每秒有數千次執行的事件驅動微協同運作，其中短時間和成本效益很重要，並且您可以設計冪等任務或在下游進行去重複，請使用 Express。

錯誤處理與整合模式：

• 在 ASL 中使用 Retry 區塊，透過 ErrorEquals、IntervalSeconds、BackoffRate 和 MaxAttempts 來定義重試。
• 使用 Catch 區塊將失敗重導至替代分支或 Fail/Success 狀態，並將錯誤詳細資訊填入 ResultPath 以供診斷。
• 對於非同步的無效信件處理，可將失敗的訊息推送到 SQS/SNS，或設計一個 Step Functions 模式，將錯誤的 payload 傳送到 SQS DLQ 以進行離線處理。透過 LoggingConfiguration 和 TracingConfiguration 啟用 CloudWatch Logs 和 X-Ray 追蹤，以實現可觀測性。

EventBridge Scheduler 與事件驅動的管線

EventBridge 提供豐富的事件路由功能以及一個用於 cron 和一次性任務的 Scheduler 功能。使用 aws events put-rule --name dailyRule --schedule-expression "cron(0 2 * * ? *)" 來建立基於排程的規則，並透過 aws events put-targets 附加目標。對於事件驅動（模式）的路由，使用 put-rule 搭配 --event-pattern '{"source":["aws.s3"],"detail-type":["Object Created"]}' 將 S3 事件路由到 Lambda、Step Functions 或 SQS。

關鍵操作要點：

• EventBridge 支援排程表達式（cron 和 rate）。當使用 rate 表達式時，請注意 EventBridge 規則有 5 分鐘的最小間隔限制；若需更精細的粒度，請考慮使用 Step Functions 或輪詢層。
• 使用 EventBridge Scheduler 處理一次性、臨時的未來調用和週期性排程；Scheduler 支援時區和針對每個目標的彈性重試設定，並可為無法交付的調用設定一個死信 SQS 佇列。
• 對於高可靠性的管線，附加如 Step Functions、Lambda 或 SQS 等目標，並設定針對每個目標的重試政策和 DLQ。例如，put-targets 接受一個 DeadLetterConfig，其中包含 SQS 佇列的 Arn。

錯誤處理：設定針對特定目標的重試次數和退避策略，使用 DLQ 處理失敗的交付，並將 EventBridge 與 Step Functions 結合以處理複雜的錯誤處理和補償性交易。

常見陷阱與決策標準

• 錯誤：對非冪等性任務使用 Express Workflows。正確方法：設計冪等性（例如使用去重鍵、冪等的 Lambda），或使用 Standard workflows 以達到僅執行一次的語意。
• 錯誤：假設 Glue 的條件觸發器會在失敗時觸發。正確方法：明確地建立 FAILED 觸發器，或在觸發器的 Predicate 中包含 State=FAILED 來路由錯誤。
• 錯誤：將 MWAA 部署在公有子網路中或未使用 NAT。正確方法：將 MWAA 放置在私有子網路中，並提供 NAT 閘道器或 VPC 端點以取得所需的服務存取權限。
• 錯誤：期望 EventBridge 能有分鐘級以下的排程。正確方法：記住 EventBridge 規則有 5 分鐘的最小間隔；對於 5 分鐘以下的需求，請使用 Step Functions 或 Lambda 計時器。
• 錯誤：跨服務間沒有集中式的重試/捕捉策略。正確方法：標準化重試/退避策略（ASL 的 Retry、EventBridge 的重試設定、Airflow 的 retries），並使用 DLQ 來保存失敗的事件，以供手動/自動修復。
• 錯誤：用繁重的資料處理使 MWAA worker 過載。正確方法：只在 MWAA 上進行協作，在 Glue/EMR/EKS 上運行繁重的轉換，並在任務之間傳遞指標（S3 路徑）。

實務問題：Acme Retail 的每小時 ETL 與流量尖峰

Acme Retail 需要一個每小時運行的 ETL，該 ETL 會執行 Glue 任務進行原始資料擷取、一個帶有 Python 運算子的複雜資料擴充 DAG，以及一個必須回應高頻率庫存事件的短期 SKU 彙總。他們要求強健的重試和失敗捕獲機制。

1. 使用 EventBridge 觸發一個每小時的排程規則，該規則會調用一個 Step Functions Standard workflow 來協調整個管線。
2. 在 Step Functions 中，使用 Retry 和 Catch 處理器來協作長時間運行的 Glue 任務（StartJobRun）；若發生失敗，則透過一個 Catch 區塊將其路由到一個 SQS DLQ 和一個用於修復的 Lambda。
3. 將複雜的資料擴充 DAG 部署在 MWAA 中，並從 Step Functions 使用 Airflow REST API 或將 DAG 運行訊息放置到 SQS 來調用它們；根據預期的並行性，透過 celery.worker_autoscale 設定來調整 MWAA worker 的大小，並監控 CloudWatch 指標以進行調整。
4. 對於高頻率的庫存事件，使用 EventBridge 的事件模式規則將事件推送到一個 Express Step Function 或帶有冪等性金鑰的 Lambda，並使用一個由 SQS 支援的 DLQ 來吸收突發流量。
5. 實作集中式監控（CloudWatch Logs/Metrics、用於 Step Functions 的 X-Ray），並針對 DLQ 增長和任務重試耗盡設定警報。

基本原理：這個設計為每個需求使用了正確的工具——Step Functions 用於持久的跨服務協作和錯誤處理，MWAA 用於複雜的 DAG 邏輯，Glue 用於受管的 ETL，而 EventBridge 用於排程和反應式事件。它強制執行冪等性和 DLQ，以建立具備彈性、可觀測性的管線，並符合 AWS 的最佳實踐。

← 數據轉換與處理 · 所有領域 · 數據查詢與分析 →

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

瀏覽 Amazon →