Amazon DEA-C01: 數據管道監控與疑難排解 — 學習指南
屬於 Amazon Data Engineer Associate DEA-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
資料管線的監控與故障排除對於確保串流與批次資料在 AWS 上能及時、準確地交付至關重要。此領域涵蓋了 Kinesis、Firehose、Glue、DMS、Lambda 等服務的遙測、警示和診斷技術，以及支援事件調查的 AWS 稽核軌跡。有效的監控能透過揭露消費者延遲、任務資源壓力、交付延遲和未經授權的存取，來降低平均偵測/復原時間 (MTTD/MTTR)。以下章節提供了具體的信號、CLI/主控台模式以及決策標準，以利操作和修復生產環境中的資料流。
適用於資料服務的 CloudWatch 指標與警示
CloudWatch 是主要的遙測平台：為關鍵服務指標建立指標篩選器、儀表板和警示，並將警示與 SNS、EventBridge 或 Systems Manager 整合以進行自動化修復。使用
undefined
以程式化方式建立警示；典型的旗標包括
undefined
、
undefined
、
undefined
(或
undefined
)、
undefined
、
undefined
和
undefined
。對於儀表板，可使用
undefined
推送自訂指標（例如，來自 Glue 任務中繼資料的指標），並指定一個命名空間，如 “MyCompany/DataPipeline”。
請專注於以下這些可採取行動的指標與模式：
- Glue：監控 BytesRead、BytesWritten、RecordsProcessed 和 DPUHrs，以偵測資料量變化、偏斜和成本。警示：RecordsProcessed 突然下降或每筆記錄的 DPUHrs 遽增。
- Kinesis：監控 GetRecords.IteratorAgeMilliseconds 以了解消費者延遲，以及監控 IncomingBytes/IncomingRecords 以了解來源壓力。
- Firehose：監控 DeliveryToS3.DataFreshness 和 DeliveryToS3.Records，以發現交付延遲和資料遺失。
- DMS：監控 FullLoadRows、CDCLatencyMilliseconds 和 AppliedChanges，以了解複寫健康狀況。
警示的決策標準：
- 使用複合警示 (CloudWatch composite alarms) 來減少雜訊：將 IteratorAgeMilliseconds > X 持續 3 個資料點 與 消費者錯誤率 > Y 結合起來。
- 對於閾值選擇，應從 7-14 天的歷史資料中推導出基準線，並在工作負載具有季節性時，使用異常偵測模型 (PutAnomalyDetector) 設定動態閾值。
Glue 任務監控與錯誤處理
Glue 會將指標發佈到 CloudWatch，並將日誌寫入
undefined
(任務執行日誌) 和
undefined
(錯誤日誌)。使用 CloudWatch Logs Insights 查詢任務執行情況：可透過主控台或
undefined
執行查詢，查詢字串範例如：
undefined
。追蹤來自 Glue 任務執行指標的 BytesRead、BytesWritten、RecordsProcessed 和 DPUHrs——DPUHrs 與成本和任務平行度直接相關。
常見的 Glue 失敗模式與修復方法：
- OutOfMemory (OOM) 或 Executor lost：增加 worker 類型/DPU 數量，對於記憶體需求較高的情況切換到 G.2X worker 類型，或優化 Spark 分區 (repartition/coalesce) 並使用下推述詞 (pushdown predicates) 來減少輸入量。
- 資料偏斜導致 stragglers (落後任務)：使用分區鍵重新平衡資料，增加平行度，或在適當時機使用 Glue DynamicFrame 的 split/resolve choices。
- 任務停滯或啟動時間過長：啟用任務書籤 (job bookmarks) 並監控 Glue JobMetrics 中的 “TimeWaitingForResources” 以識別容量競爭問題。
決策權衡：
- 當 CPU/記憶體是瓶頸且執行時間的可預測性很重要時，增加 DPU；若必須控制成本，則優先考慮程式碼優化（分區、僅在需要時進行快取）。
- 對於近乎即時的轉換，使用 Glue streaming；對於複雜的 Spark 轉換和較大的、適合 Spot 執行個體的工作負載，則使用 Glue ETL 批次處理。
Kinesis 與 Firehose 監控
Kinesis 消費者延遲 (Consumer Lag)：依靠 GetRecords.IteratorAgeMilliseconds 來偵測消費者落後了多少。如果 GetRecords.IteratorAgeMilliseconds 持續偏高：
- 透過增加分片數量 (reshard/scale) 來擴展，或
- 透過批次處理、使用增強型扇出 (enhanced fan-out)（為每個消費者提供高達 2 MB/秒的吞吐量）或使用具有改進檢查點功能的 Kinesis Client Library (KCL) v2 來提升消費者效能。
使用
undefined
檢查分片數量，並使用
undefined
取得 IteratorAgeMilliseconds。在比較修復選項時，請考量：
- 增加分片：提高寫入和讀取吞吐量；但需要重新分片和重新平衡。
- 增強型扇出：避免共享讀取吞吐量，但會增加每個消費者的成本。
- 消費者優化：減少對額外分片的需求和成本，但需要投入工程心力。
Firehose 交付指標：DeliveryToS3.DataFreshness 量化了交付延遲；典型的
undefined
設定為 60–900 秒，並且會一直保留記錄，直到
undefined
或
undefined
其中一個條件被滿足。如果 DeliveryToS3.DataFreshness 偏高：
- 在主控台或透過
undefined
檢查 Firehose 的緩衝提示 (BufferIntervalInSeconds, BufferSizeInMBs)。
- 檢查 CloudWatch Errors (DeliveryToS3.RecordsFailed) 和 S3 儲存貯體的權限（如果已加密，則檢查 KMS 錯誤）。
請記住 Firehose 的緩衝語意：該服務會刻意延遲，最長可達緩衝區間；縮短緩衝區間可以降低延遲，但代價是更頻繁地寫入 S3。
CloudTrail 與資料存取稽核
CloudTrail 提供 API 活動記錄，並可選擇性地記錄 S3 和 Lambda 的資料事件，但這些預設並未啟用。若要擷取物件層級的 S3 事件，需透過主控台或
undefined
指令在 CloudTrail 上明確啟用資料事件，並新增 S3 資料資源。若未啟用 S3 資料事件，您將無法在 CloudTrail 中看到 GetObject/PutObject 事件，這是調查過程中常見的疏漏。
結合使用 CloudTrail 日誌與 CloudWatch Logs Insights，可將營運指標（例如 Glue 任務日誌）與存取事件建立關聯。查詢模式：
- CloudWatch Logs Insights:
undefined
- 使用 EventBridge 規則對特定的 API 呼叫（例如 PutBucketAcl）做出反應，並將其轉發到 SNS 以進行快速警示。
DMS 複寫任務也會發布 CloudWatch 指標：監控 FullLoadRows 以確認初始複製的完整性、CDCLatencyMilliseconds 以偵測複寫延遲，以及 AppliedChanges 以確保交易正在目標端套用。應針對 CDCLatencyMilliseconds 超過業務 SLA 的情況，以及在 full load rows 增加後 AppliedChanges 數值過低的情況設定警報。
常見陷阱與決策標準
- 將 Kinesis 的 High IteratorAgeMilliseconds 誤認為是來源端的問題 — 正確的方法：檢查消費者的檢查點（checkpointing）與處理時間；只有在分析完消費者的 CPU/IO 後，才透過增加 shard 或使用增強型扇出（enhanced fan-out）來擴展。
- 盲目增加 DPU 來處理 Glue 任務的 OOM 錯誤 — 正確的方法：分析 Spark 的各個階段（stage），優化分區（partitioning）與資料篩選；只有在確認資源達到極限時，才增加 DPU 或更換 worker 類型。
- Firehose 的緩衝延遲造成感覺上的資料遺失 — 正確的方法：驗證 BufferIntervalInSeconds 和 BufferSizeInMBs；為滿足低延遲需求而縮短間隔，並接受較高的寫入速率/成本。
- 假設 CloudTrail 預設會記錄 S3 物件讀取 — 正確的方法：在 CloudTrail 中啟用 S3 資料事件，以擷取 GetObject/PutObject 事件，用於鑑識稽核。
- 遺漏 DMS CDC 延遲警報 — 正確的方法：針對 CDCLatencyMilliseconds 建立 CloudWatch 警報，並比較 AppliedChanges 與 FullLoadRows；當延遲增加時，調查網路或交易積壓問題。
- 對暫時性的突波過度告警 — 正確的方法：使用評估期間（evaluation-periods）、觸發警報的資料點（datapoint-to-alarm）或異常偵測來減少雜訊，並針對相關聯的條件使用複合警報（composite alarms）。
實務問題：使用案例情境
Acme Analytics 公司透過 Kinesis 進行即時點擊流（clickstream）擷取，使用 Glue ETL 任務來豐富化事件，透過 Firehose 將過期的批次資料存留至 S3，並用 DMS 複寫舊有的資料庫。他們觀察到端到端的延遲：Kinesis 的消費者延遲、Glue 任務發生 OOM，以及 Firehose 顯示較大的 DeliveryToS3.DataFreshness。
- 分析 Kinesis 消費者：提取 GetRecords.IteratorAgeMilliseconds 指標，檢查消費者日誌，並進行 Kinesis 增強型扇出（enhanced fan-out）與擴展 shard 的成本分析。
- 檢查 Glue 任務的 CloudWatch 指標和 Logs Insights 中的 OOM 堆疊追蹤；在本地或較小的任務中測試重新分區（repartitioning）+ 下推述詞（pushdown predicate）；僅在必要時才增加 DPU/worker 類型。
- 檢查 Firehose 的緩衝區設定（BufferIntervalInSeconds）和 DeliveryToS3.DataFreshness；為滿足關鍵的 SLO 而縮短緩衝間隔，並驗證 S3 寫入權限/KMS。
- 設定 CloudWatch 複合警報，結合 IteratorAgeMilliseconds、Glue 任務錯誤率和 Firehose DataFreshness；將警示傳送到一個值班用的 SNS 主題，並透過 EventBridge 觸發一個 runbook。
- 啟用 CloudTrail S3 資料事件，並將 GetObject/PutObject 事件與 Glue 任務的啟動時間及 DMS 的 applied changes 建立關聯，以偵測未經授權或延遲的存取。
此方法遵循 AWS 的最佳實踐：以正確的粒度監控正確的服務指標，在擴展資源之前，優先進行針對性的程式碼和組態修正，並確保明確啟用稽核等級的日誌記錄，以實現快速的根本原因分析和自動化修復。
← 數據安全、治理與合規 · 所有領域 · 數據工作負載的成本優化 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →