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

Objetivo

Detectar una carga rota o parcial antes de que alguien construya un informe sobre ella, con comprobaciones lo bastante económicas como para ejecutarlas en cada intervalo y lo bastante específicas como para que un fallo señale la tabla y la regla.

Requisitos previos

Cada tabla tiene una granularidad declarada (lo que representa una fila) y una columna o partición de marca de tiempo de carga. La documentación de dbt (citada) modela una comprobación como una sentencia select que devuelve los registros que fallan: cero filas significa que la afirmación se cumple. De fábrica ofrece comprobaciones de no nulo, unicidad, valores aceptados y relación (clave foránea) por columna, y una configuración de actualidad de la fuente con umbrales warn_after y error_after calculados a partir de un campo loaded_at_field; si no se proporciona ninguno de los dos umbrales, la actualidad no se calcula. Las mismas cuatro reglas pueden escribirse como SQL simple en cualquier planificador.

Pasos

1. Actualidad: para cada tabla fuente, registrar la cadencia de carga esperada y fijar un umbral de advertencia ligeramente por encima de ella y un umbral de error en el punto en que el informe posterior sería incorrecto. Comprobar max(loaded_at) frente al reloj en el momento de la ejecución.
2. Volumen: para el intervalo recién cargado, contar filas y comparar con el mismo intervalo de períodos anteriores (el mismo día de la semana para cargas diarias). Almacenar los recuentos en una pequeña tabla de historial y marcar los recuentos fuera de una banda definida a partir de ese historial; empezar con una banda amplia y reducirla tras unas semanas de observación.
3. Nulos: afirmar no nulo en las claves primarias y foráneas, en la marca de tiempo usada para particionar y en las medidas que suman los informes. No afirmar no nulo en atributos opcionales; en su lugar, seguir su tasa de nulos a lo largo del tiempo.
4. Unicidad: afirmar que las columnas que forman la granularidad son únicas. Un duplicado aquí es un reintento previo, una unión que se expandió, o una reejecución que agregó en lugar de reemplazar.
5. Ordenar las comprobaciones después de la carga y antes del paso que publica la tabla a los consumidores (cambio de vista, promoción de partición), de modo que una comprobación fallida de nivel error detenga la publicación.
6. Dirigir cada fallo a quien es responsable de la tabla, con las filas que fallan adjuntas, y registrar todos los resultados, incluidos los éxitos, para poder identificar comprobaciones inestables.

Resultado esperado

Una carga que llega tarde, incompleta, duplicada o con claves perdidas se reporta en la tabla que falló, dentro de un intervalo de planificación, antes de que se propague.

Límites y base de verificación

Estas comprobaciones detectan roturas estructurales, no valores incorrectos pero bien formados; las comprobaciones de reglas de negocio (los totales concuerdan con el sistema fuente) vienen después. Las bandas de volumen necesitan sensibilidad estacional o generan alertas en cada día festivo. El conjunto es un protocolo propuesto derivado de la documentación citada; no se afirma ninguna tasa de detección.