Data Quality Monitoring em Pipelines — O Lado Invisível dos Dados Quando um pipeline de dados falha, você sabe. Recebe um erro no Slack, o log pisca vermelho, você acorda e investiga. Mas quando um pipeline roda perfeitamente e insere 40 mil linhas duplicadas? Ninguém sabe. Até o CEO notar que os números não batem. O Problema Invisível: Technical Health vs Data Health A maioria dos data engineers monitora apenas uma coisa: o pipeline executou sem erro? Existem duas qualidades diferentes que ninguém fala: 1. Technical Health: O pipeline executou? As máquinas estão em pé? 2. Data Health: Os dados estão realmente certos? Têm a qualidade que esperamos? Um pode ser perfeito enquanto o outro desaba silenciosamente. As 4 Métricas Invisíveis que Profissionais Monitoram Um data engineer sênior não apenas deixa o pipeline rodar. Ele coloca sensores para detectar problemas antes do CEO descobrir: 1. Volume — "Quantas linhas deveriam ter chegado?" Desvio de 5% é pequeno? Não. Se você espera 50 mil e chega 47 mil, algo aconteceu. Pode ser perda de dados, conexão interrompida, ou filtro acidental. Implicação real: Relatório de faturamento fica incompleto. Decisões erradas são tomadas com 6% menos dados. E ninguém sabe. 2. Valores Nulos — "Em que colunas os dados estão faltando?" Nulos acontecem. Código SQL retorna NULL quando não encontra valor. Isso é normal. Mas quando 45% de uma coluna vira NULL do nada? Significa que algo quebrou upstream. Um join falhou. Uma API caiu. Um formato de dados mudou. Implicação real: Medidas baseadas em ficam completamente erradas. Você não sabe por quê. 3. Ranges — "Os valores estão dentro do esperado?" Este é o check mais simples e mais poderoso. Você sabe qual é a idade mínima de seus usuários? Qual é a data máxima de um evento? Se um valor sair do range esperado, é como um código de barras no checkout de supermercado: algo virou errado, investiga. Implicação real: Usuários com idade -50 anos, transações de 1 milhão de reais sem motivo aparente. Essas anomalias destroem relatórios. 4. Integridade Referencial — "As chaves estrangeiras realmente existem?" cliente_id Em SQL, você pode ter uma foreign key quebrada. Significa: Uma venda aponta para um cliente que não existe Um pedido aponta para um produto que foi deletado Uma transação aponta para uma conta encerrada Esses "registros órfãos" não geram erro. Apenas ficam lá, quebrando joins e relatórios silenciosamente. Implicação real: Dashboard mostra vendas de "Cliente ID 999999", mas esse cliente não existe. Relatório fica inconsistente. Implementação Prática — O Mínimo que Funciona Não precisa ser complexo. Aqui está o script de data quality que eu recomendo para começar: Integre este script na sua pipeline. Rode todo dia de manhã. Quando uma métrica piscar vermelho, você acorda ANTES que o CEO vire a mesa. A Realidade da Data Quality Data Quality é invisível quando está tudo certo. É visível quando tudo vai pelo ralo. Profissionais junior: "Como assim a métrica tá errada? O pipeline rodou sem erro!" Profissionais sênior: "Vamos checkar volume, nulos, ranges e integridade referencial primeiro." A diferença entre receber um email de alerta às 4am (e resolver tranquilo) vs receber uma ligação do CEO às 9am (em pânico) é simplesmente: você monitorou data quality ou não. Próximos Passos 1. Liste as 3 colunas mais críticas do seu pipeline 2. Defina o range esperado para cada uma 3. Implemente o check mínimo acima 4. Configure um alerta por email quando algo sair do esperado Não é complexo. Mas salva carreiras. Quer aprofundar em Data Engineering completo, com pipelines, monitoring e produção? Na Elite Data Academy você aprende a construir pipelines sólidos que não quebram silenciosamente.