Data Quality

O problema mais comum em projetos de dados não é falta de tecnologia, falta de budget ou falta de talento analítico. É qualidade de dados. Dashboards que mostram números contraditórios. Modelos de ML treinados em dados corrompidos que produzem previsões sistematicamente erradas. Análises baseadas em registros duplicados que inflam métricas. Decisões tomadas com base em dados que ninguém verificou se estavam corretos.

Data Quality (Qualidade de Dados) é o conjunto de dimensões, práticas e processos que garantem que os dados de uma organização são adequados para os fins a que se destinam — precisos, completos, consistentes, atuais e confiáveis o suficiente para informar decisões e alimentar sistemas com confiança.

A ênfase em "adequados para os fins" é intencional. Dados de qualidade suficiente para análise exploratória podem não ser adequados para treinamento de modelos de ML críticos. Dados adequados para relatórios gerenciais podem não ser adequados para conformidade regulatória. Qualidade de dados não é uma propriedade absoluta — é avaliada em relação ao propósito.

Acurácia: os dados refletem a realidade? O preço registrado corresponde ao preço real cobrado? A data de nascimento está correta? O endereço existe? Acurácia é a dimensão mais fundamental — dados inacurados são positivamente prejudiciais.

Completude: os dados têm todos os valores necessários? Campos obrigatórios com valores nulos, registros sem atributos-chave, tabelas com buracos. Um dataset de clientes sem email para 40% dos registros está incompleto para campanhas de e-mail — independentemente de quão acurados são os outros campos.

Consistência: os dados são representados de forma uniforme dentro de um sistema e entre sistemas diferentes? "SP", "São Paulo", "sao paulo" são inconsistentes. O cliente ID 12345 no CRM corresponde ao mesmo cliente ID 67890 no ERP? Inconsistência cria problemas em joins e análises cruzadas.

Timeliness (atualidade): os dados estão atualizados para o propósito? Um endereço atualizado há três anos pode estar desatualizado. Um preço de produto atualizado ontem é relevante para análise de hoje. O delay entre a ocorrência de um evento e sua disponibilidade para análise (data latency) é uma dimensão de qualidade.

Unicidade: há duplicatas? Registros duplicados inflam contagens, distorcem médias e contaminam modelos. Um cliente com três cadastros distintos aparece três vezes em segmentações. Uma transação registrada duas vezes dobra a receita contabilizada — erro que pode parecer crescimento.

Validade: os valores estão no formato correto e dentro dos ranges esperados? CEP com quatro dígitos em vez de oito. Data de nascimento em 1750. Valor de transação negativo em contexto onde não deveria ser. E-mail sem @. Validade é verificável por regras — é o mais fácil de automatizar.

Problemas de qualidade não surgem do nada — têm causas identificáveis.

Entrada de dados humana: formulários preenchidos por humanos introduzem erros de digitação, formatos inconsistentes e campos obrigatórios ignorados. A probabilidade de erro cresce com o número de campos e a frequência da entrada.

Sistemas sem validação: sistemas que aceitam qualquer dado sem validação na entrada permitem que dados inválidos sejam armazenados. Um campo de telefone que aceita texto livre vai ter "não tenho", "99999999999", "(11) 9 9999-9999" e "11999999999" para o mesmo conceito.

Integrações mal construídas: quando dados são copiados entre sistemas (ETL), transformações incorretas, mapeamentos errados ou falhas silenciosas produzem dados corrompidos no destino sem indicação de erro.

Schema evolution sem migração: quando o significado de um campo muda ao longo do tempo mas os dados históricos não são atualizados. "Status = 1" significava "ativo" antes de maio, e "pendente" depois — sem documentação, análises históricas são inconsistentes.

Falta de ownership: sem responsável claro pela qualidade de dados de um domínio, problemas não são reportados, não são priorizados e não são corrigidos.

Validação na origem: a primeira linha de defesa. Validar dados no momento da entrada — no formulário, na API, na integração — antes de armazená-los. Rejeitar dados inválidos com mensagem clara é melhor do que armazenar e corrigir depois. Regras: campos obrigatórios não são nulos, email tem formato válido, valor numérico está dentro do range, data é uma data válida.

Testes de qualidade em pipelines (dbt tests): em pipelines de dados, executar testes automáticos após cada transformação: not_null (campo nunca nulo), unique (sem duplicatas em coluna que deveria ser PK), accepted_values (campo só tem valores do enum esperado), relationships (FK referencia PK existente). Falha nos testes bloqueia a propagação de dados corrompidos.

Monitoramento contínuo: verificações automáticas periódicas sobre dados em produção: volume de novos registros está dentro do range esperado? Percentual de nulos não aumentou? Distribuição de valores não mudou abruptamente? Alertas quando anomalias são detectadas. Ferramentas: Great Expectations, Soda, Monte Carlo.

Profiling de dados: análise estatística sistemática das colunas — distribuição de valores, percentual de nulos, cardinalidade, outliers, valores mais frequentes. Profiling inicial de um novo dataset frequentemente revela problemas que ninguém sabia que existiam.

Reconciliação entre sistemas: verificar periodicamente que dados que existem em dois sistemas (CRM e data warehouse, por exemplo) são consistentes. Contagens divergem? Valores totais divergem? Divergências indicam problema na integração ou em um dos sistemas.

Em ML, problemas de qualidade de dados têm efeitos específicos e frequentemente mais graves do que em análise de BI.

Dados de treino corrompidos: modelos aprendem os padrões que existem nos dados. Dados com erros sistemáticos ensinam padrões errados ao modelo — que então replica esses erros em produção, de forma silenciosa e em escala.

Duplicatas em treino: registros duplicados no dataset de treino podem vazar informação entre treino e validação, produzindo estimativas de performance otimistas. O modelo "memorizou" exemplos em vez de aprender padrões generalizáveis.

Desequilíbrio e viés: se certos grupos ou tipos de registro são sub-representados ou têm mais erros nos dados, o modelo vai ter performance sistematicamente pior nesses grupos — perpetuando e amplificando viés.

Target leakage por dados de qualidade ruim: dados que chegam fora de ordem temporal, com timestamps incorretos, podem criar data leakage — o modelo vê informação do "futuro" durante o treinamento e parece ótimo na validação mas falha em produção.

Data quality é o investimento de dados com menor glamour e maior impacto real. Não há algoritmo de ML, ferramenta de BI ou plataforma de dados que compense dados fundamentalmente incorretos. A qualidade dos dados é o teto de qualidade de qualquer análise ou modelo construído sobre eles.

Para PMEs, o mapa de ação prático tem três prioridades: primeiro, validação na entrada dos sistemas principais (CRM, ERP, plataforma e-commerce) — é muito mais barato prevenir dado ruim do que corrigir depois; segundo, testes de qualidade nos pipelines de dados (dbt tests básicos: not_null, unique, accepted_values) — detectam problemas automaticamente antes que contaminem análises; terceiro, um processo claro de reporte e correção de problemas de qualidade, com responsável identificado por domínio.

O indicador mais confiável de maturidade em dados não é a sofisticação das ferramentas — é se os líderes confiam nos números que veem nos dashboards. Quando a primeira reação a um dado surpreendente é "isso está certo?" em vez de "o que explica isso?", o problema é de qualidade de dados — e nenhuma ferramenta nova vai resolver sem endereçar a causa raiz.