¿Cómo pruebas la calidad de los datos en un pipeline y qué compruebas?

Prueba esquema, volumen y semántica. Las pruebas de esquema detectan cambios de tipo y de columnas. Las de volumen y frescura detectan una partición que llegó vacía o tarde. Las semánticas verifican unicidad de claves, no nulos en campos obligatorios, valores aceptados en enums, integridad referencial entre hecho y dimensión, e invariantes de negocio como que los ingresos nunca sean negativos. Ejecútalas dentro del pipeline y falla o pon en cuarentena en lugar de publicar en silencio.

Pienso en tres capas. Esquema: la columna existe, el tipo no ha cambiado, no aparece en silencio un campo nuevo anulable. Volumen y frescura: esta partición tiene un número de filas dentro de una banda razonable respecto a la media reciente, y el último evento no tiene ocho horas. Semántica: la clave primaria es única, los campos obligatorios no son nulos, el estado está en el conjunto aceptado, cada pedido referencia a un cliente que existe, y los ingresos no son negativos. En dbt eso son en su mayoría pruebas integradas más un puñado de pruebas singulares en SQL para reglas de negocio. La parte que importa más que las pruebas es la política. Una prueba de unicidad fallida sobre una clave primaria bloquea los marts aguas abajo, porque publicar ingresos duplicados es peor que no publicar nada. Un aviso suave, como una caída del 20% en el número de filas, alerta al equipo dueño pero no detiene la ejecución. Y las filas malas van a una tabla de cuarentena con el motivo del fallo, así podemos medir con qué frecuencia ocurre en vez de perder la evidencia.