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.

資料工作負載的成本優化，旨在確保儲存、運算和資料處理管道能在不造成失控支出的情況下交付價值。資料工程師必須在查詢效能、資料耐久性和可用性之間取得平衡，同時應對因服務和使用模式而異的定價模型。這個領域需要熟悉儲存類別與生命週期政策、查詢與叢集層級的控制、Spot 與預留容量，以及無伺服器（serverless）與預配置（provisioned）之間的權衡取捨。

S3 儲存成本優化

對於存取模式無法預測的資料集，建議預設使用 S3 Intelligent-Tiering：當物件存取頻率無法可靠預測時，可透過主控台或 AWS CLI 啟用 Intelligent-Tiering。設定 Intelligent-Tiering 時，需注意相關的監控/自動化費用（每個物件每月會有一筆小額的監控費用），並為自動分層轉換設定合適的最短天數（例如，從頻繁存取層轉到不頻繁存取層為 30 天）。使用物件標籤和生命週期規則來排除那些監控費用可能超過節省成本的小型、高請求量物件。

使用以下操作模式來降低 S3 支出：

• 在建立生命週期規則前，執行 S3 Storage Class Analysis（主控台 > Management > Analytics 或

undefined

）以識別前綴/標籤層級的存取模式。

• 使用生命週期轉換，將大型歷史資料集轉換為封存類別（Glacier Flexible Retrieval 或 Glacier Deep Archive）；設定生命週期轉換的時間以符合業務的 SLA，並避免頻繁使用 Expedited 擷取。
• 針對分析工作負載，將許多小物件（小檔案問題）整合成較大的物件（如 Parquet 容器檔案），以降低每個請求和每次 GET 的成本。

決策標準：

• 對於存取模式無法預測、中度存取且擷取時間具彈性的資料集，使用 Intelligent-Tiering。
• 對於不常存取但需要快速擷取且擷取模式可預測的資料，使用 Standard-IA 或 One Zone-IA。
• 對於長期保留、擷取次數稀少且可容忍數分鐘至數小時延遲的資料，使用 Glacier Standard/Bulk/Deep Archive；優先選擇 Bulk/Standard 擷取而非 Expedited，以避免高昂費用。

Athena 與 Redshift 成本管理

Athena 的成本與掃描的位元組數成正比。強制執行工作群組（workgroup）控制（主控台或

undefined

）以實作每個查詢的資料掃描量限制以及每個工作群組的每月預算；啟用「強制執行工作群組設定」，讓超過單次查詢資料量限制的查詢直接失敗而非繼續執行。透過將來源檔案轉換為欄式壓縮格式（Parquet/ORC）、依日期或常用篩選欄位進行分割（partitioning）、應用謂詞下推（predicate pushdown），以及使用 CTAS 或 CREATE TABLE AS 將優化後的資料集具體化，來減少掃描的位元組數。使用查詢結果重用，並將工作負載隔離到不同的工作群組中，以避免跨團隊的成本外溢。

Redshift 的成本決策取決於工作負載的可預測性與儲存選擇。對於穩定、可預測的資料倉儲運算用量，購買 Reserved Nodes（一年或三年期，可選部分/全部預付）以鎖定相對於隨需（on-demand）的折扣。對於變動的工作負載：

• 使用 Redshift Serverless 或帶有託管儲存的 RA3 節點，以解耦運算與儲存。
• 謹慎使用並行擴展（concurrency scaling）（它會產生額外費用但提供自動擴展），並監控其點數（credits）。

比較重點：

• Reserved Nodes：最適合穩定狀態、長期運行的叢集；需要承諾期，但能提供顯著折扣。
• On-demand：對無法預測或短期專案具彈性；每小時成本較高。
• Serverless/RA3 搭配 Spectrum：將儲存轉移到 S3，並在運算啟用時才付費，以避免大型的預留承諾。

Glue 與 EMR 成本策略

AWS Glue 提供無伺服器 ETL，並具備多種成本控制手段。對於不具延遲敏感性的批次任務，使用 Glue 彈性執行（Glue Flex jobs），與標準 Glue 執行相比，最多可降低約 34% 的成本。在 Glue Studio 或 CLI (

undefined

) 中設定 Glue 任務參數以選擇工作者類型（worker type）和最大 DPU 數量，設定合理的 DPU 上限以防止無限制的自動擴展，並使用任務書籤（job bookmarks）來避免完整的重新處理。對於互動式或延遲敏感的工作負載，選擇合適的工作者類型（Standard/G.1X/G.2X）並負責任地調整平行度。

EMR 的成本降低策略仰賴於為任務節點（task nodes）使用 Spot Instances，同時讓主節點（master）和核心節點（core nodes）保持為 On-Demand（在主控台或透過

undefined

設定執行個體叢集或執行個體群組）。僅對任務節點使用 Spot，選擇容量優化（capacity-optimized）的分配策略，若使用帶有競價的 Spot，則設定適當的出價/最高價格。透過以下方式保護叢集狀態和任務彈性：

• 當使用 Spot 任務節點時，將持久性資料儲存在 S3（使用 EMRFS）而非 HDFS。
• 使用自動重試和基於步驟（step-based）的工作流程來處理 Spot 中斷。
• 採用 EMR Managed Scaling 來適當調整叢集規模；監控擴展政策以避免規模震盪。

決策標準：

• 對於優先級低、對成本敏感且能容忍較長啟動時間的 ETL，使用 Glue Flex；並設定最大 DPU 上限。
• 對於大型的臨時性處理（例如，夜間批次處理），使用帶有 Spot 任務節點的 EMR，但將主節點/核心節點保持為 On-Demand，或使用具有混合分配策略的 Instance Fleets。

資料服務的預留容量與 Savings Plans

預留容量與 Savings Plans 在不同的資料服務中有不同的應用方式。對於以 EC2 為基礎的服務 (EMR、自行管理的 HBase、自訂的 Hadoop)，請使用 EC2 Savings Plans 或 Reserved Instances 來涵蓋運算支出；根據移動性需求選擇區域性或區域內的選項。Redshift 支援為已佈建的叢集購買預留節點，以降低可預測的資料倉儲工作負載的每小時成本。無伺服器服務 (Glue, Athena) 沒有資源預留機制；應改為透過工作負載排程和資料格式變更來進行優化。

實際採購指南：

• 為具有已知使用率的穩定狀態資料倉儲工作負載購買 Redshift Reserved Nodes (評估 1 年期與 3 年期，以及全額/部分/無預付選項)。
• 使用 EC2 Savings Plans 來涵蓋跨執行個體系列的 EMR/EC2 可預測支出；若執行個體系列或區域變更，Savings Plans 可提供彈性。
• 不要為無伺服器服務購買預留；應改為優化使用模式、排程和資料佈局。

常見陷阱與決策標準

• Athena 在沒有分割區的情況下會掃描整個資料表 — 務必依日期或其他高基數、經常篩選的欄位對大型時間序列資料表進行分割，並轉換為 Parquet/ORC 格式，以最小化掃描的位元組數。
• Glue DPU 自動擴展可能會過度佈建 — 在任務組態中 (透過主控台或 aws glue update-job) 設定 DPU 上限，並選擇適當的工作節點類型，以保持成本的可預測性。
• S3 Glacier 的擷取費用 — 除非是業務關鍵需求，否則避免使用 Expedited 擷取；規劃使用 Standard 或 Bulk 擷取，並設定具有實際 SLA 的生命週期轉換規則。
• EMR 的主節點和核心節點不應使用 Spot — 將主節點/核心節點設定為 On-Demand，並僅將 Spot 分配給已避免或已複寫 HDFS 狀態的任務節點。
• 大量的小型 S3 物件會增加請求成本並減慢分析速度 — 在擷取過程中將小檔案合併成較大的欄式檔案。
• 過度依賴並行擴展或無人管理的自動擴展會增加每小時費用 — 監控擴展指標、設定限制，並在工作負載可預測時使用預留容量。

實際問題：Acme Analytics 的夜間 ETL 成本降低方案

Acme Analytics 執行夜間 ETL 和每日的臨時分析；由於原始 S3 儲存量和 on-demand Redshift 時數不斷增長，每月雲端支出急劇上升。公司需要在不影響夜間 SLA 的情況下將成本降低 35%。

1. 執行 S3 Storage Class Analysis 並設定生命週期規則，將超過 90 天的冷原始檔案移至 Glacier Flexible Retrieval (規劃使用 Bulk/Standard 擷取)。
2. 將原始 CSV 轉換為已分割、壓縮的 Parquet 格式，並合併小檔案；將優化後的資料集儲存在 Athena/Redshift Spectrum 的獨立前綴下。
3. 建立具有每次查詢資料掃描量限制的 Athena 工作群組並強制執行工作群組設定；啟用查詢結果重複使用功能，並設定每個工作群組的每月預算。
4. 將批次 ETL 遷移至 Glue Flex 任務以處理非緊急的轉換，設定 DPU 上限，並將其安排在離峰時段執行；保留一個較小的標準 Glue 叢集以應對緊急任務。
5. 調整 Redshift 規模：為穩定的基線運算購買 1 年期 Reserved Nodes，將歷史資料移至 S3 並使用 Spectrum 進行不頻繁的查詢，並僅在有監控的情況下啟用並行擴展。

基本原理：此策略結合了資料格式與生命週期優化 (降低儲存和掃描成本)、用於彈性任務的無伺服器低成本執行方案 (Glue Flex)、查詢治理 (Athena 工作群組)，以及用於持續性運算的預留容量，以在保持可用性和效能的同時，最大化折扣效益。

← 數據管道監控與疑難排解 · 所有領域 · 數據品質、驗證與可觀察性 →

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

瀏覽 Amazon →