O Que É Dados Inconsistentes

O que é dados inconsistentes e por que ele estraga seus relatórios

Dados inconsistentes são registros que deveriam seguir um padrão ou regra lógica e não seguem. Pode ser um campo numérico que recebeu texto, uma data de nascimento posterior à data de registro, ou um código de produto que existe em um sistema mas não no outro. O problema não é apenas estético. Ele quebra integrações, distorce dashboards e faz consultas retornarem resultados que ninguém entende.

o que é dados inconsistentes

A definição técnica é simples: inconsistência ocorre quando a informação viola constraints de integridade do domínio ou do esquema. Na prática, eu vejo isso acontecer de três formas recorrentes. Primeira, quando múltiplas fontes alimentam a mesma tabela e cada uma usa uma convenção diferente para o mesmo campo. Segunda, quando transformações etl aplicam lógica condicional incompleta e deixam valores órfãos. Terceira, quando dados históricos são editados manualmente sem auditoria e alguém atualiza um campo sem refletir a mudança nos relacionamentos dependentes. Eu vi uma vez um relatório de faturamento que apresentava R$ 12 milhões a menos que o esperado. A causa raiz era um campo de código de município que, em 347 registros, continha o valor "99999" usado como placeholder durante uma migração antiga. Esse placeholder escapou das regras de validação porque a constraint checara apenas se o campo era numérico, não se o número pertencia ao cadastro oficial do IBGE. A correção foi cruzar a tabela com uma fonte externa de municípios, mapear os 99999 e substituir pelos códigos reais. Demorou quatro horas de investigação e doze minutos de execução do script de correção. O que parece inócuo na superfície muitas vezes esconde problemas mais profundos. Dados duplicados com variações mínimas de formatação, como "João Silva" e "Joao Silva", são tratados como entidades diferentes em sistemas que não aplicam normalização prévia. Isso infla métricas de uniq usuarios e gera custos desnecessários em bancos que cobram por registro processado. Outra situação frequente é a divergência temporal: um campo de data de venda aponta para Janeiro e o campo de data de baixa aponta para Fevereiro porque um sistema registra o evento comercial e outro registra o evento contábil. Quando você agrupa por mês sem padronizar qual data usar, seu relatório de vendas mensais fica deslocado em relação à realidade financeira.

Para identificar inconsistências de forma sistemática, comece mapeando os schemas de todas as tabelas envolvidas no fluxo de dados. Anote tipos, nullable, defaults e constraints existentes. Depois, execute queries de profiling que exponham outliers. Por exemplo, para detectar valores fora de faixas esperadas: SELECT coluna, COUNT(*) FROM tabela GROUP BY coluna HAVING COUNT(*) < 5 ORDER BY COUNT(*) ASC; Isso lista os valores mais raros, que muitas vezes são os errados. Combine com validação de padrões regex para campos como CPF, CNPJ, CEP e email. Regras simples funcionam bem quando o volume é baixo. Quando o volume sobe para milhões de linhas, aí entra a questão de performance. Queries de validação full scan podem levar horas em tabelas sem particionamento adequado. Nesse cenário, eu recomendo amostragem estratificada primeiro. Pega-se uma amostra representativa, valida-se os padrões, identifica-se os padrões problemáticos e só depois roda-se a correção em lote sobre o dataset completo.

Um insight que poucos consideram é que inconsistência nem sempre vem dos dados brutos. Às vezes ela é introduzida pelas ferramentas de visualização. Ferramentas de BI aplicam agregações automaticamente e tratam nulos de formas diferentes conforme a configuração. Um gráfico pode estar ocultando registros nulos porque o filtro padrão exclui linhas com missing values. O dado não está errado. A representação está escondendo parte dele. Sempre verifique se o toolkit que você usa está filtrando, coerçando ouconvertendo algo antes de confiar no resultado final. Outro ponto negligenciado é a inconsistência semântica. Dois campos podem ter o mesmo nome e tipo, mas significar coisas diferentes em contextos distintos. "Valor total" pode significar valor com impostos em uma tabela e valor líquido em outra. Quando você junta essas duas colunas numa view sem documentação clara, o dashboard soma valores que não são comparáveis e o número final não representa nada real. A solução não é técnica. É documental. Crie um dicionário de dados com definições campo a campo e obrigue que qualquer nova ingestão passe por review contra esse dicionário antes de entrar em produção. Existem ferramentas que ajudam nesse processo. O Great Expectations permite definir suites de validação declarativas e gerar reports automáticos. O Deequ, da AWS, faz profiling e verificação de qualidade em dados Spark. O Soda Core oferece checks contínuos com alertas. Nenhuma delas resolve o problema sozinha. Elas detectam, mas não corrigem. E a correção muitas vezes exige decisão humana sobre o que é aceitável e o que não é.

Um limitação séria dessas ferramentas é que elas dependem de regras bem definidas. Se você não sabe o que é consistente no seu domínio, a ferramenta vai te dar relatórios de erros genéricos que não ajudam em nada. Eu já vi equipes implementarem Great Expectations inteiros e depois não conseguirem interpretar os falhas porque as expectativas foram copiadas de repositórios públicos sem adaptação ao contexto local. O resultado foi um pipeline que alertava sobre tudo e ninguém resolvia nada. Se o volume de inconsistências for alto e o tempo de resposta for crítico, considere adiar a correção em lotes para um job noturno em vez de validar em tempo real. Validação síncrona adiciona latência e pode derrubar pipelines inteiros durante janelas de processamento. Uma abordagem híbrida funciona melhor: validação leve na ingestão para rejeitar claramente inválidos e validação profunda em batch para corrigir casos limítrofes. A longo prazo, o que reduz inconsistência de verdade é arquitetura. Tabelas com chaves estrangeiras rigorosas, triggers de auditoria, pipelines imutáveis e governança de dados com owners responsabilizados por cada entidade. Sem isso, você passa o resto do ano caçando problemas que já poderiam ter sido impedidos na origem.