Comprobaciones de calidad de datos: actualidad, volumen, nulos y unicidad como conjunto mínimo

Objetivo

Detectar una carga incompleta, tardía, duplicada o sin claves en la tabla donde se produce el fallo, dentro de un intervalo y antes de que alguien construya un informe sobre ella.

Requisitos previos

Cada tabla tiene una granularidad declarada (lo que significa una fila) y una columna de hora de carga o una partición. La documentación de dbt modela una comprobación como un SELECT que devuelve los registros erróneos (cero filas significa que pasa) e incluye las pruebas genéricas not_null, unique, accepted_values y relationships; para las fuentes, la actualidad se puede configurar mediante loaded_at_field con los umbrales warn_after y error_after. Quien trabaje sin dbt escribe las mismas cuatro reglas como SQL en su propio planificador; en la propia base de datos, las restricciones NOT NULL, UNIQUE y FOREIGN KEY, tal como las documenta PostgreSQL, cubren una parte de forma permanente.

Pasos

1. Actualidad: anotar para cada fuente la cadencia de carga esperada, fijar un umbral de aviso algo por encima de ella y un umbral de error en el punto en que el informe posterior dejaría de ser correcto; comprobar max(geladen_am) contra el reloj en el momento de la ejecución.
2. Volumen: comparar el número de filas del intervalo recién cargado con los mismos intervalos de periodos anteriores (en cargas diarias, el mismo día de la semana); guardar los recuentos en una pequeña tabla de histórico, empezar con una banda amplia y estrecharla tras algunas semanas de observación.
3. Nulos: aplicar NOT NULL a las claves primarias y foráneas, a la hora de partición y a las métricas que los informes suman; en los atributos opcionales, seguir en su lugar la tasa de nulos a lo largo del tiempo.
4. Unicidad: las columnas de la granularidad deben ser únicas. Un duplicado es una repetición de la fuente, un join que multiplica filas o una recarga que añadió en lugar de reemplazar.
5. Orden: ejecutar las comprobaciones después de la carga y antes del paso que hace visible la tabla (intercambio de vista, liberación de partición), de modo que un fallo de nivel «error» detenga la publicación y «warn» solo avise.
6. Guardar cada resultado, también los que pasan, con marca de tiempo, y dirigir los fallos, junto con las filas afectadas, a la persona responsable de la tabla; así se hacen visibles las comprobaciones intermitentes.

Resultado esperado

Una carga que llega demasiado tarde, a medias, duplicada o con claves perdidas se notifica en el punto donde se produce el fallo, antes de que se propague.

Límites y base de verificación

Las cuatro comprobaciones encuentran roturas estructurales, no valores erróneos pero bien formados; las conciliaciones con el sistema de origen (las sumas coinciden) son el siguiente paso. Las bandas de volumen sin conocimiento de la estacionalidad saltan en cada festivo. El conjunto es una propuesta basada en la documentación citada; no se afirma ninguna tasa de detección.