Las comprobaciones de frescura y de número de filas en las tablas de origen en bruto detectan la mayoría de los incidentes de un pipeline antes que las pruebas a nivel de columna aguas abajo

Hipótesis

Los incidentes de un almacén de datos (un informe muestra cifras incorrectas, falla un trabajo aguas abajo) tienen su causa raíz aguas arriba con mayor frecuencia que en el modelo que falla. Si eso es así, entonces dos comprobaciones que no requieren conocer el significado de los datos —la frescura del origen (si la tabla en bruto se cargó dentro de su cadencia esperada, tal como calcula la configuración de dbt citada a partir de un loaded_at_field) y el volumen por intervalo (si la carga entregó un número de filas plausible)— se dispararán antes, y para una proporción mayor de incidentes, que las pruebas de datos a nivel de columna que describe la documentación citada (no nulo, único, valores aceptados, relaciones) aplicadas sobre los modelos transformados. La hipótesis no afirma que las pruebas a nivel de columna sean innecesarias; afirma que, ordenadas por tiempo de detección, las comprobaciones de la capa de origen llegan primero para la mayoría de los incidentes, y que un equipo con esfuerzo limitado debería implementarlas antes que cualquier otra cosa.

Predicción

Para un almacén que registra los incidentes con una causa raíz y la primera comprobación que falla, al menos la mitad de los incidentes cuya causa raíz es una interrupción aguas arriba, una extracción parcial o un fallo de programación serán detectados por una comprobación de frescura o de volumen antes de que falle ninguna prueba a nivel de columna, y el tiempo mediano entre la primera alerta de la capa de origen y el primer fallo de prueba aguas abajo será de al menos un intervalo de programación. Los incidentes causados por errores lógicos en las transformaciones mostrarán el orden contrario, y su proporción decide si la hipótesis se sostiene en conjunto.

Prueba propuesta

1. Habilitar comprobaciones de frescura y de volumen en cada fuente en bruto, y mantener sin cambios las pruebas aguas abajo existentes; registrar cada resultado de comprobación con una marca de tiempo.
2. Durante un período de varios meses, registrar cada incidente con su categoría de causa raíz (aguas arriba, extracción, programación, lógica de transformación, cambio de esquema) y las marcas de tiempo de la primera comprobación que se dispara de cada tipo.
3. Contar, por categoría, qué tipo de comprobación se disparó primero y el retraso entre ellas; informar de las proporciones con su incertidumbre y del número de incidentes que ninguna comprobación detectó.
4. Preregistrar el umbral (la mitad de los incidentes) y las categorías antes de recopilar los datos.

Estado

No se afirma ningún resultado. Factores de confusión: los equipos que ya cuentan con pruebas aguas abajo maduras tendrán menos incidentes de transformación; unos umbrales de volumen fijados con demasiada amplitud pasarán por alto las cargas parciales y sesgarán el conteo en contra de la hipótesis; los incidentes que nadie registra no pueden contarse.