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 和预留容量，以及无服务器与预置模式之间的权衡。

S3 存储成本优化

对于访问模式不可预测的数据集，S3 Intelligent-Tiering 是推荐的默认选项：当无法可靠预测对象访问频率时，通过控制台或 AWS CLI 启用 Intelligent-Tiering。配置 Intelligent-Tiering 时，需注意其相应的监控/自动化费用（每个对象每月有少量监控费用），并为自动分层转换设置合适的最小天数（对于从频繁访问层到非频繁访问层为 30 天）。使用对象标签和生命周期规则来排除那些监控费用会超过节省成本的小型、高请求对象。

使用以下操作模式来减少 S3 开销：

在创建生命周期规则之前，运行 S3 存储类别分析（控制台 > 管理 > 分析或

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 的成本与扫描的字节数成正比。强制执行工作组控制（控制台或

undefined

）以实施单次查询的数据扫描量限制和每个工作组的月度预算；启用“强制执行工作组设置”，使超出单次查询数据限制的查询失败而不是继续运行。通过将源文件转换为列式压缩格式（Parquet/ORC）、按日期或常用筛选列进行分区、应用谓词下推以及使用 CTAS 或 CREATE TABLE AS 来物化优化的数据集，从而减少扫描的字节数。使用查询结果重用和将工作负载隔离到不同的工作组中，以避免跨团队的成本泄露。

Redshift 的成本决策取决于工作负载的可预测性和存储选择。对于稳定、可预测的数据仓库计算使用量，购买预留节点（一年或三年期，部分/全额预付选项）以锁定相比按需付费的折扣。对于可变的工作负载：

使用 Redshift Serverless 或带有托管存储的 RA3 节点，以解耦计算与存储。
谨慎使用并发扩展（它会产生额外费用但提供自动扩展），并监控其积分。

比较要点：

预留节点：最适合稳定、长期的集群；需要承诺但能获得显著折扣。
按需：对于不可预测或短期项目很灵活；每小时成本较高。
Serverless/RA3 with Spectrum：将存储转移到 S3，并在计算活跃时付费，以避免大量的预留承诺。

Glue 和 EMR 成本策略

AWS Glue 提供具有多种成本控制手段的无服务器 ETL。对于非延迟敏感的批处理作业，使用 Glue 灵活执行（Glue Flex 作业），与标准 Glue 执行相比，可降低高达约 34% 的成本。在 Glue Studio 或 CLI (

undefined

) 中配置 Glue 作业参数，以选择工作器类型和最大 DPU，设置一个合理的 DPU 上限以防止无限制的自动扩展，并使用作业书签以避免完全重新处理。对于交互式或延迟敏感的工作负载，选择合适的工作器类型（Standard/G.1X/G.2X）并负责任地调整并行度。

EMR 的成本降低依赖于为任务节点使用 Spot 实例，同时保持主节点和核心节点为按需模式（在控制台或通过

undefined

配置实例舰队或实例组）。仅为任务节点使用 Spot，选择容量优化分配策略，如果使用带竞价的 Spot，则设置适当的出价/最高价格。通过以下方式保护集群状态和作业弹性：

当使用 Spot 任务节点时，将持久性数据存储在 S3（使用 EMRFS）而不是 HDFS 中。
使用自动重试和基于步骤的工作流来处理 Spot 中断。
使用 EMR Managed Scaling 来合理调整集群规模；监控扩展策略以避免振荡。

决策标准：

对于低优先级、对成本敏感且能容忍较长启动时间的 ETL，使用 Glue Flex；并设置最大 DPU 上限。
对于大规模的瞬时处理（例如，夜间批处理），使用带有 Spot 任务节点的 EMR，但保持主/核心节点为按需模式，或使用混合分配的实例舰队。

数据服务的预留容量和 Savings Plans

预留容量和 Savings Plans 在不同数据服务中的应用方式有所不同。对于由 EC2 支持的服务（EMR、自管理的 HBase、自定义 Hadoop），使用 EC2 Savings Plans 或预留实例来覆盖计算开销；根据移动性需求选择区域性或可用区级选项。Redshift 支持为预置集群购买预留节点，以降低可预测的数据仓库工作负载的小时成本。无服务器服务（Glue、Athena）没有资源预留；应通过工作负载调度和数据格式变更来进行优化。

实用购买指南：

对于使用率已知的稳态数据仓库工作负载，购买 Redshift 预留节点（评估1年期与3年期，以及全预付/部分预付/无预付选项）。
使用 EC2 Savings Plans 覆盖跨实例族的、可预测的 EMR/EC2 开销；如果实例族或区域发生变化，Savings Plans 能提供灵活性。
不要为无服务器服务购买预留；相反，应优化使用模式、调度和数据布局。

常见陷阱与决策标准

Athena 在没有分区的情况下扫描整个表 — 对于大型时间序列数据表，务必按日期或其他高基数、频繁筛选的列进行分区，并转换为 Parquet/ORC 格式，以最小化扫描的字节数。
Glue DPU 自动扩展可能导致过度预置 — 在作业配置中（通过控制台或

undefined

）设置 DPU 上限，并选择合适的工作器类型，以保持成本可预测。

S3 Glacier 检索费用 — 除非业务关键，否则避免使用加急检索；规划使用标准或批量检索，并根据切合实际的 SLA 设置生命周期转换。
EMR 主节点和核心节点不应使用 Spot — 将主节点/核心节点配置为按需实例，仅将 Spot 分配给那些已避免或复制了 HDFS 状态的任务节点。
大量 S3 小对象会增加请求成本并减慢分析速度 — 在摄取过程中将小文件合并为更大的列式文件。
过度依赖并发扩展或无托管的自动扩展会增加小时费用 — 监控扩展指标，设置限制，并在工作负载可预测时使用预留容量。

实践问题：Acme Analytics 夜间 ETL 成本削减

Acme Analytics 运行夜间 ETL 和日常的即席分析；由于原始 S3 存储和按需 Redshift 小时数的增长，其月度云支出飙升。该公司需要在不影响夜间 SLA 的前提下削减 35% 的成本。

运行 S3 存储类分析并设置生命周期规则，将超过90天的冷原始文件移动到 Glacier Flexible Retrieval（并规划批量/标准检索）。
将原始 CSV 转换为分区、压缩的 Parquet 格式，并合并小文件；将优化后的数据集存储在不同的前缀下，供 Athena/Redshift Spectrum 使用。
创建带有每次查询数据扫描量限制的 Athena 工作组，并强制执行工作组设置；启用查询结果重用，并为每个工作组设置月度预算。
将批量 ETL 迁移到 Glue Flex 作业以处理非紧急的转换任务，设置 DPU 上限，并在非高峰时段调度它们；为紧急作业保留一个较小的标准 Glue 集群。
对 Redshift 进行规模优化：为稳定的基线计算购买1年期预留节点，将历史数据移至 S3 并使用 Spectrum 进行不频繁的查询，并且仅在有监控的情况下启用并发扩展。

基本原理：该策略结合了数据格式和生命周期优化（降低存储和扫描成本）、为灵活作业采用无服务器的低成本执行方式（Glue Flex）、查询治理（Athena 工作组），以及为持续计算使用预留容量，从而在保证可用性和性能的同时最大化折扣。

← 数据管道监控和故障排除 · 所有领域 · 数据质量、验证和可观测性 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →