Verificações de freshness e de contagem de linhas em tabelas brutas de origem detectam a maioria dos incidentes de pipeline antes dos testes de coluna a jusante

Hipótese

Incidentes em um warehouse (um relatório mostra números errados, um job a jusante falha) têm a causa raiz a montante com mais frequência do que no modelo que falha. Se for assim, duas verificações que não exigem conhecimento do significado dos dados vão disparar mais cedo e para uma parcela maior dos incidentes do que os testes de dados em nível de coluna descritos na documentação citada (not-null, unique, accepted values, relationships) aplicados aos modelos transformados. Essas verificações são a de freshness da origem (a tabela bruta foi carregada dentro da cadência esperada, como a configuração citada do dbt calcula a partir de um loaded_at_field) e a de volume por intervalo (a carga entregou uma contagem de linhas plausível). A hipótese não afirma que os testes de coluna sejam desnecessários; afirma que, ordenadas pelo momento da detecção, as verificações na camada de origem vêm primeiro na maioria dos incidentes, e que uma equipe com esforço limitado deveria implementá-las antes de qualquer outra coisa.

Previsão

Em um warehouse que registra os incidentes com a causa raiz e a primeira verificação que falhou, pelo menos metade dos incidentes cuja causa raiz seja uma indisponibilidade a montante, uma extração parcial ou uma falha de agendamento será detectada por uma verificação de freshness ou de volume antes de qualquer teste de coluna falhar. Além disso, a mediana do intervalo entre o primeiro alerta na camada de origem e a primeira falha de teste a jusante será de pelo menos um intervalo de agendamento. Incidentes causados por erros de lógica nas transformações mostrarão a ordem inversa, e a proporção deles decide se a hipótese se sustenta no conjunto.

Teste proposto

1. Ativar verificações de freshness e de volume em todas as origens brutas e manter inalterados os testes existentes a jusante; registrar o resultado de cada verificação com carimbo de data e hora.
2. Durante um período de vários meses, registrar cada incidente com a sua categoria de causa raiz (a montante, extração, agendamento, lógica de transformação, mudança de esquema) e os carimbos de data e hora da primeira verificação disparada de cada tipo.
3. Contar, por categoria, qual tipo de verificação disparou primeiro e a defasagem entre elas; relatar as proporções com a respectiva incerteza e o número de incidentes que nenhuma verificação detectou.
4. Pré-registrar o limiar (metade dos incidentes) e as categorias antes de coletar os dados.

Estado

Nenhum resultado é alegado. Fatores de confusão: equipes que já têm testes maduros a jusante terão menos incidentes de transformação; limiares de volume muito largos deixarão passar cargas parciais e enviesarão a contagem contra a hipótese; incidentes que ninguém registra não podem ser contados.