Calidad y observabilidad de datos
Los datos viajan por cadenas de transformaciones donde un error silencioso se propaga aguas abajo sin aviso. La calidad de datos pone reglas que detectan esos errores; la observabilidad vigila la salud del pipeline en producción para enterarse antes que el consumidor.
Las dimensiones de la calidad
- Completitud: no faltan filas ni valores obligatorios.
- Unicidad: una entidad real no aparece duplicada.
- Validez: los valores respetan tipo, formato y rango esperados.
- Consistencia: no se contradicen entre sistemas que deberían coincidir.
- Oportunidad (frescura): el dato llegó a tiempo para ser útil.
Contratos de datos
Un contrato de datos es un acuerdo explícito entre quien produce un dataset y quien lo consume: esquema, semántica, formato y nivel de servicio. Cuando el productor cambia una columna sin avisar (schema drift), el contrato lo detecta en lugar de romper al consumidor en silencio.
Pruebas dentro del pipeline
Las mismas ideas que se aplican al código se aplican al dato: antes y después de transformar, el pipeline ejecuta pruebas que aprueban o bloquean. Herramientas como dbt o Great Expectations declaran esas reglas junto al modelo.
- No nulos y únicos en llaves primarias.
- Rango y accepted values en columnas sensibles.
- Relacional: toda clave foránea existe en su tabla padre.
- Volumen esperado: el conteo de hoy no cae abruptamente.

Observabilidad: las cinco señales
La observabilidad moderna de datos monitorea automáticamente cinco señales que suelen anticipar un problema: frescura (¿llegó a tiempo?), volumen (¿cuántas filas?), esquema (¿cambió la estructura?), linaje (¿qué depende de qué?) y distribución (¿se movieron los valores?).
| Dimensión | Pregunta que responde | Ejemplo de regla |
|---|---|---|
| Completitud | ¿Faltan datos? | id_pedido nunca nulo |
| Unicidad | ¿Hay duplicados? | email es único |
| Validez | ¿El valor tiene sentido? | edad entre 0 y 120 |
| Frescura | ¿Está al día? | tabla actualizada en las últimas 6 h |
| Volumen | ¿Es el esperado? | entre 80k y 120k filas/día |
Linaje: de dónde viene y a dónde va
El linaje registra el camino de cada dato desde su origen hasta cada tablero. Sin linaje, un cambio en una fuente es una apuesta a ciegas; con linaje, se sabe exactamente qué reportes y equipos se verán afectados antes de publicar.
Cuando algo falla
- Detectar: la prueba o la señal de observabilidad dispara.
- Aislar: no propagar el dato malo aguas abajo.
- Alertar con contexto: qué regla, qué tabla, desde cuándo.
- Corregir y reprocesar (backfill) una vez arreglada la causa.
Errores frecuentes
- Validar solo al final de la cadena, cuando el daño ya se propagó.
- No poner umbral de volumen, así que una fuente que deja de mandar pasa inadvertida.
- Tener un tablero de calidad que nadie mira y sin dueño asignado.
Ejemplo resuelto: un KPI amanece en cero
El ingreso diario del directorio muestra cero esta mañana aunque ayer estaba bien. Secuencia de diagnóstico:
- Revisar frescura: ¿llegó el lote de hoy de la fuente de pagos?
- Consultar volumen: el conteo de la tabla de hechos viene desplomado.
- Seguir el linaje hacia arriba hasta el modelo que alimenta el KPI.
- Confirmar la causa: cambió el esquema de la fuente y el parser dejó de leer una columna.
- Aislar el modelo, arreglar el contrato y lanzar el backfill del día.
¿Para qué sirve en la realidad?
La confianza es el activo de un equipo de datos: un solo KPI errado publicado destruye la credibilidad de todo el almacén. La calidad y la observabilidad convierten errores silenciosos en alertas manejables.
¿Qué distingue a la observabilidad de datos de simplemente "que el pipeline no falle"?
Un contrato de datos ayuda a detectar el schema drift antes de que rompa a los consumidores.
La dimensión de calidad que pregunta si el dato llegó a tiempo se llama o frescura.
Clasifica cada control según a qué dimensión de calidad pertenece.
Validez
Unicidad
Frescura
Une cada señal de observabilidad con lo que vigila.
Calidad y observabilidad
Calidad y observabilidad de datos
# Calidad y observabilidad ## Dimensiones ### completitud ### unicidad y validez ### frescura y volumen ## Tecnicas ### pruebas en el pipeline ### contratos de datos ### linaje ## Respuesta ### detectar y aislar ### alertar con contexto ### backfill
Pruebas de datos en dbt (documentación oficial)
Cómo se declaran pruebas de unicidad, no nulos y relaciones junto al modelo.
Amanece un tablero ejecutivo con una métrica a la mitad del valor habitual, pero todos los jobs terminaron en verde. ¿Qué señal de observabilidad debería haberlo atrapado y qué prueba o umbral implementarías para que no vuelva a pasar desapercibido?