Amazon DEA-C01: Transformação e Processamento 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 serviços e padrões da AWS usados para limpar, transformar e preparar dados para analytics e ML em grande escala. Ele se concentra na seleção da computação e das ferramentas corretas (Glue, Lambda, EMR, DataBrew) com base no volume de dados, nos requisitos de latência e nas restrições de custo. Compreender os limites dos serviços, os parâmetros de configuração de jobs e como os formatos de dados e catálogos interagem é fundamental para construir pipelines confiáveis e incrementais.

Jobs ETL do AWS Glue (Spark e Python shell)

Os jobs Spark do Glue são a principal escolha para ETL distribuído e em grande escala: eles rodam em Apache Spark gerenciado pelo AWS Glue, usam o GlueContext e operam nos tipos DynamicFrame e Spark DataFrame. Configure pelo console ou pela CLI com o tipo de job “glueetl”, workerType (G.1X, G.2X, G.4X) e NumberOfWorkers; inicie com a CLI: aws glue start-job-run –job-name my-spark-job –arguments ‘–execution-class=STANDARD’. Use as APIs do DynamicFrame (create_dynamic_frame.from_options, apply_mapping) quando precisar de transformações com esquema flexível, transformações integradas (Relationalize, Unnest) e tratamento automático de dados semiestruturados; converta para um Spark DataFrame com dyf.toDF() quando precisar de Spark SQL, joins de maior desempenho ou UDFs personalizadas.

Os jobs Python shell do Glue usam o tipo de job “pythonshell” para scripts leves e tarefas de plano de controle. Eles são de uma única DPU (1 DPU) com paralelismo limitado e são ideais para manipulações de arquivos pequenos, atualizações de metadados ou orquestração. Configure via aws glue create-job –name my-pyjob –command ‘{“Name”:“pythonshell”,“PythonVersion”:“3”}’ e inicie com aws glue start-job-run. Observe que os jobs Python shell têm um limite de 1 DPU — use o Spark para grandes conjuntos de dados.

Os bookmarks de job do Glue permitem o processamento incremental ao rastrear objetos e partições do S3 processados anteriormente. Habilite os bookmarks na configuração do job ou ao iniciar as execuções: aws glue start-job-run –job-name my-job –job-bookmark-option job-bookmark-enable. Os bookmarks funcionam para fontes baseadas no S3 que usam conectores integrados; fontes JDBC não suportam bookmarks por padrão e exigem watermarking personalizado ou armazenamento de estado.

O Glue agora suporta a ExecutionClass FLEX para jobs não urgentes e com custo otimizado. Inicie com aws glue start-job-run –job-name my-job –execution-class FLEX para permitir que o Glue agende o job a um custo menor com SLAs de tempo de início mais flexíveis. Use FLEX para backfills em lote e cargas de trabalho não sensíveis à latência; use STANDARD para latência previsível.

Critérios de decisão — comparações rápidas:

DynamicFrame vs Spark DataFrame
- Use o DynamicFrame ao ingerir JSON/Parquet semiestruturado com schema drift, aproveitando as transformações apply_mapping, relationalize e do Glue.
- Use o Spark DataFrame quando precisar do desempenho do Spark SQL, joins complexos, funções de janela e bibliotecas Spark de terceiros.
- Converta entre eles via DynamicFrame.fromDF(df, glueContext, “name”) e dyf.toDF().
Glue Spark vs Python shell
- Escolha Spark para ETL distribuído e multinó em grandes conjuntos de dados e ao usar a integração com o Glue Catalog em grande escala.
- Escolha Python shell para tarefas pequenas e rápidas ou etapas de orquestração que se encaixam em 1 DPU.

AWS Lambda para transformações leves

O Lambda é ideal para transformações leves, orientadas a eventos e de baixa latência, acionadas diretamente pelo S3, Kinesis ou EventBridge. Os usos típicos incluem validação de arquivos, extração de metadados, conversão de JSON para CSV para arquivos pequenos ou processamento de registros em stream. Configure a memória e o timeout com aws lambda update-function-configuration –function-name myFunc –memory-size 2048 –timeout 300. A simultaneidade provisionada (Provisioned Concurrency) pode ser definida com aws lambda put-provisioned-concurrency-config para mitigar cold starts em pipelines de streaming sensíveis à latência.

Esteja ciente dos limites do Lambda para processamento de dados: execução máxima de 15 minutos, 10 GB de memória (10.240 MB) e apenas 512 MB de armazenamento efêmero em /tmp. Para o processamento de arquivos maiores, use processamento em cadeia (dividindo arquivos), faça o stage para o S3 e invoque um job do Glue ou EMR, ou use processamento multipartes com o AWS Step Functions. Use variáveis de ambiente para configurações pequenas e políticas de IAM role que concedam estritamente o menor privilégio.

Critérios de decisão — quando escolher o Lambda:

Use o Lambda quando o processamento por invocação se encaixar nas restrições de 15 minutos, 10 GB de memória e 512 MB em /tmp, e quando for necessária uma latência de subsegundos a segundos.
Evite usar o Lambda para transformações grandes, de longa duração ou com uso intensivo de memória; em vez disso, use o Glue Spark ou o EMR.

Amazon EMR para processamento em grande escala

O EMR é a principal opção para processamento de big data personalizável e em grande escala (Spark, Hadoop, Presto, Flink), onde controle no nível do cluster, ações de bootstrap personalizadas ou bibliotecas especializadas são necessárias. Crie clusters via CLI com aws emr create-cluster e escolha entre --instance-groups ou --instance-fleets. As frotas de instâncias (Instance Fleets) fornecem combinações flexíveis de tipos de instância e combinações de instâncias Spot/On-Demand; os grupos de instâncias (Instance Groups) são mais simples, com tamanho fixo.

Padrões de cluster EMR a serem considerados:

Clusters transitórios: inicie com --auto-terminate e submeta etapas (steps) para que o cluster seja encerrado quando as etapas forem concluídas. Bom para controle de custos, mas o HDFS efêmero e o estado local serão perdidos no encerramento.
Clusters de longa duração: não encerram automaticamente; use para cargas de trabalho interativas, HDFS persistente ou quando muitos jobs pequenos se beneficiam do aquecimento da JVM. Persista dados críticos no S3 ou em armazenamento Hadoop com backend em EBS se o encerramento do cluster for esperado.

Exemplos de configuração:

CLI de grupo de instâncias: aws emr create-cluster --name Prod --release-label emr-6.6.0 --use-default-roles --instance-groups InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=4
A CLI de frota de instâncias usa --instance-fleets com alocações OnDemand/Spot e múltiplos tipos de instância para resiliência e otimização de custos.

Use o EMR quando precisar de controle total sobre os componentes do ecossistema Hadoop, scripts de bootstrap personalizados ou HDFS persistente para dados intermediários; caso contrário, o Glue Spark é mais simples para ETL Spark gerenciado que se integra com o Glue Data Catalog.

Glue DataBrew e transformações visuais

O Glue DataBrew é uma ferramenta visual, no-code/low-code, para criação de perfil (profiling), limpeza e transformação de dados, voltada para analistas e engenheiros de dados que trabalham de forma interativa. Crie um dataset a partir do S3 ou do Glue Catalog, construa uma receita (recipe) de transformações no console, visualize o resultado em uma amostra e execute jobs para aplicar as receitas em escala. Agende jobs do DataBrew ou execute-os via CLI com aws databrew start-job-run --name my-databrew-job.

O DataBrew é otimizado para tarefas de preparação de dados como padronização, desduplicação, conversão de tipos e transformações no nível da coluna com funções integradas. Ele se integra com o Glue Catalog e grava as saídas no S3. Escolha o DataBrew quando usuários de negócio precisam de limpeza de dados self-service e criação rápida de perfil; para lógica de transformação pesada, joins complexos ou conjuntos de dados muito grandes, prefira o Glue Spark ou o EMR.

Comparação de transformações visuais vs. baseadas em código:

Glue DataBrew
- Prós: criação rápida de perfil, baseado em receitas, permite que não programadores construam pipelines, agendamento integrado.
- Contras: não é adequado para joins distribuídos muito grandes ou altamente complexos e bibliotecas personalizadas.
Glue Spark / EMR
- Prós: controle programático total, lida com conjuntos de dados massivos, suporta bibliotecas de terceiros.
- Contras: requer habilidades de desenvolvedor e mais configuração.

Armadilhas Comuns e Critérios de Decisão

Assumir que os bookmarks de job do Glue funcionam para fontes JDBC — os bookmarks rastreiam apenas o estado de objetos/partições do S3; para cargas incrementais via JDBC, use colunas de marca d’água (watermark), captura de dados de alteração (change-data-capture) ou armazene o progresso no DynamoDB/S3.
Tratar clusters EMR transitórios como sistemas com estado (stateful) — clusters transitórios são encerrados após as etapas e perdem o HDFS; persista dados intermediários no S3 ou use volumes EBS para armazenamento durável.
Ignorar cold starts do Lambda em pipelines de streaming — cold starts aumentam a latência; mitigue com concorrência provisionada para caminhos críticos ou use recursos computacionais de longa duração para requisitos rigorosos de baixa latência.
Executar grandes transformações no Python shell do Glue — jobs de Python shell são limitados a 1 DPU; para grandes conjuntos de dados, use jobs do Glue Spark com workerType/NumberOfWorkers apropriados.
Configurar incorretamente os tipos de instância do EMR: escolha frotas de instâncias para custo e flexibilidade com instâncias spot; use grupos de instâncias quando precisar de uma composição de instâncias previsível.
Uso excessivo do Glue Flex para cargas de trabalho urgentes — o FLEX reduz o custo, mas pode atrasar os tempos de início; use STANDARD para tempos de início e execução previsíveis.

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

A AcmeRetail processa arquivos Parquet de clickstream noturnos em uma tabela unificada de atividade do cliente e deseja processamento incremental para evitar reprocessar meses de dados, mantendo os custos baixos para preenchimentos retroativos (backfills) não urgentes.

Use um layout particionado no S3 (year=/month=/day=) e registre o dataset no Glue Data Catalog.
Crie um job do Glue Spark (glueetl) que lê DynamicFrame.from_catalog para flexibilidade de esquema, aplica mapeamentos, converte para DataFrame para joins complexos e grava o Parquet particionado de volta no S3.
Habilite os bookmarks de job do Glue (job-bookmark-enable) para as execuções noturnas para processar apenas as partições novas; para fontes de enriquecimento JDBC, implemente colunas de marca d’água (watermark) persistidas no DynamoDB para rastrear o timestamp máximo processado.
Para execuções noturnas de rotina, use ExecutionClass=STANDARD; para reprocessamento histórico não urgente, submeta as execuções com --execution-class FLEX para economizar custos.
Monitore com métricas do CloudWatch e defina alarmes para falhas de job; para escala muito grande ou bibliotecas personalizadas, considere clusters transitórios do EMR que gravam resultados intermediários no S3 e encerram automaticamente.

Justificativa: Esta abordagem aproveita o Spark gerenciado do Glue para transformações escaláveis e os DynamicFrames para entradas semiestruturadas, usa bookmarks de job para processamento incremental do S3 e usa o FLEX para reduzir custos de preenchimentos retroativos — preservando custo, confiabilidade e simplicidade operacional.

← Catalogação de Dados e Gerenciamento de Metadados · Todos os domínios · Orquestração de Dados e Gerenciamento de Fluxo de Trabalho →

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