Como testar a qualidade dos dados em ELT: passo a passo

Num pipeline ELT, os dados são primeiro carregados no data warehouse e só depois transformados. Essa ordem traz velocidade, mas também um risco: os dados em bruto entram sem validação, por isso um valor nulo ou um registo duplicado pode viajar até aos relatórios sem ninguém reparar. Testar a qualidade dos dados em ELT com queries SQL simples resolve este problema — cada teste corre depois da carga e falha assim que encontra algo fora do esperado, antes de os dados serem consumidos.

Pré-requisitos

• Acesso a um data warehouse SQL (Snowflake, BigQuery, PostgreSQL, SQL Server, entre outros).
• Uma tabela já carregada pelo processo ELT — neste exemplo, stg_encomendas.
• Noções básicas de SQL: SELECT, WHERE, GROUP BY e COUNT.

Passo 1: Definir as regras de qualidade

Antes de escrever qualquer código, decida o que significa "dados válidos" para a sua tabela. Escrever as regras por palavras torna-as fáceis de rever com a equipa de negócio. Para stg_encomendas vamos usar quatro regras muito comuns:

• Não nulo: a coluna id_encomenda nunca pode estar vazia.
• Único: não podem existir duas linhas com o mesmo id_encomenda.
• Valores aceites: a coluna estado só pode ser 'nova', 'paga' ou 'cancelada'.
• Frescura: deve existir pelo menos uma encomenda das últimas 24 horas.

A ideia central é sempre a mesma: cada teste é uma query que devolve as linhas que violam a regra. Se a query devolver zero linhas, o teste passa; se devolver linhas, essas linhas são exatamente os problemas a corrigir.

Passo 2: Testar valores nulos e duplicados

Comece pelos dois testes mais frequentes num pipeline de dados. O primeiro conta quantos id_encomenda estão nulos; o segundo procura chaves repetidas, um erro clássico quando a carga corre duas vezes.

-- Teste 1: id_encomenda não pode ser nulo
SELECT COUNT(*) AS falhas
FROM stg_encomendas
WHERE id_encomenda IS NULL;

-- Teste 2: id_encomenda tem de ser único
SELECT id_encomenda, COUNT(*) AS repeticoes
FROM stg_encomendas
GROUP BY id_encomenda
HAVING COUNT(*) > 1;

Se o Teste 1 devolver um número maior que zero, ou o Teste 2 devolver alguma linha, a carga tem um problema que deve ser investigado antes de seguir em frente.

Passo 3: Validar valores aceites e integridade

Agora garanta que a coluna estado só contém valores previstos e que cada encomenda pertence a um cliente que existe mesmo na tabela de clientes.

-- Teste 3: estado só pode conter valores da lista
SELECT DISTINCT estado
FROM stg_encomendas
WHERE estado NOT IN ('nova', 'paga', 'cancelada');

-- Teste 4: integridade referencial com a tabela de clientes
SELECT e.id_encomenda
FROM stg_encomendas AS e
LEFT JOIN stg_clientes AS c
  ON e.id_cliente = c.id_cliente
WHERE c.id_cliente IS NULL;

O Teste 3 revela estados inválidos, como um erro de escrita vindo da origem. O Teste 4 mostra encomendas com um id_cliente que não corresponde a nenhum cliente — um sinal típico de dados desalinhados entre tabelas.

Passo 4: Testar a frescura dos dados

Um pipeline pode terminar sem erros e, ainda assim, trazer apenas dados antigos. Este teste confirma que a última carga trouxe registos recentes.

-- Teste 5: tem de haver encomendas nas últimas 24 horas
SELECT COUNT(*) AS encomendas_recentes
FROM stg_encomendas
WHERE data_encomenda >= CURRENT_TIMESTAMP - INTERVAL '24' HOUR;

Aqui a lógica inverte-se: o teste falha se o resultado for zero. A sintaxe de intervalos de tempo muda entre warehouses, por isso adapte INTERVAL '24' HOUR ao seu (por exemplo, com DATEADD no SQL Server). Ajuste também a janela à frequência do seu pipeline.

Passo 5: Juntar tudo num único teste

Para automatizar, junte os testes que devolvem "linhas em falha" numa só query com UNION ALL. Cada linha do resultado passa a ser uma falha a investigar e um resultado vazio significa que está tudo bem.

SELECT 'nulo:id_encomenda' AS teste, CAST(id_encomenda AS VARCHAR) AS detalhe
FROM stg_encomendas
WHERE id_encomenda IS NULL

UNION ALL

SELECT 'estado_invalido' AS teste, estado AS detalhe
FROM stg_encomendas
WHERE estado NOT IN ('nova', 'paga', 'cancelada');

Guarde esta query como o passo final do seu ELT — por exemplo, num modelo de dbt, numa task do Airflow ou num procedimento agendado. Se devolver linhas, faça o pipeline parar ou enviar um alerta à equipa, para que ninguém construa relatórios sobre dados errados.

Verificar o resultado

Para confirmar que os testes funcionam, insira de propósito uma linha inválida e volte a correr as queries:

INSERT INTO stg_encomendas (id_encomenda, id_cliente, valor, data_encomenda, estado)
VALUES (NULL, 10, 25.0, CURRENT_TIMESTAMP, 'expedida');

Depois desta inserção, o Teste 1 deve devolver 1 e o Teste 3 deve mostrar o estado 'expedida', que não está na lista permitida. Se isso acontecer, os testes estão a apanhar problemas como esperado. Apague a linha de teste no fim para deixar a tabela como estava.

Conclusão

Com apenas cinco queries simples passou a validar nulos, duplicados, valores aceites, integridade referencial e frescura sempre que o ELT corre, apanhando erros antes de chegarem aos relatórios. O passo seguinte é tornar estes testes parte automática do pipeline e guardar cada resultado numa tabela de histórico, para acompanhar a evolução da qualidade ao longo do tempo. Qual destas regras seria a mais crítica nos seus próprios dados?