Amazon DEA-C01: Ingestão e Coleta de Dados — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Faz parte do Amazon Data Engineer Associate DEA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Este domínio abrange os padrões, serviços da AWS e detalhes operacionais usados para trazer dados brutos para uma plataforma de dados de forma confiável e em escala. Engenheiros de dados devem escolher entre pontos de entrada em lote (batch) e em tempo real (streaming), garantir a catalogação e a descoberta de dados, e projetar para throughput (vazão), capacidade de reprocessamento (replayability) e modos de falha. Os principais componentes da AWS são o S3 e o Glue para batch, Kinesis e Firehose para streaming, DMS para migração de banco de dados e CDC, e componentes orientados a API/eventos (API Gateway, Lambda, SNS, SQS, eventos do S3) para ingestão ad-hoc e baseada em push.

Ingestão em lote (batch) com AWS Glue e S3

O Glue é a principal solução gerenciada de ETL e metadados para ingestão em lote no S3 e no seu catálogo de dados. O padrão típico é: depositar arquivos brutos no S3 (usando prefixos separados para zonas raw/bruta), executar um crawler do Glue para inferir o esquema e popular o Glue Data Catalog, e então executar jobs de ETL do Glue (Spark) para transformar, particionar, converter para formatos colunares (Parquet/ORC) e gravar os dados otimizados de volta no S3. Configure os crawlers com os classificadores apropriados (integrados para CSV/JSON/Parquet ou customizados com grok/regex) e conceda ao crawler uma IAM role com permissões s3:GetObject/s3:ListBucket e glue:catalog — a falta dessas permissões é uma falha operacional comum.

Ao configurar jobs e crawlers do Glue, use estes padrões e opções no console/CLI:

Criar crawler:

undefined

e inicie com

undefined

Job do Glue:

undefined

; habilite os job bookmarks para evitar o reprocessamento. Critérios de decisão para o Glue vs. alternativas:

Use o Glue quando você precisar de ETL Spark gerenciado, descoberta de esquema e integração do catálogo com Athena/Redshift Spectrum.
Use o EMR quando precisar de ajuste fino especializado do cluster, bibliotecas customizadas ou clusters de longa duração.
Use uma simples função Lambda ou Glue on-demand para transformações leves em arquivos pequenos.

Ingestão em tempo real (streaming) com Kinesis Data Streams e Firehose

O Kinesis Data Streams (KDS) é para ingestão em tempo real com capacidade de reprocessamento (replay), controle de consumidores e escalabilidade granular. Um shard do Kinesis fornece 1 MB/s ou 1.000 registros/s de capacidade de escrita e 2 MB/s de capacidade de leitura; use

undefined

e insira dados com

undefined

. As chaves de partição determinam para qual shard os dados são enviados; uma baixa cardinalidade da chave de partição causa “hot shards” (shards sobrecarregados) — evite isso aumentando a entropia da chave ou adicionando um sufixo com um hash. Escale os shards usando

undefined

ou habilite o modo On-Demand para escalabilidade automática.

O Firehose é um serviço de stream de entrega otimizado para entrega em tempo quase real (near-real-time) para destinos como S3, Redshift, OpenSearch e Splunk, com buffering, compressão e transformação opcional com Lambda integrados. Configure o buffering com BufferingHints: buffer_size (MB) e buffer_interval (segundos) para ajustar a latência de entrega versus o custo; habilite a compressão (GZIP, Snappy) e defina uma função Lambda de processamento para transformações no nível do registro. Principais diferenças:

Kinesis Data Streams:
- Tempo real, suporta múltiplos consumidores, reprocessamento (replay) de dados retidos, gerenciamento explícito de shards
- Throughput por shard (1MB/1k de escritas), exige o design de chaves de partição
Kinesis Data Firehose:
- Entrega gerenciada para destinos, retentativa/backoff automáticos, sem reprocessamento (replay) de registros entregues
- Suporta buffering (tamanho/tempo), compressão, transformação via Lambda, staging em S3 para cargas no Redshift

Escolha o KDS quando precisar de reprocessamento (replay), forte controle sobre os consumidores ou múltiplos consumidores downstream; escolha o Firehose quando precisar de entrega e transformação simples para S3/Redshift/OpenSearch com o mínimo de sobrecarga operacional.

Migração de banco de dados e CDC com DMS

O AWS DMS é usado para migrações homogêneas/heterogêneas e replicação contínua (CDC). Implante uma instância de replicação (

undefined

) dimensionada para o throughput necessário, com decisões de dimensionamento baseadas na taxa de alteração, volume da carga completa e paralelismo das tarefas. Tipos de tarefa do DMS:

full-load: copia apenas os dados existentes
cdc: replica continuamente as alterações em andamento
full-load + cdc: carga inicial e depois continua replicando as alterações Configure os endpoints com as configurações de engine apropriadas (JDBC/connection-string), habilite o logging suplementar ou plugins na origem e forneça um mapeamento de tabelas em JSON para filtrar/incluir tabelas. Para origens baseadas em MySQL, o CDC do DMS requer que o binary logging (binlog) esteja habilitado e o binlog_format apropriado (ROW é recomendado) na origem; para PostgreSQL, você deve habilitar a replicação lógica e um plugin como o wal2json ou usar replication slots. Monitore as tarefas através das métricas do CloudWatch e dos logs da tarefa; ajuste batchApplyEnabled e maxFullLoadSubTasks para otimizar o throughput.

Critérios de decisão entre full-load e CDC: use full-load+CDC quando precisar de uma migração com tempo de inatividade (downtime) mínimo; use apenas CDC para replicação contínua após uma carga inicial ter sido concluída por outro mecanismo. Sempre valide o mapeamento de esquema e execute migrações de teste com volumes de dados representativos.

Padrões de ingestão baseados em API e orientados a eventos

APIs e eventos são para ingestão e orquestração baseadas em push. Padrões comuns:

API Gateway -> Lambda -> Firehose/Kinesis: adequado para quando os clientes enviam eventos JSON. Use o throttling do API Gateway e os controles de concorrência do Lambda para fornecer contrapressão (backpressure) e impor cabeçalhos de idempotência.
Notificações de eventos do S3: configure notificações de bucket para enviar eventos de criação de objetos (object-created) para o Lambda, SQS ou SNS através do console ou do comando

undefined

; use filtros de prefixo/sufixo para limitar os gatilhos. Para fan-out, roteie S3 -> tópico SNS -> múltiplas filas SQS/assinantes Lambda para entregar o mesmo evento a múltiplos consumidores sem acoplamento.

SQS e SNS para ingestão durável e desacoplada: SQS para processamento por workers baseado em pull com tempo limite de visibilidade (visibility timeout), SNS para fan-out por push.

Questões operacionais e padrões de CLI:

Use DLQs para falhas no Lambda/SQS; configure a política de novas tentativas (retry policy) nas assinaturas do SNS.
Para streaming de alta vazão (high-throughput) a partir de APIs, prefira o envio em lote (batching) para o Kinesis ou Firehose em vez de gravações síncronas downstream para evitar o bloqueio de clientes da API.

Armadilhas Comuns e Critérios de Decisão

Confundir Kinesis Data Streams (com capacidade de replay, gerenciado por shards) com Firehose (entrega gerenciada, sem replay): escolha o KDS quando precisar de replay ou múltiplos consumidores; escolha o Firehose para pipelines de entrega diretos.
Esquecer as permissões do IAM para o crawler do Glue: sempre anexe uma role do IAM que conceda permissões

undefined

para que os crawlers possam popular o Data Catalog.

Falta de logging binário/replicação lógica para o CDC do DMS: habilite o binlog no MySQL (formato ROW) ou a replicação lógica e o wal2json no PostgreSQL antes de iniciar as tarefas de CDC.
Baixa cardinalidade da chave de partição causando shards sobrecarregados (hot shards): aumente a cardinalidade da chave de partição por meio de hashing, inclua atributos de alta cardinalidade ou aumente a contagem de shards; monitore as métricas de throttling de Put/Get.
Excesso de buffer no Firehose ou configuração incorreta de buffer levando a alta latência: ajuste

undefined

com base na latência aceitável e no volume de requisições.

Depender de notificações de eventos do S3 sem DLQ ou novas tentativas (retry): use fan-out com SNS/SQS ou Lambda com DLQ para evitar a perda de eventos e garantir um fan-out durável.

Problema Prático: Cenário de Caso de Uso

A RetailCo coleta clickstreams de dispositivos móveis (alto volume em tempo real) e arquivos noturnos de catálogo de produtos; eles precisam de dashboards em tempo real e um lago de analytics consolidado.

Ingerir clickstreams no Kinesis Data Streams com chaves de partição derivadas da sessão do usuário + um sufixo de shard com hash; criar consumidores usando Kinesis Data Analytics ou Lambda/Kinesis Client Library para processamento em tempo real.
Usar o Kinesis Data Firehose com uma função Lambda de transformação para persistir as saídas de streaming enriquecidas no S3 (Parquet), comprimir com Snappy e, opcionalmente, carregar no Redshift Spectrum para analytics.
Colocar os arquivos de catálogo noturnos em

undefined

e executar um crawler agendado do Glue para atualizar o Glue Data Catalog, depois executar jobs de ETL do Glue para converter para Parquet particionado na zona curada (curated zone). 4. Usar notificações de eventos do S3 -> SNS -> Lambda para disparar atualizações leves de metadados ou invalidar caches; rotear a entrega para o SQS para processamento downstream durável. 5. Monitorar as métricas de shard do Kinesis (IncomingBytes, IncomingRecords, PutRecords.Success) e usar

undefined

ou streams On-Demand para lidar com o crescimento; habilitar alarmes do CloudWatch.

Justificativa da boa prática da AWS: separar os caminhos de tempo real e de lote (batch), usar o Kinesis Data Streams quando replay e isolamento de consumidores são necessários, usar o Firehose para entrega gerenciada para o S3/destinos e manter um Glue Data Catalog para descoberta e integração de consultas com o Athena/Redshift.

Todos os domínios · Armazenamento de Dados e Arquitetura de Lake →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →