Ingeniería de Datos · Pipeline de Datos

Calidad y observabilidad de datos

Aplicar las dimensiones de calidad de datos, pruebas en el pipeline, contratos y observabilidad para detectar y contener datos malos antes de que lleguen al consumidor.

Calidad y observabilidad de datos

Correr no es lo mismo que ser confiable Que el pipeline termine en verde no significa que el dato esté bien. Un valor nulo mal colocado o una fuente que dejó de alimentar puede dejar un KPI en cero sin que ningún trabajo falle. La observabilidad trata el dato como un servicio que se vigila.

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

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.

Diagrama de tres bandas: las dimensiones de calidad arriba, las técnicas de vigilancia en el centro (pruebas, contratos, frescura, linaje) y las acciones cuando algo falla abajo (aislar, alertar, backfill).
La calidad se define por dimensiones, se vigila con técnicas y se responde con acciones acotadas.

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?).

Cada dimensión se traduce en una regla concreta que el pipeline puede ejecutar.
DimensiónPregunta que respondeEjemplo 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

Errores frecuentes

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:

  1. Revisar frescura: ¿llegó el lote de hoy de la fuente de pagos?
  2. Consultar volumen: el conteo de la tabla de hechos viene desplomado.
  3. Seguir el linaje hacia arriba hasta el modelo que alimenta el KPI.
  4. Confirmar la causa: cambió el esquema de la fuente y el parser dejó de leer una columna.
  5. 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

Regla declarada sobre el dato que aprueba o bloquea
prueba de calidad
Acuerdo de esquema y semántica entre productor y consumidor
contrato de datos
Camino del dato de origen a cada tablero
linaje
Señal que detecta que una fuente dejó de mandar
frescura / volumen
Reprocesar tras arreglar la causa
backfill

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?