Construir um pipeline não é o fim — você precisa continuar observando para saber que está funcionando corretamente. Se um job de processamento de dados falhar e você descobrir seis horas depois, dados incorretos podem já ter aparecido em relatórios. Monitoramento é sobre detectar problemas rapidamente. Gerenciamento de qualidade de dados é sobre impedir que dados incorretos passem pelo pipeline desde o início. As questões do exame DEA-C01 sobre esses tópicos aparecem como cenários de estabilidade operacional e confiabilidade de dados.
CloudWatch — O serviço central de monitoramento da AWS
O CloudWatch é a plataforma de monitoramento onde você pode observar quase tudo que acontece na AWS. Pense nele como uma máquina de check-up de saúde que mede os sinais vitais do serviço como números e envia alertas quando algo parece errado.
Métricas: Medidas numéricas ao longo do tempo. Contagem de invocações de funções Lambda, duração de execução de jobs do Glue, latência do stream do Kinesis — todas são métricas. Algumas métricas são coletadas automaticamente; outras são métricas personalizadas que seu código publica diretamente.
Alarmes: Alarmes observam uma métrica e disparam uma ação quando ela cruza um limite. Por exemplo, se a taxa de erros do Lambda exceder 5%, enviar um email via SNS ou acionar uma política de Auto Scaling.
Logs: O CloudWatch Logs coleta a saída de texto dos serviços. Instruções print de funções Lambda, mensagens de erro de jobs do Glue e logs do sistema EMR vão para o CloudWatch Logs.
Logs Insights: Consulte seus logs do CloudWatch usando uma linguagem similar a SQL. Busque mensagens de erro específicas em grandes volumes de logs, ou agregue contagens de erros por janela de tempo.
Monitoramento por serviço
Cada serviço AWS publica suas próprias métricas no CloudWatch.
Monitoramento do Glue: : Quanto dado o job do Glue leu : Número de tarefas com falha : Uso de memória heap da JVM O histórico de execução de jobs também é visível diretamente no console do Glue
Monitoramento do EMR: : Se o cluster está ocioso sem trabalho ativo : Proporção de containers aguardando por recursos insuficientes A interface do YARN ResourceManager mostra o progresso individual dos jobs
Monitoramento do Redshift: : Contagem atual de conexões , : Latência de leitura e escrita em disco : Uso de CPU Os planos de execução de consultas revelam consultas lentas e seus gargalos
Kinesis IteratorAge: A métrica mais importante do Kinesis. IteratorAge é a idade em milissegundos do registro não processado mais antigo no stream. Quando esse número está perto de zero, os consumidores estão acompanhando os produtores em tempo real. Quando cresce continuamente, os consumidores estão ficando para trás — um sinal claro de que você precisa de mais capacidade de processamento.
Solução de problemas de desempenho
O que verificar quando cada serviço funciona lentamente.
Desempenho do Glue: DPU (Data Processing Unit) é a unidade de computação do Glue. Poucos DPUs significa processamento lento. Muitos desperdiça dinheiro. O número certo depende do volume de dados e da complexidade da transformação. Observe e as métricas de memória juntas para encontrar o gargalo real.
Desempenho do EMR: Quando um job é lento, verifique os tipos de instância primeiro. Jobs Spark intensivos em memória se beneficiam de instâncias otimizadas para memória (série R). Jobs intensivos em computação se beneficiam de instâncias otimizadas para computação (série C). Misturar instâncias Spot reduz custos, mas introduz risco de interrupção.
Shards do Kinesis: Quando o throughput do Kinesis atinge seu limite, o IteratorAge cresce. Cada shard lida com 1 MB/s de escrita e 2 MB/s de leitura. Quando o throughput é insuficiente, adicione mais shards através de resharding.
Cinco dimensões da qualidade de dados
A qualidade de dados não é simplesmente certo ou errado. É avaliada em múltiplas dimensões.
| Dimensão | Significado | Exemplo | |----------|-------------|----------| | Completude | Valores obrigatórios estão presentes? | Porcentagem de registros com email NULL | | Unicidade | Não há duplicatas? | Mesmo ID de pedido aparecendo duas vezes | | Validade | Os valores correspondem ao formato e intervalo esperados? | Data de 2099, idade de -5 | | Consistência | Os valores coincidem entre sistemas? | Contagem de clientes no CRM difere do warehouse | | Pontualidade | Os dados chegam quando esperado? | Dados horários chegando com 2 horas de atraso |
!5 dimensões da qualidade de dados
Regras de qualidade do DataBrew
O AWS Glue DataBrew permite definir e aplicar automaticamente regras de qualidade de dados através de uma interface visual.
Exemplos de regras: A coluna deve estar entre 0 e 150 A coluna não deve conter NULLs A coluna deve ser única A coluna deve ser uma de: "pending", "completed", "cancelled"
O DataBrew aplica essas regras ao conjunto de dados completo automaticamente e relata a porcentagem de registros que violam cada regra, junto com linhas de amostra que violam as regras. Se uma taxa de violação de regra exceder um limite, o job pode ser marcado como falho ou um aviso emitido.
Técnicas de amostragem
Inspecionar centenas de milhões de registros leva tempo e dinheiro demais. A amostragem verifica um subconjunto e o usa para estimar a qualidade do conjunto de dados completo.
Amostragem aleatória: Selecione registros aleatoriamente do conjunto de dados completo. Simples de implementar, resultados imparciais. Funciona melhor quando os dados estão distribuídos uniformemente.
Amostragem estratificada: Divida os dados em grupos (estratos) e amostre uma proporção fixa de cada grupo. Por exemplo, ao amostrar dados de pedidos por região, garanta que cada região esteja representada proporcionalmente. Mais precisa do que amostragem aleatória quando os tamanhos dos grupos diferem drasticamente.
Amostragem sistemática: Selecione cada N-ésimo registro. Por exemplo, pegue cada 100º registro de um conjunto de dados de 1 milhão. Útil quando os dados estão ordenados cronologicamente e você quer detectar padrões periódicos.
Desvio de dados (Data Skew)
O desvio de dados ocorre quando os dados são distribuídos de forma desigual entre nós ou partições em um sistema de processamento distribuído. A maioria dos nós termina rapidamente, mas todo o job aguarda o nó sobrecarregado.
Exemplo: Ao agregar dados de pedidos por ID de cliente no Spark, se um grande cliente empresarial tem milhões de pedidos enquanto todos os outros têm dezenas, essa partição fica sobrecarregada.
Soluções para desvio: Salting: Adicionar um sufixo aleatório a chaves com desvio para espalhá-las entre múltiplas partições Reparticionamento: Ajustar a contagem de partições usando ou Broadcast joins: Replicar uma tabela pequena em cada nó para eliminar o join com shuffle dispendioso
Pontos-chave do exame
"Coletar métricas de serviços AWS e configurar alarmes" → CloudWatch "Consultar erros específicos em logs" → CloudWatch Logs Insights "Detectar atraso do consumidor do Kinesis" → Métrica IteratorAge "Job do Glue processa lentamente" → Ajustar número de DPUs "EMR ficando sem memória" → Mudar para instâncias otimizadas para memória "Throughput do Kinesis insuficiente" → Adicionar mais shards "Verificar dados por NULLs e valores fora do intervalo" → Regras de qualidade do DataBrew "Dados demais para inspecionar completamente" → Usar amostragem "Alguns nós sobrecarregados no processamento distribuído" → Data Skew