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

Objetivo

Detectar, na tabela em que o problema ocorreu, uma carga incompleta, atrasada, duplicada ou sem chaves — dentro de um intervalo de tempo e antes que alguém construa um relatório em cima dela.

Pré-requisitos

Cada tabela tem uma granularidade declarada (o que uma linha representa) e uma coluna de data de carga ou uma partição. A documentação do dbt modela uma verificação como um SELECT que devolve os registros com erro — zero linhas significa que passou — e traz os testes genéricos not_null, unique, accepted_values e relationships; para fontes, a atualidade pode ser configurada com loaded_at_field e os limiares warn_after e error_after. Quem trabalha sem dbt escreve as mesmas quatro regras como SQL no próprio agendador; no próprio banco de dados, as constraints NOT NULL, UNIQUE e FOREIGN KEY documentadas pelo PostgreSQL cobrem parte disso de forma permanente.

Passos

1. Atualidade: para cada fonte, anote a cadência de carga esperada, defina um limiar de aviso um pouco acima dela e um limiar de erro no ponto em que o relatório a jusante passaria a estar errado; compare max(geladen_am) com o relógio no momento da execução.
2. Volume: compare o número de linhas do intervalo recém-carregado com os mesmos intervalos de períodos anteriores (em cargas diárias, o mesmo dia da semana); guarde as contagens numa pequena tabela de histórico, comece com uma faixa larga e estreite-a após algumas semanas de observação.
3. Nulos: aplique NOT NULL a chaves primárias e estrangeiras, ao tempo de partição e às métricas que os relatórios somam; para atributos opcionais, acompanhe em vez disso a taxa de nulos ao longo do tempo.
4. Unicidade: as colunas da granularidade têm de ser únicas. Um duplicado é uma repetição da fonte, um join que multiplicou linhas ou uma reexecução que acrescentou dados em vez de os substituir.
5. Ordem: execute as verificações depois da carga e antes do passo que torna a tabela visível (troca de view, liberação de partição), para que uma falha no nível «error» interrompa a publicação e «warn» apenas notifique.
6. Guarde cada resultado, inclusive os que passaram, com carimbo de data/hora, e encaminhe as falhas, com as linhas afetadas, ao responsável pela tabela; assim, verificações instáveis tornam-se visíveis.

Resultado esperado

Uma carga que chega tarde, pela metade, em duplicado ou com chaves perdidas é reportada no ponto onde o problema ocorreu, antes de se propagar.

Limites e base de verificação

As quatro verificações encontram falhas estruturais, não valores errados mas bem formados; as reconciliações com o sistema de origem (os totais coincidem) vêm a seguir. Faixas de volume sem conhecimento de sazonalidade disparam em todos os feriados. O conjunto é uma proposta baseada na documentação citada; não se afirma nenhuma taxa de detecção.