Testes de Qualidade de Dados: Guia para Analytics

Como impedir que dados inconsistentes cheguem ao BI

Testes de qualidade de dados são verificações executáveis que confrontam um conjunto de registros com regras explícitas: quais campos precisam existir, o que identifica uma ocorrência, quais relações são válidas e até quando a informação deve estar disponível. Para implementá-los, comece por um indicador importante, documente suas regras, automatize as verificações e defina o que acontece quando elas falham.

Um pipeline terminar sem erro não prova que os dados estão corretos. A carga pode executar normalmente e entregar pedidos duplicados, uma filial ausente ou valores calculados com a regra errada. Também não basta ter muitos testes: uma regra mal definida pode aprovar um resultado inadequado.

Este guia apresenta uma proposta prática para pipelines ETL e ELT, responsáveis por extrair, carregar e transformar dados. Os exemplos são hipotéticos, não resultados de clientes. O foco é transformar validações em controles operacionais, complementando o panorama de Business Intelligence para empresas.

Primeiro, defina o que significa um dado utilizável

Qualidade depende do uso. Uma base suficiente para analisar vendas mensais pode ser inadequada para uma decisão de estoque que exige atualização frequente. O Government Data Quality Framework trata a adequação à finalidade e as necessidades dos usuários como elementos centrais; é uma referência conceitual, não uma obrigação regulatória brasileira.

Antes de programar, registre:

• Qual decisão ou indicador depende do conjunto de dados.
• O que cada linha representa, isto é, sua granularidade.
• A chave que identifica essa ocorrência.
• A origem responsável e o responsável de negócio pela regra.
• A janela de processamento, o fuso horário e as exceções previstas.
• A consequência de publicar informação incompleta ou incorreta.

Considere uma tabela de itens de pedidos. O número do pedido, isoladamente, não deve ser único: um pedido pode ter vários itens. Se empresas diferentes reutilizam números, a identificação pode exigir empresa, pedido e item. Testar apenas o pedido produziria falsos alarmes; ignorar a empresa poderia misturar operações distintas.

Essa definição faz parte da modelagem de dados e dos pipelines de analytics. Nenhuma ferramenta de testes consegue decidir sozinha qual é a granularidade correta para o negócio.

Testes de qualidade de dados: quais verificações priorizar

A matriz abaixo é um ponto de partida para o exemplo de pedidos. As regras devem ser aprovadas para o processo real, não copiadas como padrões universais.

Não imponha “valor sempre positivo” indiscriminadamente: devoluções e ajustes podem ser negativos por definição. Prefira regras associadas ao tipo da operação.

Validade também não equivale a exatidão. Um código pode ter formato correto e apontar para o produto errado. Por isso, verificações automáticas devem ser combinadas com reconciliações e revisão do significado dos dados.

Diferencie teste unitário, teste de dados e monitoramento

Um teste unitário verifica a lógica de transformação usando entradas controladas e resultados esperados. Por exemplo: fornecer um pedido com desconto e uma devolução para conferir o cálculo líquido. A documentação de testes unitários do dbt descreve essa validação com pequenos conjuntos estáticos antes da materialização completa do modelo.

Já um teste de dados examina os registros disponíveis naquela execução. A regra pode estar correta, mas o fornecedor ter enviado um arquivo duplicado hoje. Entradas sintéticas não revelariam esse incidente.

O monitoramento acompanha a operação ao longo do tempo: atrasos, volumes, duração das validações e reincidência de falhas. Ele ajuda a perceber desvios que não cabem em uma regra binária simples.

Essas três abordagens se complementam. Um teste aprovado ontem não certifica a carga de hoje; uma carga atual não comprova que a fórmula do indicador está certa.

Exemplo SQL: localizar chaves nulas e duplicadas

A consulta abaixo utiliza uma tabela fictícia chamada staging_pedidos. Ela procura problemas na chave composta de um lote específico e não altera registros.

select
  empresa_id,
  pedido_id,
  numero_item,
  count(*) as ocorrencias
from staging_pedidos
where lote_id = 'carga-exemplo-001'
group by empresa_id, pedido_id, numero_item
having empresa_id is null
    or pedido_id is null
    or numero_item is null
    or count(*) > 1;

O agrupamento preserva a separação entre empresas, pedidos e itens. Uma combinação duplicada aparece com contagem superior a um; uma chave incompleta aparece mesmo se houver apenas uma ocorrência.

Para validar o próprio teste, prepare registros artificiais com uma duplicata, um item nulo e combinações legítimas de outras empresas. Confirme que somente os casos esperados são sinalizados.

Existem dois limites importantes:

1. Se o lote não existir ou estiver vazio, a consulta também retornará zero linhas. É necessário um controle separado para verificar chegada e completude da carga.
2. A consulta não procura colisões com lotes anteriores. Antes de incorporar os dados ao destino, compare as chaves com o histórico e considere a política de atualização ou versionamento.

Uma duplicata dentro do lote e o reenvio legítimo do mesmo registro são situações diferentes. A construção de software e integrações sob medida deve prever identificação de eventos e reprocessamento sem efeitos indevidos, além das validações analíticas.

Atualização e reconciliação precisam de contexto

Freshness não é apenas o horário da última execução

Separe o momento do evento de negócio, a atualização na origem e a ingestão no ambiente analítico. Copiar novamente um arquivo antigo pode gerar uma ingestão recente sem trazer informação nova.

Também não confie apenas no registro mais recente da tabela. Uma filial atualizada pode esconder outras atrasadas. Quando a decisão depende dessas divisões, avalie a atualização por origem ou partição relevante.

No dbt, dbt build não inclui automaticamente a verificação de freshness das fontes. A documentação oficial de source freshness orienta configurar essa checagem separadamente. Sua posição no fluxo e o tratamento da falha precisam refletir a política de publicação.

Compare conjuntos equivalentes

Uma reconciliação útil compara origem e destino com a mesma definição: empresa, moeda, status, intervalo de datas e horário de corte. Registre quais filtros foram aplicados.

Um total geral igual pode esconder erros que se compensam. Combine contagens, totais por segmentos e verificação de chaves ausentes ou inesperadas. Quando houver tolerância por arredondamento, documente a razão e a unidade; não escolha um percentual genérico para fazer o teste passar.

Dados atrasados exigem uma janela de aceitação. Diferencie um período ainda aberto de um período fechado e estabeleça como ajustes posteriores serão reaplicados e conferidos.

Ao falhar, alertar, isolar ou bloquear?

A resposta deve acompanhar o impacto. Esta é uma proposta de decisão operacional, não uma configuração automática de qualquer ferramenta.

Alertar

Adequado para um desvio ainda sob investigação ou uma regra não crítica. O alerta precisa de responsável, prazo e registro do impacto. Avisos recorrentes sem ação tendem a perder utilidade.

Isolar registros

Pode funcionar quando é possível separar os registros inválidos sem comprometer a interpretação do restante. Mantenha os dados originais, o motivo da rejeição e um caminho de correção.

Não descarte itens silenciosamente: remover linhas problemáticas pode subestimar um indicador. Quando a incompletude inviabiliza a decisão, isolar não substitui bloquear.

Bloquear a atualização

Considere impedir a publicação do conjunto afetado quando uma regra crítica falhar. Evite interromper processos independentes por padrão; mapeie quais tabelas e relatórios realmente dependem da carga.

Uma abordagem possível é validar uma versão candidata antes de torná-la visível aos consumidores. Manter temporariamente a última versão aprovada exige informar sua data e o atraso; em alguns usos, sinalizar indisponibilidade é mais seguro que exibir informação antiga.

O tratamento precisa incluir o caso em que o próprio teste não consegue executar. Erro de consulta, falta de permissão e tempo esgotado não são aprovação de qualidade.

Como escolher ferramentas sem complicar o projeto

Para um fluxo pequeno, consultas SQL versionadas e executadas pelo orquestrador existente podem ser suficientes, desde que resultados, falhas e responsabilidades sejam registrados.

Em projetos centrados em transformações SQL, o dbt oferece testes de dados para nulidade, unicidade, valores aceitos e relacionamentos, além de regras personalizadas. Escolha as verificações conforme o modelo, não apenas porque estão disponíveis.

Para fluxos programáticos, o Great Expectations Core organiza verificações em Expectations e conjuntos de regras, executados sobre lotes de dados. Seus Checkpoints podem associar validações a ações de processamento dos resultados.

Nenhuma dessas escolhas dispensa avaliar compatibilidade com as fontes, versões, autenticação, custo de execução e capacidade de manutenção. Defina primeiro onde a validação deve acontecer e como a falha será tratada; depois selecione a implementação.

Um roteiro para colocar os controles em produção

1. Escolha um conjunto crítico. Comece por uma tabela e pelos indicadores que ela alimenta. Documente impacto, granularidade e responsáveis.
2. Observe o comportamento atual. Examine ciclos completos do negócio e ocorrências conhecidas. Um histórico com erros não deve virar referência automática de normalidade.
3. Versione regras e exemplos. Guarde a consulta, a justificativa, o resultado esperado e casos artificiais que devem falhar.
4. Execute sem bloqueio quando for seguro. Calibre regras novas e investigue alarmes. Isso não justifica liberar dados sabidamente inadequados para usos críticos.
5. Integre os controles ao fluxo. Teste mudanças de transformação antes da entrega e valide os dados reais em cada carga relevante.
6. Ensaie a recuperação. Simule arquivo ausente, duplicata e atraso. Confirme quem recebe o aviso, o que deixa de atualizar e como reprocessar.
7. Revise após mudanças. Novas filiais, regras comerciais ou sistemas de origem podem alterar o que é considerado válido.

Em bases grandes, execute verificações locais nas partições alteradas quando isso preservar a cobertura necessária. Complemente com controles globais para propriedades como unicidade histórica. Amostragem reduz trabalho, mas não prova ausência de falhas raras; explicite essa limitação.

Registre evidências que permitam agir

Cada execução deve identificar regra e versão, conjunto avaliado, lote ou janela, quantidade examinada, falhas encontradas, duração e responsável. Diferencie falha de qualidade, falha técnica e teste não executado.

Evite enviar registros pessoais completos para canais de alerta. Prefira contagens e identificadores controlados, com detalhes em ambiente de acesso restrito.

Relacione a falha aos consumidores afetados. Essa conexão aproxima a validação da observabilidade de sistemas: o objetivo não é acumular sinais, mas localizar o problema e orientar a recuperação.

Conclusão: confiança exige regras e resposta

Testes de qualidade de dados funcionam melhor quando combinam regras de negócio claras, cobertura dos dados reais e uma resposta definida para cada falha. Comece pelo que pode comprometer decisões, valide os próprios testes e torne visíveis as limitações da informação publicada.

Se sua empresa precisa estruturar essas verificações nos pipelines ou revisar dados que alimentam o BI, converse com a Mattos Tech Solutions sobre o contexto das fontes, dos indicadores e da operação.