Como você testa qualidade de dados em um pipeline, e o que você testa?

Teste schema, volume e semântica. Testes de schema pegam mudanças de tipo e de coluna. Testes de volume e frescor pegam uma partição que chegou vazia ou atrasada. Testes semânticos garantem unicidade das chaves, campos obrigatórios não nulos, valores aceitos em enums, integridade referencial entre fato e dimensão e invariantes de negócio, como receita nunca ser negativa. Rode tudo dentro do pipeline e falhe ou coloque em quarentena, em vez de publicar em silêncio.

Eu penso em três camadas. Schema: a coluna existe, o tipo não mudou, nenhum campo novo aceitando nulo apareceu em silêncio. Volume e frescor: esta partição tem uma contagem de linhas dentro de uma faixa razoável da média recente, e o evento mais recente não tem oito horas. Semântica: a chave primária é única, os campos obrigatórios não são nulos, o status está no conjunto aceito, todo pedido referencia um cliente que existe e a receita não é negativa. No dbt, a maior parte disso são testes nativos mais um punhado de testes SQL pontuais para regras de negócio. A parte que importa mais do que os testes é a política. Um teste de unicidade que falha na chave primária bloqueia os marts seguintes, porque publicar receita duplicada é pior do que não publicar nada. Um aviso leve, como uma queda de 20% na contagem de linhas, alerta o time dono, mas não interrompe a execução. E as linhas ruins vão para uma tabela de quarentena com o motivo da falha, para que a gente consiga medir com que frequência isso acontece em vez de perder a evidência.