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 服务和操作细节。数据工程师必须在批量和流式入口点之间做出选择，确保数据的编目和可发现性，并针对吞吐量、可重放性和故障模式进行设计。关键的 AWS 构建模块是用于批量的 S3 和 Glue，用于流式处理的 Kinesis 和 Firehose，用于数据库迁移和 CDC 的 DMS，以及用于临时和基于推送的摄取的 API/事件驱动组件（API Gateway、Lambda、SNS、SQS、S3 事件）。

使用 AWS Glue 和 S3 进行批量摄取

Glue 是将数据批量摄取到 S3 和您的数据目录中的主要托管式 ETL 和元数据解决方案。典型模式：将原始文件存放到 S3（使用不同的 raw/zone 前缀），运行 Glue 爬网程序（crawler）以推断 schema 并填充 Glue Data Catalog，然后运行 Glue ETL 作业（Spark）进行转换、分区、转换为列式格式（Parquet/ORC），并将优化后的数据写回 S3。使用适当的分类器（内置的 CSV/JSON/Parquet 或自定义的 grok/regex）配置爬网程序，并为爬网程序提供一个具有 s3:GetObject/s3:ListBucket 和 glue:catalog 权限的 IAM 角色——缺少这些权限是一个常见的操作故障。

在配置 Glue 作业和爬网程序时，请使用以下控制台/CLI 模式和开关：

• 创建爬网程序：

undefined

，并使用

undefined

启动。

• Glue 作业：

undefined

；启用作业书签以避免重复处理。 Glue 与替代方案的决策标准：

• 当您需要托管的 Spark ETL、schema 发现以及与 Athena/Redshift Spectrum 的目录集成时，请使用 Glue。
• 当您需要专门的集群调优、自定义库或长时间运行的集群时，请使用 EMR。
• 对于小文件的轻量级转换，请使用简单的 Lambda 或 Glue on-demand。

使用 Kinesis Data Streams 和 Firehose 进行流式摄取

Kinesis Data Streams (KDS) 用于支持重放、消费者控制和精细扩展的实时摄取。一个 Kinesis 分片提供 1 MB/秒或 1,000 条记录/秒的写入容量和 2 MB/秒的读取容量；使用

undefined

创建流，并使用

undefined

推送数据。分区键决定了分片的分配；分区键基数过低会导致热分片——通过增加键的熵或添加哈希后缀来避免。使用

undefined

扩展分片或启用 On-Demand 模式以实现自动扩展。

Firehose 是一种交付流服务，专为近实时交付到目的地（S3、Redshift、OpenSearch、Splunk）而优化，具有内置的缓冲、压缩和可选的 Lambda 转换功能。使用 BufferingHints 配置缓冲：通过 buffer_size (MB) 和 buffer_interval (秒) 来调整交付延迟与成本；启用压缩（GZIP、Snappy）并设置一个处理 Lambda 以进行记录级别的转换。主要区别：

• Kinesis Data Streams:
  • 实时，支持多个消费者，可重放保留的数据，需要明确的分片管理
  • 每个分片的吞吐量（1MB/1k 写入），必须设计分区键
• Kinesis Data Firehose:
  • 到目标的托管式交付，自动重试/退避，无法重放已交付的记录
  • 支持缓冲（大小/时间）、压缩、通过 Lambda 进行转换，以及为 Redshift 加载提供 S3 中间暂存

当您需要重放、强大的消费者控制或多个下游消费者时选择 KDS；当您需要以最小的运维开销将数据简单地交付和转换到 S3/Redshift/OpenSearch 时选择 Firehose。

使用 DMS 进行数据库迁移和 CDC

AWS DMS 用于同构/异构迁移和持续复制（CDC）。部署一个复制实例（

undefined

），其大小应根据吞吐量来确定，大小决策取决于变更率、全量加载的数据量和任务并行度。DMS 任务类型：

• full-load：仅复制现有数据
• cdc：流式传输持续的变更
• full-load + cdc：初始加载，然后继续流式传输变更 使用适当的引擎设置（JDBC/连接字符串）配置端点，在源端启用补充日志记录或插件，并提供一个 JSON 表映射来筛选/包含表。对于基于 MySQL 的源，DMS CDC 要求在源端启用二进制日志（binlog）并设置适当的 binlog_format（推荐 ROW）；对于 PostgreSQL，您必须启用逻辑复制和一个类似 wal2json 的插件，或使用复制槽。通过 CloudWatch 指标和任务日志监控任务；调整 batchApplyEnabled 和 maxFullLoadSubTasks 以优化吞吐量。

full-load 和 CDC 之间的决策标准：当您需要最小停机时间迁移时，使用 full-load+CDC；在通过其他机制完成初始加载后，使用仅 CDC 模式进行持续复制。务必验证 schema 映射，并使用有代表性的数据量运行测试迁移。

基于 API 和事件驱动的摄取模式

API 和事件用于基于推送的摄取和编排。常见模式：

• API Gateway -> Lambda -> Firehose/Kinesis：适用于客户端推送 JSON 事件的场景。使用 API Gateway 节流和 Lambda 并发控制来提供背压并强制执行幂等性标头。
• S3 事件通知：通过控制台或

undefined

配置存储桶通知，以将对象创建事件发送到 Lambda、SQS 或 SNS；使用前缀/后缀过滤器来限制触发。对于扇出（fan-out）场景，将 S3 事件路由到 SNS 主题，再分发给多个 SQS 队列/Lambda 订阅者，从而在不产生耦合的情况下将同一事件交付给多个消费者。

• SQS 和 SNS 用于持久、解耦的摄取：SQS 用于基于拉取（pull-based）的工作节点处理，并带有可见性超时；SNS 用于基于推送的扇出（push fan-out）。

运维考量和 CLI 模式：

• 为 Lambda/SQS 故障使用 DLQ（死信队列）；在 SNS 订阅上配置重试策略。
• 对于来自 API 的高吞吐量流式传输，优先选择批量推送到 Kinesis 或 Firehose，而不是同步写入下游，以避免阻塞 API 客户端。

常见陷阱和决策标准

• 混淆 Kinesis Data Streams（可重放、分片需自行管理）和 Firehose（托管交付、不可重放）：当需要重放或有多个消费者时选择 KDS；对于直接的交付管道，选择 Firehose。
• 忘记 Glue 爬网程序（crawler）的 IAM 权限：务必附加一个 IAM 角色，授予 s3:GetObject/s3:ListBucket 和 glue:CreateTable/UpdateTable/DeleteTable 权限，以便爬网程序填充数据目录（Data Catalog）。
• DMS CDC 缺少二进制日志/逻辑复制：在启动 CDC 任务之前，在 MySQL 上启用 binlog（ROW 格式），或在 PostgreSQL 上启用逻辑复制和 wal2json。
• 分区键基数（cardinality）过低导致热分片（hot shards）：通过哈希、包含高基数属性或增加分片数量来提高分区键的基数；监控 Put/Get 节流指标。
• Firehose 缓冲过度或缓冲配置不当导致高延迟：根据可接受的延迟和请求量调整 buffer_size 和 buffer_interval。
• 依赖 S3 事件通知但没有配置 DLQ 或重试：使用 SNS/SQS 扇出或带 DLQ 的 Lambda 来避免事件丢失，并确保持久的扇出。

实践问题：用例场景

RetailCo 公司收集移动端点击流（高容量、实时）和夜间的产品目录文件；他们需要实时仪表板和一个统一的分析湖。

1. 将点击流摄取到 Kinesis Data Streams，分区键由用户会话 + 哈希化的分片后缀派生；使用 Kinesis Data Analytics 或 Lambda/Kinesis Client Library 创建消费者进行实时处理。
2. 使用 Kinesis Data Firehose 和一个转换 Lambda，将经过丰富的流式输出持久化到 S3（Parquet 格式），使用 Snappy 压缩，并可选择性地加载到 Redshift Spectrum 进行分析。
3. 将夜间目录文件放置在 S3 的 raw/ 目录中，并运行一个计划的 Glue 爬网程序来更新 Glue Data Catalog，然后运行 Glue ETL 作业将其转换为分区化的 Parquet 格式并存放在 curated（精选）区域。
4. 使用 S3 事件通知 -> SNS -> Lambda 来触发轻量级的元数据更新或缓存失效；将交付路由到 SQS 以进行持久的下游处理。
5. 监控 Kinesis 分片指标（IncomingBytes、IncomingRecords、PutRecords.Success），并使用 UpdateShardCount 或 On-Demand 模式的流来应对增长；启用 CloudWatch 警报。

AWS 最佳实践原理：分离实时和批处理路径，当需要重放和消费者隔离时使用 Kinesis Data Streams，使用 Firehose 进行到 S3/目标的托管交付，并维护一个 Glue Data Catalog 以便与 Athena/Redshift 进行发现和查询集成。

所有领域 · 数据存储和数据湖架构 →

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

浏览 Amazon →