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 服务。强大的验证和可观测性可以减少下游缺陷，满足 SLA 并实现安全的重新处理。数据工程师必须结合使用 Glue Data Quality、验证框架、CloudWatch 异常检测、DLQ（死信队列）和幂等设计来构建稳健的管道。

AWS Glue Data Quality 规则和评估

Glue Data Quality 使用数据质量定义语言 (DQDL) 规则集来定义关于数据集的断言（例如行数、空值阈值、唯一性、自定义 SQL 检查）。您可以在控制台中或使用 CLI 创建规则集（示例模式：aws glue create-data-quality-ruleset –name MyRuleset –rules file://dqdl.json）。规则集可以附加到 Glue ETL 作业，也可以通过 StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun API 独立运行，以评估存储在 S3、目录表或 Glue DynamicFrames 中的数据集。

关键配置细节和决策标准：

• DQDL 结构：规则包括 ruleName、表达式 (DQDL 或 SQL)、严重性 (severity) 和失败时的操作 (action on failure)。当关键检查失败时，明确将失败操作设置为 FAIL 作业；否则 Glue 可能只记录结果而不会使运行失败。
• 评估上下文：通过作业参数或评估运行的输入提供表或 S3 路径引用以及采样选项（全量扫描 vs. 抽样），以平衡成本与覆盖范围。
• 输出：规则评估将结果写入 Glue 指标和 Amazon S3 (以 JSON 格式)；使用这些产物进行审计和自动化修复。

何时使用 Glue Data Quality 与外部框架的对比：

• 对于与 Glue 作业和血缘关系原生集成的标准模式、完整性和简单的唯一性规则，请使用 Glue DQDL。
• 当您需要更丰富的期望库、更具表现力的检查，或跨多个系统共享的期望套件时，请使用 Great Expectations（参见下一个子领域）。

管道中的数据验证模式

验证应位于多个接触点：入口 (ingress)、转换 (transformation) 和输出 (sink)。常见模式：

• 在 Lambda/Kinesis 生产者中进行轻量级的预摄取检查，针对模式和基本值范围，以便在进入管道前拒绝或路由不良数据行。
• 在 Glue ETL (Spark) 作业中使用 DQDL 规则集和代码中的显式验证进行服务器端验证。在 Glue Studio 中，添加一个引用规则集的数据质量转换；在 CLI 中，传递 –arguments ‘{"–enable-glue-datacatalog":""}’ 或包含作业参数以触发评估运行。
• 在转换后使用集成到 Glue Python Shell 或 Glue Spark 作业中的 Great Expectations 进行验证。将期望部署到 S3 (expectations/ 目录) 并在作业中加载 DataContext：在将 S3 期望同步到作业环境后，使用 DataContext(root_dir="/tmp/ge")。

验证选项的比较：

对于流式处理，验证传输中的记录，并在失败时将其推送到 SQS DLQ（死信队列）（通过 AWS CLI 或控制台配置带有 maxReceiveCount 的 RedrivePolicy），而不是直接丢弃。对于批处理，生成验证报告产物，并根据策略使输出失败或隔离输出。

异常检测和数据漂移监控

使用 CloudWatch 异常检测来监控运营指标（处理的记录数、错误率、作业持续时间）。使用 CLI 创建一个检测器：aws cloudwatch put-anomaly-detector –namespace “Glue” –metric-name “JobRunTime” –statistic “Average” –single-metric-anomaly-detector ‘{“MetricName”:“JobRunTime”,“Namespace”:“Glue”,“Stat”:“Average”,“Dimensions”:[…]}’，然后创建引用该异常检测范围的 CloudWatch 告警。对于数据级漂移（分布变化、空值率变化），调度 Glue DataBrew profile 作业 (aws databrew create-profile-job) 以计算统计数据、直方图和分位数；将配置文件作为基线存储在 S3 中。

异常检测告警与阈值告警的决策标准：

• 当指标模式具有季节性或可变性时，选择 CloudWatch 异常检测；它能学习过去的行为并减少手动调整阈值的工作。
• 对于可预测性高的二进制条件（例如，作业卡住超过 X 小时），使用静态阈值告警。

对于自动化漂移检测：

• 调度定期的 DataBrew profile 作业（每日/每周，取决于数据速率）以捕获指标基线（空值百分比、基数、百分位数）。
• 使用 Glue 规则集（自定义 SQL 检查）或引用基线统计数据的 Great Expectations 自定义期望，将新的配置文件输出与基线配置文件进行比较。
• 当漂移超过策略阈值或异常检测器标记出不寻常的指标行为时，使用 SNS / EventBridge 发出警报。

SLA 管理与管道可靠性

SLA 管理将可观测性与修复及可靠性工程联系起来。为每个管道配置这些基线指标：吞吐量 (记录/秒)、延迟 (从摄入到接收器)、错误率、作业/运行时长以及下游计数。使用 CloudWatch Metrics 监控 Glue 作业 (作业运行指标)、Kinesis/Kafka 消费者延迟，并通过 PutMetricData 监控自定义应用程序指标。

可靠性模式和配置详情：

• 死信队列 (SQS DLQ)：对于流式消费者 (Lambda、Kinesis 消费者)，配置一个 DLQ 并设置 RedrivePolicy(maxReceiveCount)。使用 DLQ 保留策略和一个单独的处理作业来检查和重新处理 DLQ 消息。
• 幂等设计：确保数据接收器支持幂等写入 — 示例：
  • DynamoDB：使用带条件表达式的 PutItem，或使用复合键作为幂等性令牌。
  • S3：使用原子重命名模式写入，或使用基于内容的键 (记录的哈希值)，以便重放时覆盖而非创建副本。
  • Redshift/Glue ETL：通过按键进行暂存 (staging) + MERGE，在重新处理后进行去重。
• 检查点机制：启用 Kinesis/DynamoDB 连接器的检查点，并管理消费者的检查点频率，以平衡重处理窗口和数据重复的风险。

重试与快速失败的决策标准：

• 对于瞬时故障 (如下游限流)，应实现带指数退避的重试，并在达到最大重试次数后才发送到 DLQ。
• 对于数据质量故障 (如模式不匹配)，应快速失败，并将有问题的记录连同元数据写入一个隔离的 S3 前缀，以供手动审查。

常见陷阱与决策标准

• Glue Data Quality 规则默认只记录失败，但不会使作业失败 — 对于关键检查，应将规则操作配置为 FAIL，并将规则集评估附加到作业运行中。
• 没有 DLQ 的流式管道会丢弃或丢失失败的记录 — 务必配置 SQS DLQ (或持久化的 S3 暂存区) 和重驱动策略，以便检查和重新处理。
• 没有幂等性的重处理会产生重复记录 — 应设计确定性键，在接收器端使用 upsert/merge 语义，或为 S3 应用基于内容的对象键。
• 没有基线的数据漂移检测会产生大量嘈杂的警报 — 应调度 Glue DataBrew 分析作业来创建并存储基线统计数据，然后将新的分析结果与基线进行比较。
• 过度依赖静态 CloudWatch 阈值会导致误报 — 对季节性/可变指标应使用 CloudWatch 异常检测，仅对不可协商的限制使用静态阈值。
• 将 maxReceiveCount 设置得过高会延迟消息路由到 DLQ，并增加处理延迟 — 应选择一个合理的 maxReceiveCount，以便持续失败的消息能及时进入 DLQ。

实践问题：用例场景

Streamline Retail 公司在夜间 ETL 后，下游报表频繁出错：偶尔出现模式突变、静默的规则违反，以及在重处理失败的运行时产生重复订单。

1. 实施 Glue Data Quality 规则 (DQDL)，对模式、空值阈值和 order_id 的唯一性进行检查；将失败时的操作设置为 FAIL 作业，并将评估产物发布到 S3。
2. 在一个 Glue Python Shell 步骤中添加 Great Expectations，用于复杂的业务检查 (如跨表的订单一致性)；将期望 (expectations) 存储在 S3 中，并在管道中运行检查点。
3. 调度 DataBrew 分析作业以捕获每日基线 (如基数、空值率、百分位数)，并使用自动化比较来检测数据漂移。
4. 对于流式订单事件，配置带有适当 RedrivePolicy 的 SQS DLQ，并创建一个重放作业，以幂等方式处理 DLQ 消息 (使用 order_id 作为去重键)。
5. 为作业运行时长和错误计数配置 CloudWatch 异常检测器；将基于异常的警报附加到 SNS，用于待命升级。

AWS 最佳实践基本原理：结合使用原生 Glue 质量控制以实现快速集成，使用 Great Expectations 增强表达能力，使用 DataBrew 获取基线统计数据，并使用 CloudWatch 异常检测器进行自适应监控。DLQ 和幂等接收器为安全重试和重处理形成了闭环，同时保障了 SLA。

← 数据工作负载成本优化 · 所有领域

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

浏览 Amazon →