Verificações de qualidade de dados: atualidade, volume, nulos e unicidade como conjunto mínimo de testes

Objetivo

Detectar uma carga quebrada ou parcial antes que alguém construa um relatório sobre ela, com verificações baratas o bastante para rodar a cada intervalo e específicas o bastante para que uma falha indique a tabela e a regra violada.

Pré-requisitos

Cada tabela tem uma granularidade declarada (o que uma linha representa) e uma coluna ou partição com o timestamp de carga. A documentação do dbt (citada) modela uma verificação como uma instrução select que devolve os registros com falha: zero linhas significa que a asserção é válida. Por padrão, ela oferece verificações por coluna de not-null, unique, accepted-values e relationship (chave estrangeira), além de uma configuração de source freshness com os limites warn_after e error_after, calculados a partir de um loaded_at_field; se nenhum dos dois limites for informado, a atualidade não é calculada. As mesmas quatro regras podem ser escritas como SQL puro em qualquer agendador.

Passos

1. Atualidade: para cada tabela de origem, registre a cadência de carga esperada e defina um limite de aviso ligeiramente acima dela e um limite de erro no ponto em que o relatório downstream passaria a estar errado. Compare max(loaded_at) com o relógio no momento da execução.
2. Volume: para o intervalo recém-carregado, conte as linhas e compare com o mesmo intervalo de períodos anteriores (o mesmo dia da semana, no caso de cargas diárias). Guarde as contagens em uma pequena tabela de histórico e sinalize as contagens fora de uma faixa definida a partir desse histórico; comece com uma faixa larga e estreite-a após algumas semanas de observação.
3. Nulos: assegure not-null nas chaves primárias e estrangeiras, no timestamp usado para particionamento e nas métricas que os relatórios somam. Não assegure not-null em atributos opcionais; em vez disso, acompanhe a taxa de nulos deles ao longo do tempo.
4. Unicidade: assegure que as colunas que formam a granularidade sejam únicas. Uma duplicata aqui vem de uma nova tentativa (retry) na origem, de um join que multiplicou linhas ou de uma reexecução que acrescentou dados em vez de substituí-los.
5. Posicione as verificações após a carga e antes da etapa que publica a tabela para os consumidores (troca de view, promoção de partição), de modo que uma verificação de nível de erro com falha interrompa a publicação.
6. Encaminhe cada falha ao responsável pela tabela, com as linhas com falha anexadas, e registre todos os resultados, inclusive os sucessos, para que seja possível identificar verificações instáveis.

Resultado esperado

Uma carga que chega atrasada, pela metade, duplicada ou com chaves perdidas é reportada na tabela que quebrou, dentro de um intervalo de agendamento, antes de se propagar.

Limites e base de verificação

Essas verificações encontram quebras estruturais, não valores errados mas bem formados; as verificações de regras de negócio (os totais conferem com o sistema de origem) vêm em seguida. As faixas de volume precisam levar em conta a sazonalidade, ou vão disparar alertas em todo feriado. O conjunto é um protocolo proposto, derivado da documentação citada; nenhuma taxa de detecção é afirmada.