Eran las nueve de la mañana de un lunes cuando el informe de ventas apareció a cero. No había sido un mal fin de semana: era un fichero que no llegó. El origen falló durante la noche, el pipeline se ejecutó igualmente sobre datos vacíos y el panel mostró, con total confianza, un número equivocado. Quien lo notó fue el director comercial, no el equipo de datos.
Esta escena se repite en muchas organizaciones y explica por qué la observabilidad de datos ha dejado de ser un lujo. A medida que los datos pasan por más etapas —ingesta, transformación, modelos, informes—, se multiplican los puntos donde algo puede romperse en silencio. Y el problema más caro no es el pipeline que falla con estruendo; es el que sigue ejecutándose y produciendo números plausibles pero erróneos.
La observabilidad de datos es la práctica de saber, en cualquier momento, si los datos en los que confiamos están sanos, y de ser avisados cuando no lo están, antes de que la decisión equivocada ya se haya tomado. Este artículo explica el concepto, por qué las pruebas tradicionales no bastan, cuáles son los cinco pilares que la componen y cómo empezar sin tener que comprar ya una plataforma.
Qué es la observabilidad de datos
El término viene de la ingeniería de software. En los sistemas de aplicaciones, la observabilidad es la capacidad de entender el estado interno de un sistema a partir de las señales que emite: métricas, logs y traces. La observabilidad de datos toma esa idea y, en lugar de vigilar el uso de CPU o la latencia de las peticiones, vigila la salud de los propios datos y de los pipelines que los mueven.
El principio es el mismo: instrumentar el sistema para que cuente lo que está pasando y detectar desviaciones pronto. Aplicada a los datos, se traduce en monitorizar continuamente señales como la hora en que una tabla se actualizó por última vez, cuántas filas recibió, si el esquema cambió y si la distribución de los valores sigue pareciéndose a la habitual. Cuando alguna de esas señales se aparta del patrón, se avisa a alguien, preferiblemente antes que al informe.
Por qué las pruebas no bastan
Muchos equipos ya escriben pruebas de datos: una columna no puede tener nulos, una clave tiene que ser única, un total tiene que cuadrar. Son valiosas y deben existir. Pero las pruebas verifican aquello que ya sabemos que puede salir mal, los llamados known unknowns. Escribimos una aserción porque anticipamos el problema.
La realidad produce sobre todo unknown unknowns: el fallo que nadie previó. Un origen que cambia el formato de una fecha, un proveedor que empieza a enviar valores en mayúsculas, una unión que pasa a duplicar filas tras un cambio aguas arriba. No hay prueba escrita para eso, porque nadie imaginó el escenario. La observabilidad cubre ese territorio: en lugar de preguntar solo si los datos pasan las reglas que escribimos, pregunta si están distintos de lo que suelen ser. Pruebas y observabilidad no compiten: se complementan.
Los cinco pilares de la observabilidad de datos
Una forma muy usada de organizar el tema describe cinco pilares. Juntos, cubren la mayoría de los síntomas de datos enfermos:
- Frescura (freshness) — ¿los datos están actualizados? ¿Cuándo recibió la tabla nuevas filas por última vez?
- Volumen — ¿la cantidad está dentro de lo esperado? Un día con la mitad de las filas habituales, o con el doble, es sospechoso.
- Esquema (schema) — ¿cambió la estructura? Una columna que desaparece, cambia de tipo o se renombra rompe todo lo que viene aguas abajo.
- Distribución — ¿los valores siguen siendo plausibles? Un pico de nulos, un campo que pasa a tener solo ceros o una media que salta revelan problemas que el recuento de filas no detecta.
- Linaje (lineage) — ¿cómo se conectan tablas e informes entre sí? Es el mapa que permite ir del síntoma a la causa y medir el impacto.
Ningún pilar basta por sí solo. Una tabla puede estar fresca y con el volumen correcto, pero llena de nulos por un cambio en el esquema del origen. Es la lectura combinada la que da confianza.
Frescura y volumen: los avisos más tempranos
Frescura y volumen son, a menudo, las alarmas más útiles porque detectan los fallos más frecuentes: datos que no llegaron o llegaron de menos. Monitorizar la frescura es comparar la hora de la última actualización con la que cabría esperar: si una tabla suele cargarse hasta las 6 h y a las 8 h todavía tiene la de ayer, algo falló.
El volumen añade una segunda lectura. Un pipeline puede ejecutarse a su hora y aun así traer solo una fracción de las filas, por ejemplo porque el origen solo exportó una región. Definir bandas de normalidad para el recuento diario de filas, con margen para la estacionalidad natural, convierte un silencio peligroso en una alerta accionable. Estas dos señales, por sí solas, evitan una parte considerable de los incidentes clásicos.
Esquema y distribución: cuando cambia la forma de los datos
Los cambios de esquema están entre las causas más traicioneras de averías. Alguien, tres equipos aguas arriba, renombra una columna o le cambia el tipo, y el pipeline o revienta o —peor— rellena el campo con nulos sin quejarse. Vigilar el esquema significa registrar la estructura esperada y alertar cuando aparecen, desaparecen o cambian de tipo las columnas.
La distribución es más sutil. Aquí se mira la forma de los valores: el porcentaje de nulos, la proporción entre categorías, la media y la dispersión de un campo numérico, el número de valores distintos. Una columna de país que siempre tuvo veinte valores y pasa a tener dos, o un precio medio que se triplica de un día para otro, son señales de que algo cambió en el origen, aunque el volumen y la frescura estén impecables. Es la diferencia entre saber que los datos llegaron y saber que los datos tienen sentido.
Linaje: del síntoma a la causa y al impacto
Cuando salta una alerta, siguen dos preguntas: ¿qué causó esto y a quién afecta? El linaje responde a ambas. Al mapear cómo cada tabla deriva de otras y qué informes dependen de cada tabla, se puede subir la cadena hasta el origen del problema y, a la vez, enumerar los paneles que deben llevar un aviso de datos bajo sospecha.
Sin linaje, cada incidente es una investigación desde cero, hecha a la carrera y bajo presión. Con linaje, el análisis de causa y el de impacto se vuelven casi inmediatos. El linaje es también lo que permite comunicar con transparencia: avisar proactivamente a quienes usan un informe afectado genera mucha más confianza que dejar que sea el usuario quien descubra el error.
Cómo empezar sin comprar una plataforma
No hace falta adquirir una herramienta dedicada para dar los primeros pasos. Buena parte del valor se obtiene con consultas sencillas sobre los metadatos que el propio almacén ya guarda. Una verificación de frescura puede ser tan directa como comparar la fecha máxima de una tabla con el momento actual:
SELECT MAX(data_carga) AS ultima, CURRENT_TIMESTAMP AS agora FROM vendas;
Una verificación de volumen compara el recuento del día con la media reciente:
SELECT COUNT(*) FROM vendas WHERE data_carga = CURRENT_DATE;
A partir de aquí, el camino es incremental: programar estas consultas, guardar el histórico de los resultados, definir umbrales y enviar una alerta cuando se superan. Empiece por las tablas más críticas —aquellas de las que dependen los informes que ve la dirección— y amplíe la cobertura a medida que el valor se demuestra. Solo cuando el número de tablas y de pipelines hace inviable el esfuerzo manual tiene sentido evaluar una plataforma dedicada, con detección automática de anomalías.
Minicaso: una empresa de retail que dejó de enterarse de los errores por sus clientes
Pensemos en una empresa de retail con una decena de tiendas y un puñado de analistas. Los informes de ventas y de stock se alimentaban de varios pipelines nocturnos. Cerca de una vez al mes, un informe aparecía erróneo y, casi siempre, era un gerente de tienda quien lo reportaba, lo que erosionaba la confianza en toda la plataforma de datos.
El equipo empezó por instrumentar solo las cinco tablas más importantes, con verificaciones de frescura y de volumen y un puñado de reglas de distribución sobre campos críticos, como el porcentaje de nulos en el identificador de producto. En tres meses, el tiempo medio de detección de un problema bajó de más de un día a menos de una hora, y la mayoría de los incidentes pasó a detectarse antes de llegar a un informe. El número de errores reportados por usuarios de negocio cayó a casi cero.
La ganancia no fue solo técnica. Al avisar proactivamente de que un panel podía estar afectado y se estaba corrigiendo, el equipo de datos cambió su imagen de fuente de sorpresas desagradables por la de un servicio fiable. La observabilidad se pagó no en líneas de código, sino en confianza recuperada.
Métricas para demostrar el valor
Como cualquier inversión, la observabilidad debe mostrar resultados. Tres métricas ayudan a contar la historia. El tiempo medio de detección mide cuánto se tarda en descubrir un problema después de que ocurre; el tiempo medio de resolución mide cuánto se tarda en corregirlo. Ambos deben bajar a medida que crece la cobertura.
La tercera es el tiempo de indisponibilidad de datos (data downtime): el periodo en que los datos estuvieron erróneos, ausentes o parciales, estimado normalmente como el número de incidentes multiplicado por la suma de los tiempos de detección y de resolución. Es una medida honesta del riesgo al que estuvo expuesto el negocio, y la forma más elocuente de justificar el esfuerzo ante quien decide el presupuesto.
En la práctica
La observabilidad de datos no es una moda ni exige empezar comprando software. Empieza por un cambio de actitud: asumir que los datos van a fallar de maneras que no podemos anticipar e instrumentar los pipelines para que esos fallos se anuncien pronto, en lugar de ser descubiertos por el cliente.
Elija las tablas de las que más depende, empiece por vigilar frescura y volumen, añada algunas reglas de distribución sobre los campos que más duelen cuando fallan y mapee el linaje que conecta cada informe con sus orígenes. Es una inversión modesta al arrancar y con un retorno claro: menos sorpresas, decisiones más seguras y un equipo de datos en el que la organización vuelve a confiar.
