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 上能够及时、准确地交付。此领域涵盖了 Kinesis、Firehose、Glue、DMS、Lambda 等服务的遥测、告警和诊断技术，以及支持事件调查的 AWS 审计日志。有效的监控通过暴露消费者延迟、作业资源压力、交付延迟和未授权访问等问题，来降低平均检测/恢复时间（Mean Time To Detect/Recover）。以下各节将提供具体信号、CLI/控制台模式和决策标准，以帮助您运维和修复生产环境中的数据流。

针对数据服务的 CloudWatch 指标和告警

CloudWatch 是主要的遥测平台：您可以为关键服务指标创建指标筛选器、仪表板和告警，并将告警与 SNS、EventBridge 或 Systems Manager 集成以实现自动化修复。使用 aws cloudwatch put-metric-alarm 以编程方式创建告警；典型的标志包括 --metric-name、--namespace、--statistic (或 --extended-stat)、--threshold、--evaluation-periods 和 --comparison-operator。对于仪表板，可以使用 aws cloudwatch put-metric-data 推送自定义指标（例如，来自 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 发送指标，并将日志写入 /aws-glue/jobs/output（作业运行日志）和 /aws-glue/jobs/error（错误日志）。使用 CloudWatch Logs Insights 查询作业运行情况：可以通过控制台或使用 aws logs start-query 运行查询，查询字符串示例：fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20。从 Glue 作业运行指标中跟踪 BytesRead、BytesWritten、RecordsProcessed 和 DPUHrs——DPUHrs 与成本和作业并行度直接相关。

常见的 Glue 故障模式及修复方法：

• 内存不足 (OOM) 或 Executor 丢失：增加工作节点类型/DPU 数量，对于内存需求更高的场景切换到 G.2X 工作节点类型，或优化 Spark 分区（repartition/coalesce）并使用下推谓词来减少输入数据量。
• 数据倾斜导致出现拖慢任务（stragglers）：使用分区键进行重新平衡，增加并行度，或在适当情况下使用 Glue DynamicFrame 的 split/resolve 选项。
• 作业停滞或启动时间过长：启用作业书签，并监控 Glue JobMetrics 中的 “TimeWaitingForResources” 以识别容量争用问题。

决策权衡：

• 当 CPU/内存是瓶颈且运行时可预测性很重要时，增加 DPU；如果必须控制成本，则优先选择代码优化（如分区、仅在需要时缓存）。
• 对于近实时的转换，使用 Glue streaming；对于复杂的 Spark 转换和更适合 Spot 实例的大型工作负载，使用 Glue 批量 ETL。

Kinesis 和 Firehose 监控

Kinesis 消费者延迟：依赖 GetRecords.IteratorAgeMilliseconds 来检测消费者的落后程度。如果 GetRecords.IteratorAgeMilliseconds 持续很高：

• 通过增加分片数量（重分片/扩展）来进行扩展，或者
• 通过批处理、使用增强型扇出（每个消费者吞吐量最高可达 2 MB/秒）或使用带有改进检查点机制的 Kinesis Client Library (KCL) v2 来提升消费者性能。

使用 aws kinesis describe-stream 检查分片数量，使用 aws cloudwatch get-metric-statistics 获取 GetRecords.IteratorAgeMilliseconds。在比较修复方案时，请考虑：

• 增加分片：提高摄入和读取吞吐量；需要重分片和重新平衡。
• 增强型扇出：避免共享读取吞吐量，但会增加每个消费者的成本。
• 消费者优化：减少对额外分片的需求和成本，但需要工程投入。

Firehose 交付指标：DeliveryToS3.DataFreshness 量化了交付延迟；典型的 buffering_delay 设置为 60-900 秒，它会一直持有记录，直到达到 bufferSize 或 bufferInterval。如果 DeliveryToS3.DataFreshness 过高：

• 在控制台中或通过 aws firehose describe-delivery-stream 检查 Firehose 的缓冲提示（BufferIntervalInSeconds、BufferSizeInMBs）。
• 检查 CloudWatch Errors (DeliveryToS3.RecordsFailed) 和 S3 存储桶权限（如果加密，则检查 KMS 错误）。

请记住 Firehose 的缓冲语义：该服务会有意延迟，最长可达缓冲间隔时间；减小缓冲间隔可以降低延迟，但代价是更频繁地向 S3 写入。

CloudTrail 与数据访问审计

CloudTrail 提供 API 活动，以及针对 S3 和 Lambda 的可选数据事件（默认不启用）。要捕获对象级别的 S3 事件，需要通过控制台或 aws cloudtrail create-trail --include-global-service-events 命令在 CloudTrail 上显式启用数据事件，并添加 S3 数据资源。如果不启用 S3 数据事件，您将无法在 CloudTrail 中看到 GetObject/PutObject 事件，这是调查过程中的一个常见疏漏。

使用 CloudTrail 日志结合 CloudWatch Logs Insights，可以将运营指标（例如 Glue 作业日志）与访问事件关联起来。查询模式：

• CloudWatch Logs Insights: filter @message like /GetObject/ | stats count() by userIdentity.principalId
• 使用 EventBridge 规则对特定的 API 调用（例如 PutBucketAcl）做出反应，并转发到 SNS 以进行快速告警。

DMS 复制任务也会发布 CloudWatch 指标：监控 FullLoadRows 以了解初始复制的完整性，监控 CDCLatencyMilliseconds 以检测复制延迟，以及监控 AppliedChanges 以确保事务正在目标端应用。当 CDCLatencyMilliseconds 超出业务 SLA 以及在全量加载行数增加后 AppliedChanges 过低时，应设置告警。

常见陷阱与决策标准

• Kinesis 的 IteratorAgeMilliseconds 指标过高，被误认为是源头问题 —— 正确方法：检查消费者的检查点设置和处理时间；只有在分析了消费者的 CPU/IO 后，才通过增加分片或使用增强型扇出进行扩展。
• 通过盲目增加 DPU 来处理 Glue 作业的 OOM 错误 —— 正确方法：分析 Spark 阶段，优化分区和数据筛选；只有在确认达到资源限制时才增加 DPU 或工作节点类型。
• Firehose 缓冲延迟导致感知上的数据丢失 —— 正确方法：检查 BufferIntervalInSeconds 和 BufferSizeInMBs；为满足低延迟需求可缩短间隔，并接受更高的写入速率/成本。
• 假设 CloudTrail 默认记录 S3 对象读取 —— 正确方法：在 CloudTrail 中启用 S3 数据事件，以捕获 GetObject/PutObject 用于取证审计。
• 缺少 DMS CDC 延迟告警 —— 正确方法：基于 CDCLatencyMilliseconds 创建 CloudWatch 告警，并比较 AppliedChanges 与 FullLoadRows；当延迟增长时，调查网络或事务积压问题。
• 对瞬时峰值过度告警 —— 正确方法：使用评估周期、告警数据点或异常检测来减少噪音，并使用复合告警处理关联条件。

实践问题：用例场景

Acme Analytics 公司通过 Kinesis 进行实时点击流摄取，使用 Glue ETL 作业丰富事件，通过 Firehose 将过时批次持久化到 S3，并使用 DMS 复制旧有数据库。他们观察到端到端延迟：Kinesis 出现消费者延迟，Glue 作业发生 OOM，并且 Firehose 的 DeliveryToS3.DataFreshness 指标很高。

1. 分析 Kinesis 消费者：获取 GetRecords.IteratorAgeMilliseconds 指标，检查消费者日志，并对 Kinesis 增强型扇出与分片扩展进行成本分析。
2. 检查 Glue 作业的 CloudWatch 指标和 Logs Insights 中的 OOM 堆栈跟踪；在本地或较小的作业中测试重新分区 + 下推谓词；仅在需要时才增加 DPU/工作节点类型。
3. 检查 Firehose 的缓冲设置 (BufferIntervalInSeconds) 和 DeliveryToS3.DataFreshness；为满足关键 SLO，缩短缓冲间隔，并验证 S3 写入权限/KMS。
4. 配置 CloudWatch 复合告警，结合 IteratorAgeMilliseconds、Glue 作业错误率和 Firehose DataFreshness；将告警发送到待命 SNS 主题，并通过 EventBridge 触发运行手册。
5. 启用 CloudTrail S3 数据事件，并将 GetObject/PutObject 事件与 Glue 作业启动时间和 DMS 的 applied changes 关联起来，以检测未经授权或延迟的访问。

这种方法遵循了 AWS 的最佳实践：以正确的粒度监控正确的服务指标，在扩展资源之前优先选择有针对性的代码和配置修复，并确保显式启用审计级别的日志记录，以便进行快速的根本原因分析和自动化修复。

← 数据安全、治理和合规 · 所有领域 · 数据工作负载成本优化 →

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

浏览 Amazon →