Qualidade de dados é o quanto você pode confiar num número na hora de agir sobre ele. Um conjunto de dados tem boa qualidade quando é preciso (reflete a realidade), completo (sem registros faltando), atual (recente o bastante para importar), consistente (a mesma coisa significa o mesmo em todo lugar), válido (os valores estão nos formatos e faixas esperados) e único (sem duplicatas distorcendo as contagens). A maioria dos times descobre problemas de qualidade só depois que um número errado já afetou uma decisão.
Por que problemas de qualidade ficam invisíveis
Dashboard não te avisa quando o dado quebra. As queries continuam rodando. Os números continuam aparecendo. A única diferença é que esses números estão silenciosamente errados.
O padrão típico de falha: um pipeline trava às 2h da manhã, uma tabela enche de nulos, uma métrica dobra sem aviso — e o dashboard não reporta nada incomum, porque dashboard espera alguém olhar. O time toma uma decisão de produto na segunda com números que quebraram na sexta. A descoberta vem de um stakeholder, não de um monitor.
Segundo o Gartner, má qualidade de dados custa às organizações em média US$ 12,9 milhões por ano. A maior parte não é custo de limpeza — é o efeito cascata: decisões erradas, horas de engenharia desperdiçadas e dashboards que perdem credibilidade até ninguém mais confiar neles.
A solução não é mais checagem manual. É tratar qualidade de dados como times de software tratam confiabilidade de aplicação: monitoramento automatizado contra um baseline aprendido, não uma planilha de spot checks na sexta à tarde.
As seis dimensões da qualidade de dados
Seis dimensões capturam as diferentes formas em que dado pode falhar com você. Entender cada uma torna as escolhas de monitoramento claras.
1. Precisão
Precisão mede se o dado reflete o evento real que representa. Uma tabela de pedidos com data de entrega em 1970 está imprecisa. Uma linha de receita com valor negativo por erro está imprecisa. Precisão é a dimensão mais difícil de monitorar automaticamente — exige comparar os dados com uma fonte externa de verdade, que a maioria dos pipelines não tem disponível.
2. Completude
Completude mede se todos os registros e campos esperados estão presentes. Uma tabela de eventos que carregou 200 linhas em vez das 10.000 usuais está incompleta. Um registro de cliente sem e-mail está incompleto. Completude está diretamente ligada à taxa de nulos — o percentual de linhas onde um campo está vazio. Uma coluna normalmente 2% nula que salta para 40% de nulos é uma falha de completude.
3. Atualidade
Atualidade dos dados mede o tempo desde a última vez que uma tabela recebeu dados — e se esse intervalo é normal. Uma tabela que atualiza de hora em hora mas não muda há um dia está velha, mesmo que cada linha esteja individualmente correta. Dado velho é perigoso exatamente porque nada parece quebrado: o dashboard carrega, os números estão lá, só estão desatualizados.
4. Consistência
Consistência mede se o mesmo fato significa o mesmo em todo lugar em que aparece. Um cliente marcado como "ativo" no CRM mas "churned" no sistema de cobrança está inconsistente. Um ID de produto aparecendo em três formatos diferentes em três tabelas está inconsistente. Falhas de consistência produzem o problema clássico: três dashboards, três números de receita diferentes, e uma reunião gasta discutindo qual está certo.
5. Validade
Validade mede se os valores estão dentro dos formatos e faixas esperados. Um campo de CEP contendo texto livre é inválido. Uma coluna de percentual com valor 340 é inválida. Falhas de validade costumam vir de bugs de transformação ou mudanças de API onde o tipo ou formato de um campo muda sem o sistema downstream ser atualizado.
6. Unicidade
Unicidade mede a ausência de registros duplicados. Uma carga duplicada que insere as mesmas 10.000 linhas duas vezes passa em todas as outras checagens — o dado está preciso, completo, atual, consistente e válido — mas os totais das métricas estão errados por exatamente 2×. Falhas de unicidade são as mais fáceis de ignorar e estão entre as mais destrutivas para a precisão dos relatórios.
O checklist de monitoramento de qualidade de dados
Esta tabela mapeia cada dimensão para uma checagem específica, um sinal de alerta e a frequência de monitoramento adequada para a maioria das tabelas de produção. Ajuste os thresholds ao padrão dos seus dados.
| Dimensão | O que checar | Sinal de alerta | Frequência |
|---|---|---|---|
| Atualidade | Minutos desde a última linha inserida | Intervalo > 2× o ritmo normal de atualização | A cada hora |
| Completude / Volume | Contagem de linhas vs. baseline histórico | ±30% da contagem esperada para aquela janela | A cada hora |
| Taxa de nulos | % nulo em colunas-chave | Salto > 5 pontos percentuais acima do normal | A cada 2–4 horas |
| Consistência | Mesmo ID de entidade presente em tabelas relacionadas | Taxa de mismatch > 0,1% | Diária |
| Validade | Valores dentro da faixa ou formato esperados | Qualquer contagem de linhas fora do range > 0 | Diária |
| Unicidade | Taxa de duplicata na chave primária | Qualquer duplicata > 0 | Após cada carga |
A parte difícil do checklist não é saber o que checar — é saber o que é "normal". Uma contagem de linhas que parece baixa num domingo é esperada. Uma tabela que fica quieta às 3h da manhã pode ser uma janela de manutenção. Um baseline aprendido que considera o ritmo por dia da semana e por hora é o que separa alertas úteis do ruído que você aprende a ignorar.
Exemplo antes e depois
Um time de produto de uma fintech monitora usuários ativos semanais para a revisão de segunda-feira. O pipeline de eventos roda todo dia à noite.
Sem monitoramento: Na sexta às 23h, uma mudança de schema a montante faz a coluna user_id na tabela events ficar nula em 68% das linhas. O pipeline finaliza sem erro. O dashboard mostra 12.400 WAU — igual à semana passada, porque o segmento não-nulo parece consistente. Na segunda de manhã, a liderança corta R$ 200 mil do orçamento de aquisição citando "engajamento estagnado." Às 14h, um engenheiro percebe o pico de nulos ao construir um relatório não relacionado. Três dias de dado errado já tinham dirigido a decisão de budget.
Com monitoramento: Um alerta no Slack dispara às 23:05: "events.user_id taxa de nulos saltou de 2% → 68% — 3× o baseline de sexta à noite. Causa provável: mudança de schema ou mudança no formato da API. Query de diagnóstico em anexo." O engenheiro de plantão resolve antes do fim de semana. A reunião de segunda usa o número correto de 12.400 WAU e a decisão de budget é tomada com dado preciso.
A diferença não é a habilidade do time. É se o monitoramento existia para expor o problema em minutos, não em 72 horas.
Erros comuns que os times cometem
- Thresholds fixos em vez de baselines. "Alertar se contagem de linhas < 1.000" dispara todo domingo durante o vale esperado do fim de semana. Os times aprendem a dispensar o alerta — até que um problema real dispara e é dispensado junto. Baselines aprendidos que consideram o ritmo por dia da semana eliminam isso.
- Spot checks manuais no calendário. Checagens na segunda de manhã não pegam problemas que aconteceram no sábado e já foram consumidos pelos relatórios automáticos de domingo. Monitoramento precisa ser contínuo.
- Tratar qualidade de dados como problema só do time de dados. A maioria das falhas origina na camada de aplicação (um campo de formulário para de salvar), na camada de pipeline (um join produz nulos) ou na camada de infraestrutura (uma mudança de schema não é comunicada). Esperar o data engineer notar é esperar tempo demais.
- Monitorar tabelas mas não métricas. Uma métrica como Usuários Ativos Diários pode parecer saudável no nível da tabela mas estar errada no nível da métrica — porque a coluna nula excluiu exatamente os usuários que deveriam ser contados. Monitoramento de métricas de negócio pega o que monitoramento de tabelas não vê.
- Não checar unicidade após cargas. Cargas duplicadas são silenciosas. O dado passa em todas as outras checagens — exceto nessa, que costuma ser a última a ser adicionada.
Como começar sem um time de dados
Você não precisa de um data engineer para começar com monitoramento de qualidade de dados. O setup mínimo viável:
- Conecte somente-leitura. Crie um papel de banco com permissão somente-leitura. Monitoramento é observação — não é necessário permissão de escrita.
- Escolha cinco tabelas críticas. As tabelas que alimentam suas métricas de negócio principais: receita, usuários ativos, pedidos, cadastros. Comece aqui, não em tudo ao mesmo tempo.
- Deixe o baseline se formar. Dê 7 a 14 dias de dados antes de confiar nos alertas de anomalia. O baseline precisa de histórico suficiente para entender o ritmo semanal.
- Defina uma métrica de negócio. O número que você revisa toda segunda-feira. Defina uma vez — "Usuários Ativos Diários =
user_ids distintos emeventsondeevent_date= hoje" — e monitore tanto o valor da métrica quanto a tabela que a alimenta. - Roteie os alertas para onde o time já está. Slack, e-mail ou PagerDuty. Um alerta que exige login em uma ferramenta separada é ignorado.
Veja como está a qualidade dos seus dados hoje — o diagnóstico gratuito de 2 minutos dá uma nota A–F em todas as seis dimensões, sem necessidade de cadastro. Ou compare as ferramentas de monitoramento disponíveis em 2026 para encontrar a que melhor se encaixa no seu stack.
Perguntas frequentes
O que é qualidade de dados em termos simples?
Qualidade de dados é o quanto você pode confiar num número quando vai usá-lo. Dado de boa qualidade é preciso (reflete o que realmente aconteceu), completo (sem linhas ou colunas faltando de forma inesperada), atual (recente o bastante para ser relevante), consistente (o mesmo fato significa o mesmo em todo lugar), válido (os valores estão nos formatos e faixas esperados) e único (sem registros duplicados inflando as contagens). A parte difícil não é a definição — é perceber quando escorrega.
Quais são as seis dimensões da qualidade de dados?
As seis dimensões mais usadas são precisão, completude, atualidade (freshness), consistência, validade e unicidade. Cada uma captura um modo diferente de falha: atualidade pega pipelines parados, completude e taxa de nulos pegam registros faltando, validade pega erros de formato, consistência pega definições divergentes e unicidade pega cargas duplicadas. A maioria dos incidentes reais envolve pelo menos duas dimensões simultaneamente.
Como medir qualidade de dados na prática?
Você mede com checagens específicas por dimensão: taxa de nulos (percentual de valores em branco em colunas-chave), lag de atualidade (tempo desde a última atualização da tabela), anomalia de contagem de linhas (volume em relação ao baseline histórico), taxa de duplicata na chave primária e checagens de faixa de valores em colunas numéricas. O sinal mais útil é a velocidade de detecção — quanto tempo leva para um problema ser identificado após ocorrer.
Qual a diferença entre qualidade de dados e observabilidade de dados?
Qualidade de dados é a propriedade — o quanto os dados são confiáveis num ponto no tempo. Observabilidade de dados é a prática de monitorar essa propriedade continuamente, para que os problemas apareçam em minutos em vez de dias. Qualidade de dados é o objetivo; observabilidade é como você o mantém em produção sem precisar que um stakeholder avise que algo está errado.
Dá para monitorar qualidade de dados sem um time de dados?
Sim. As checagens principais — atualidade, anomalias de contagem de linhas, taxa de nulos, mudança de schema — rodam automaticamente contra uma conexão somente-leitura e não exigem que você escreva SQL ou seja dono de nenhum pipeline. Um time de dados amplia o que você pode monitorar — mas não é pré-requisito para começar a pegar os problemas que mais importam.