Amazon DEA-C01: Qualidade, Validação e Observabilidade 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 as práticas de ponta a ponta e os serviços da AWS usados para garantir a correção dos dados, detectar anomalias e manter a confiabilidade dos pipelines. Validação e observabilidade robustas reduzem defeitos em etapas posteriores, atendendo aos SLAs e permitindo o reprocessamento seguro. Engenheiros de dados devem combinar o Glue Data Quality, frameworks de validação, detecção de anomalias do CloudWatch, DLQs e design idempotente para construir pipelines robustos.

Regras e avaliação do AWS Glue Data Quality

O Glue Data Quality usa conjuntos de regras da Data Quality Definition Language (DQDL) para definir asserções sobre conjuntos de dados (contagens de linhas, limiares de nulos, unicidade, verificações SQL personalizadas). Crie conjuntos de regras no console ou com a CLI (padrão de exemplo:

undefined

). Os conjuntos de regras podem ser anexados a jobs de ETL do Glue ou executados de forma independente por meio das APIs

undefined

/

undefined

para avaliar conjuntos de dados armazenados no S3, tabelas do catálogo ou Glue DynamicFrames.

Principais detalhes de configuração e critérios de decisão:

• Estrutura DQDL: as regras incluem

undefined

,

undefined

(DQDL ou SQL),

undefined

e

undefined

. Defina explicitamente a ação em caso de falha como

undefined

para o job quando verificações críticas falharem; caso contrário, o Glue pode registrar os resultados sem falhar a execução.

• Contexto de avaliação: forneça referências de tabela ou caminho do S3 e opções de amostragem (varredura completa vs. amostra) por meio de parâmetros do job ou entradas da execução de avaliação para equilibrar custo vs. cobertura.
• Saída: a avaliação das regras grava os resultados nas métricas do Glue e no Amazon S3 como JSON; use esses artefatos para auditoria e remediação automatizada.

Quando usar o Glue Data Quality vs. frameworks externos:

• Use o Glue DQDL para regras padrão de esquema, completude e unicidade simples que se integram nativamente aos jobs e à linhagem (lineage) do Glue.
• Use o Great Expectations (veja o próximo subdomínio) quando precisar de bibliotecas de expectativas mais ricas, verificações mais expressivas ou conjuntos de expectativas compartilhados entre múltiplos sistemas.

Padrões de validação de dados em pipelines

A validação deve ocorrer em múltiplos pontos de contato: entrada (ingress), transformação e destino (sink). Padrões comuns:

• Verificações leves de pré-ingestão em produtores Lambda/Kinesis para esquema e faixas de valores básicos para rejeitar ou rotear linhas inválidas antes do pipeline.
• Validação no lado do servidor em jobs de ETL do Glue (Spark) usando conjuntos de regras DQDL e validações explícitas no código. No Glue Studio, adicione uma transformação de Data Quality que referencie um conjunto de regras; na CLI, passe

undefined

ou inclua parâmetros de job para acionar as execuções de avaliação.

• Validação pós-transformação com o Great Expectations integrado a jobs Glue Python Shell ou Glue Spark. Implante as expectativas no S3 (diretório

undefined

) e carregue o DataContext no job:

undefined

após sincronizar as expectativas do S3 com o ambiente do job.

Comparação das opções de validação:

• Glue DQDL
  • Prós: integração nativa, baixa sobrecarga operacional, grava resultados no catálogo/métricas do Glue
  • Contras: menos expressivo para expectativas lógicas complexas
• Great Expectations
  • Prós: expectativas ricas, data docs, checkpoints integrados, backends extensíveis
  • Contras: requer empacotamento e gerenciamento de artefatos de expectativas no S3 e orquestração nos jobs do Glue
• Verificações manuais no código (Spark/DataFrame)
  • Prós: flexibilidade total, alto desempenho para lógica personalizada
  • Contras: manutenção mais alta, sem relatórios padronizados sem trabalho extra

Para streaming, valide os registros em trânsito e, em caso de falha, envie para uma DLQ do SQS (configure a

undefined

com

undefined

via AWS CLI ou console) em vez de descartá-los. Para batch, gere um artefato de relatório de validação e falhe ou coloque as saídas em quarentena com base na política.

Detecção de anomalias e monitoramento de desvio de dados (data drift)

Use a detecção de anomalias do CloudWatch para métricas operacionais (registros processados, taxa de erro, duração do job). Crie um detector com a CLI:

undefined

e, em seguida, crie alarmes do CloudWatch que referenciem a banda de detecção de anomalias. Para desvio no nível dos dados (mudanças de distribuição, alterações na taxa de nulos), agende jobs de perfil do Glue DataBrew (

undefined

) para calcular estatísticas, histogramas e quantis; armazene os perfis no S3 como linhas de base (baselines).

Critérios de decisão para alarmes de anomalia vs. de limiar:

• Escolha a detecção de anomalias do CloudWatch quando os padrões das métricas forem sazonais ou variáveis; ela aprende o comportamento passado e reduz o ajuste manual de limiares.
• Use alarmes de limiar estático para condições binárias (ex: job travado > X horas) onde a previsibilidade é alta.

Para detecção automatizada de desvio (drift):

• Agende jobs de perfil do DataBrew regulares (diários/semanais, dependendo da velocidade dos dados) para capturar as linhas de base das métricas (% de nulos, cardinalidade, percentis).
• Compare as novas saídas de perfil com os perfis de linha de base usando conjuntos de regras do Glue (verificações SQL personalizadas) ou expectativas personalizadas do Great Expectations que referenciam as estatísticas da linha de base.
• Alerte usando SNS / EventBridge quando o desvio ultrapassar os limiares da política ou quando os detectores de anomalias sinalizarem um comportamento incomum das métricas.

Gerenciamento de SLA e confiabilidade do pipeline

O gerenciamento de SLA conecta a observabilidade à remediação e à engenharia de confiabilidade. Instrumente cada pipeline com estas métricas de base: vazão (registros/seg), latência (ingestão→sink), taxa de erro, tempo de execução do job e contagens downstream. Use o CloudWatch Metrics para jobs do Glue (métricas de execução de job), lag de consumidor do Kinesis/Kafka e métricas de aplicação personalizadas via PutMetricData.

Padrões de confiabilidade e detalhes de configuração:

• Filas de mensagens mortas (DLQ do SQS): para consumidores de streaming (Lambda, consumidores do Kinesis), configure uma DLQ e defina a RedrivePolicy(maxReceiveCount). Use a retenção da DLQ e um job de processamento separado para inspecionar e reprocessar as mensagens da DLQ.
• Design idempotente: garanta que os sinks suportem escritas idempotentes — exemplos:
  • DynamoDB: use PutItem com expressões condicionais ou uma chave composta para o token de idempotência.
  • S3: escreva com padrões de renomeação atômica ou use chaves baseadas em conteúdo (hash do registro) para que os reprocessamentos sobrescrevam em vez de duplicar.
  • Redshift/Glue ETL: use staging + MERGE por chave para deduplicar após o reprocessamento.
• Checkpointing: habilite os checkpoints do conector Kinesis/DynamoDB e gerencie a frequência de checkpoint do consumidor para equilibrar a janela de reprocessamento e o risco de duplicação.

Critérios de decisão para retry vs. fail-fast:

• Para falhas transitórias (throttling no sistema de destino), implemente retries com backoff exponencial e uma DLQ somente após o máximo de tentativas.
• Para falhas de qualidade de dados (incompatibilidade de schema), aplique fail-fast e escreva os registros problemáticos em um prefixo S3 de quarentena com metadados para revisão manual.

Armadilhas Comuns e Critérios de Decisão

• As regras do Glue Data Quality registram falhas, mas não falham o job por padrão — configure a ação da regra para FAIL para verificações críticas e anexe a avaliação do conjunto de regras à execução do job.
• Pipelines de streaming sem DLQs descartam ou perdem registros com falha — sempre configure DLQs do SQS (ou staging persistente no S3) e uma política de redirecionamento (redrive policy) para inspecionar e reprocessar.
• O reprocessamento sem idempotência produz registros duplicados — projete chaves determinísticas, use semântica de upsert/merge no sink ou aplique chaves de objeto baseadas em conteúdo para o S3.
• A detecção de desvio de dados (data drift) sem linhas de base (baselines) produz alertas ruidosos — agende jobs de perfil (profile) do Glue DataBrew para criar e armazenar estatísticas de linha de base e, em seguida, compare novos perfis com elas.
• A dependência excessiva de limites estáticos do CloudWatch causa falsos positivos — use a detecção de anomalias do CloudWatch para métricas sazonais/variáveis e reserve limites estáticos para limites não negociáveis.
• Definir um maxReceiveCount muito alto adia o roteamento para a DLQ e aumenta a latência de processamento — escolha um maxReceiveCount sensato para que as DLQs recebam mensagens que falham persistentemente em tempo hábil.

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

A Streamline Retail enfrenta erros frequentes nos relatórios downstream após o ETL noturno: alterações inesperadas ocasionais no schema, violações silenciosas de regras e pedidos duplicados ao reprocessar execuções com falha.

1. Implemente regras do Glue Data Quality (DQDL) para schema, limites de nulos e unicidade em order_id; defina a ação em caso de falha para FAIL no job e publique os artefatos de avaliação no S3.
2. Adicione o Great Expectations em um passo de Glue Python Shell para verificações de negócio complexas (consistência de pedidos entre tabelas); armazene as expectativas (expectations) no S3 e execute checkpoints no pipeline.
3. Agende jobs de perfil do DataBrew para capturar baselines diários (cardinalidade, taxa de nulos, percentis) e use comparações automatizadas para detectar desvios (drift).
4. Para eventos de pedidos em streaming, configure uma DLQ do SQS com uma RedrivePolicy apropriada e crie um job de replay para processar mensagens da DLQ de forma idempotente (usando order_id como a chave de deduplicação).
5. Instrumente detectores de anomalias do CloudWatch para o tempo de execução do job e a contagem de erros; anexe alarmes baseados em anomalias ao SNS para escalonamento da equipe de plantão (on-call).

Justificativa da best-practice da AWS: combine os controles de qualidade nativos do Glue para uma integração rápida, o Great Expectations para expressividade, o DataBrew para estatísticas de linha de base e os detectores de anomalias do CloudWatch para monitoramento adaptativo. DLQs e sinks idempotentes fecham o ciclo para novas tentativas (retries) e reprocessamento seguros, enquanto preservam os SLAs.

← Otimização de Custos para Cargas de Trabalho de Dados · Todos os domínios

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

Navegar Amazon →