Cómo saber si tus datos son fiables antes de que lo pregunte negocio

De los tests de dbt a la monitorización continua en Snowflake: qué implementar, en qué orden y cómo no ahogarse en alertas.

Hay una escena que todo data engineer ha vivido. Un lunes por la mañana, alguien de negocio escribe por Slack: «el dashboard de ventas dice que ayer facturamos la mitad, ¿es correcto?». Y empieza la arqueología: revisar el run de anoche, que salió verde; mirar la tabla origen; descubrir que el sistema de origen cambió un campo hace tres días y que llevamos setenta y dos horas sirviendo datos incompletos. El pipeline no falló. Simplemente hizo su trabajo con datos malos, sin quejarse.

Ese es exactamente el hueco que cubre la data observability, o observabilidad de datos. La diferencia con la monitorización clásica es breve de enunciar y decisiva en la práctica: la monitorización te dice que un job terminó; la observabilidad te dice si el dato que produjo es fiable. Una vigila el proceso; la otra, el producto.

Conviene además distinguirla de la calidad de datos, con la que se solapa pero no es idéntica. La calidad mide si el dato cumple unas reglas en un momento concreto y produce puntuaciones; la observabilidad mide si el dato se comporta con normalidad a lo largo del tiempo y produce alertas e incidentes. Dicho de otro modo: los tests comprueban las reglas que ya sabes formular; la observabilidad detecta lo que no se te ocurrió comprobar.

Por qué se ha vuelto una prioridad

• Las arquitecturas distribuidas multiplicaron los puntos de fallo silencioso: el job termina bien y el dato llega mal.
• Los sistemas de IA consumen datos directamente, sin un analista humano que detecte que algo no cuadra.
• El coste de un incidente ya no es un dashboard raro: es un modelo que decide mal, en producción y a escala.
• Gartner proyecta que la mitad de las empresas con arquitecturas de datos distribuidas habrán adoptado herramientas de observabilidad en 2026, frente a en torno al 20 % en 2024.

Los cinco pilares de la data observability (y el sexto que trae la IA)

El marco de referencia, establecido por Barr Moses en Monte Carlo y hoy asumido por todo el sector, descompone la salud de los datos en cinco dimensiones. Sirve como checklist mental: si no estás cubriendo alguna, ahí tienes un punto ciego.

• Frescura: ¿está el dato al día? Detecta tablas obsoletas, cargas retrasadas y huecos en la llegada.
• Volumen: ¿está completo? Tanto filas de menos por una carga parcial como de más por una duplicación silenciosa.
• Esquema: ¿es estable la estructura? Columnas añadidas, borradas, renombradas o con cambio de tipo aguas arriba.
• Distribución: ¿son normales los valores? Nulos que se disparan, rangos imposibles, deriva estadística progresiva.
• Linaje: ¿de dónde viene y qué depende de esto? Es lo que convierte una alerta en un diagnóstico.

La novedad de 2026 es que estos cinco pilares vigilan la estructura, no el significado. En un pipeline analítico tradicional bastaba, porque había un analista con conocimiento de dominio capaz de detectar que una cifra no tenía sentido. Cuando el consumidor es un modelo, ese filtro desaparece. De ahí que se hable ya de una sexta dimensión, la integridad semántica, y de una categoría más amplia —observabilidad de datos y de IA— que cubre también los inputs del modelo, el corpus de RAG y el contexto que reciben los agentes. El ejemplo que mejor lo ilustra: una definición de métrica que lleva dieciocho meses sin revisarse es una violación de frescura semántica, aunque la tabla se actualice cada hora.

Data observability con dbt: dónde llegan los tests y dónde no

Si trabajas con dbt, ya tienes la primera capa montada, y conviene reconocerlo antes de comprar nada. Los tests genéricos (unique, not_null, accepted_values, relationships), los paquetes dbt_utils y dbt_expectations, los contratos de modelo y el comando dbt source freshness cubren muchísimo terreno. La frescura de fuentes se declara así:

 

sources: – name: raw_ventas tables: – name: pedidos loaded_at_field: ingested_at freshness: warn_after:  { count: 6,  period: hour } error_after: { count: 12, period: hour }

Ejecutarlo como puerta en el pipeline —y no como un informe que se mira después— es lo que evita que el dato obsoleto llegue a producción. En dbt Cloud puede configurarse para detener el job si la fuente está rancia.

Ahora, los límites. Los tests de dbt son determinísticos y puntuales: comprueban una regla que tú has escrito, en el momento en que corre el pipeline. Eso deja tres huecos importantes. Primero, solo detectan lo que anticipaste: si nadie escribió un test sobre la columna que se rompió, no hay alerta. Segundo, corren cuando corre dbt; si el dato se corrompe fuera de esa ventana, te enteras en el siguiente run. Y tercero, un umbral fijo envejece mal: «más de 1.000 filas diarias» deja de tener sentido cuando el negocio crece o cuando hay estacionalidad.

Para cubrir el tercer hueco existen tests de detección de anomalías. Elementary es la opción dbt-nativa más extendida: es un paquete que se instala en el proyecto, captura los artefactos y resultados de cada ejecución en tablas del propio warehouse, y añade tests que aprenden del histórico en lugar de exigir un umbral fijo.

models: – name: fct_pedidos config: elementary: timestamp_column: «ingested_at» tests: – elementary.volume_anomalies: time_bucket: period: day count: 1 – elementary.freshness_anomalies

Data observability en Snowflake: monitorización continua con DMF

Aquí está la pieza que muchos equipos desconocen y que resuelve el segundo hueco: la vigilancia entre ejecuciones de dbt. Snowflake ofrece Data Quality Monitoring mediante Data Metric Functions (DMF): funciones que se asocian a una tabla o vista y se ejecutan según un calendario propio, con resultados registrados de forma centralizada en tu cuenta. Cubren completitud, exactitud, unicidad y validez. Es una funcionalidad de Enterprise Edition; conviene confirmarlo antes de planificar nada.

Snowflake proporciona DMFs de sistema en el esquema SNOWFLAKE.CORE, que cubren directamente varios de los pilares: FRESHNESS y ROW_COUNT para frescura y volumen, SCHEMA_CHANGE_COUNT para cambios de esquema, NULL_PERCENT, DUPLICATE_COUNT, STDDEV o los cuantiles aproximados para distribución. El flujo son dos pasos: primero se fija el calendario en el objeto, después se asocia la función.

— 1) Calendario: cada 30 minutos, o al modificarse la tabla ALTER TABLE core.fct_pedidos SET DATA_METRIC_SCHEDULE = ’30 MINUTE’; — alternativas: ‘USING CRON 0 6,12,18 * * * UTC’  |  ‘TRIGGER_ON_CHANGES’   — 2) Asociar metricas del sistema ALTER TABLE core.fct_pedidos ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT ON (customer_id);   — ROW_COUNT no recibe columnas como argumento ALTER TABLE core.fct_pedidos ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ROW_COUNT ON ();

También se pueden declarar las expectativas en el propio CREATE TABLE, de modo que la vigilancia empieza en el instante en que nace el objeto y queda documentada junto a su definición:

CREATE OR REPLACE TABLE core.pedidos ( order_id     NUMBER, customer_id  NUMBER ) WITH DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT ON (customer_id) EXPECTATION sin_clientes_nulos ( VALUE = 0 ), SNOWFLAKE.CORE.DUPLICATE_COUNT ON (order_id) EXPECTATION sin_pedidos_duplicados ( VALUE = 0 );

Cuando ninguna métrica del sistema encaja, se crea una propia con CREATE DATA METRIC FUNCTION, lo que permite codificar reglas de negocio específicas. Y para explotar los resultados, la vista de referencia es DATA_QUALITY_MONITORING_RESULTS. Un detalle nada obvio pero importante: hay que evaluar sobre la columna measurement_time, porque entre la hora programada y la medición real pueden haberse producido inserciones, y esa columna refleja el momento efectivo de la evaluación.

Tres avisos prácticos antes de desplegar esto a escala:

• El coste es serverless y aparece en la factura bajo la categoría «Data Quality Monitoring». Solo se factura cuando un DMF programado se computa sobre un objeto: crear un DMF no cuesta, y llamarlo de forma suelta con un SELECT tampoco.
• Hay un límite de 50.000 asociaciones de DMF por cuenta, y cada asignación a una tabla cuenta como una.
• Al modificar la programación existe una latencia de unos diez minutos sobre los DMF ya asignados. Planifica los cambios de calendario con eso en mente.

Cómo implementar data observability por capas

La conclusión de todo lo anterior no es elegir una herramienta, sino combinar tres capas que responden a preguntas distintas. La primera son los tests en CI: bloquean en el pull request lo que nunca debería llegar a producción. La segunda es la monitorización continua —los DMF— que vigila las tablas críticas entre ejecuciones. La tercera es la detección de anomalías, que cubre lo que no anticipaste y se adapta a la evolución del negocio.

El error más común es intentar montar las tres a la vez sobre todo el warehouse. Un orden que funciona: empieza por identificar las tablas realmente críticas —las que alimentan decisiones o modelos en producción, que suelen ser muchas menos de las que parecen—, cúbrelas con tests en CI y frescura de fuentes, añade DMFs continuos solo sobre ellas, y deja la detección de anomalías para cuando el proceso de respuesta ya funcione. Instrumentar antes de tener a quién avisar solo genera ruido.

Data observability: el proceso de detección y respuesta

Se puede tener una cobertura impecable y una observabilidad inútil. Lo que separa un caso del otro no es la herramienta, sino cómo se mide y se responde. Y aquí conviene tomar prestado el vocabulario de los equipos de SRE.

El data downtime es el periodo total durante el cual hubo datos poco fiables en producción, y se descompone en tramos con palancas distintas. El MTTD (tiempo medio hasta detectar) es el tramo invisible: el dato ya está mal y nadie lo sabe. Es el más difícil de reducir porque depende de la calidad de la instrumentación, no de la rapidez del equipo. El MTTA (hasta que alguien atiende la alerta) suele ser el más barato de mejorar: casi siempre se arregla con propiedad clara por tabla y buen enrutado. Y el tramo de diagnóstico y resolución es donde el linaje deja de ser un diagrama bonito para convertirse en la diferencia entre media hora y dos días.

El fallo que hunde más implantaciones es la fatiga de alertas, y merece la pena entender su mecánica porque es contraintuitiva. Degrada primero el MTTA, porque los ingenieros tardan cada vez más en atender avisos que asumen falsos positivos. Después degrada la calidad de la investigación, porque un equipo saturado deja de correlacionar señales. Y remata con un círculo vicioso: el equipo silencia los monitores ruidosos, lo que reduce la cobertura y, paradójicamente, empeora el MTTD que la instrumentación pretendía mejorar. La conclusión operativa es incómoda para quien mide el éxito en número de tests: cobertura sin priorización es ruido. Es preferible vigilar veinte tablas con alertas que alguien atiende que doscientas que todo el mundo ignora.

Tres reglas que sostienen el proceso: cada tabla crítica tiene un propietario con nombre y apellidos; la severidad significa algo (un warn no despierta a nadie, un error sí); y cuando salta una alerta hay un runbook que dice qué mirar primero. Sin esas tres cosas, la mejor plataforma del mercado acaba siendo un canal de Slack silenciado.

Conclusión

La observabilidad de datos no es una categoría de producto que se compra, sino una propiedad que se construye por capas: tests que bloquean en CI, monitorización continua sobre lo crítico, detección de anomalías para lo imprevisto y, envolviéndolo todo, un proceso de respuesta con dueños y prioridades.

Para un equipo que ya vive en Snowflake y dbt, la buena noticia es que buena parte del camino está hecho y el resto es nativo: los tests y la frescura de fuentes ya están ahí, y los DMF cubren la vigilancia continua sin introducir una herramienta nueva en el stack. Lo verdaderamente difícil nunca fue técnico. Es decidir qué datos merecen ser vigilados, quién responde cuando fallan y qué alertas se ganan el derecho a interrumpir a alguien. Empieza por las tablas que alimentan decisiones reales, cúbrelas bien, y crece desde ahí.

Nota: las funcionalidades de Data Quality Monitoring de Snowflake requieren Enterprise Edition y algunas capacidades están en preview; verifica el estado, los límites y el modelo de coste en la documentación oficial antes de desplegar a escala. Las proyecciones de mercado citadas proceden de análisis de terceros y deben tratarse como estimaciones.

Preguntas frecuentes sobre Data Observability

¿Qué es data observability?

La data observability es la capacidad de monitorizar de forma continua el estado y el comportamiento de los datos para detectar problemas antes de que afecten a los usuarios o a los sistemas que dependen de ellos. A diferencia de los tests de calidad, que comprueban reglas concretas, la data observability analiza dimensiones como frescura, volumen, esquema, distribución y linaje para detectar anomalías y facilitar el diagnóstico de incidentes.

¿Cuál es la diferencia entre data observability y data quality?

La data quality comprueba si los datos cumplen determinadas reglas en un momento concreto, mientras que la data observability monitoriza su comportamiento a lo largo del tiempo y genera alertas cuando detecta anomalías o incidentes. Los tests de calidad verifican lo que el equipo ya sabe que debe comprobar; la observabilidad permite detectar también comportamientos inesperados que no habían sido definidos previamente como reglas.

¿Cuáles son los pilares de data observability?

Los cinco pilares clásicos de data observability son frescura, volumen, esquema, distribución y linaje. La frescura comprueba si los datos están actualizados; el volumen, si han llegado las cantidades esperadas; el esquema, si la estructura ha cambiado; la distribución, si los valores se comportan con normalidad; y el linaje permite conocer el origen y las dependencias de los datos.

¿Qué relación existe entre data observability y dbt?

dbt proporciona una primera capa de data observability mediante tests, contratos de modelos y controles de frescura de las fuentes. Sin embargo, sus tests son determinísticos y se ejecutan cuando corre el pipeline. Para cubrir anomalías no previstas o problemas que aparecen entre ejecuciones, pueden añadirse herramientas de detección de anomalías y monitorización continua.

¿Cómo implementar data observability en Snowflake?

Una estrategia de data observability en Snowflake puede combinar tests de dbt para bloquear errores en CI con Data Metric Functions (DMF) para monitorizar continuamente las tablas críticas. Los DMF permiten medir dimensiones como frescura, volumen, cambios de esquema, valores nulos o duplicados según un calendario independiente de las ejecuciones de dbt.

¿Qué son las Data Metric Functions (DMF) de Snowflake?

Las Data Metric Functions (DMF) son funciones de Snowflake que permiten monitorizar métricas de calidad de datos sobre tablas y vistas siguiendo un calendario propio. Pueden utilizarse para detectar problemas de frescura, volumen, esquema, distribución y otras métricas, y sus resultados quedan registrados de forma centralizada. También es posible crear DMF personalizadas para reglas específicas del negocio.

¿Qué es data downtime?

El data downtime es el periodo durante el cual los datos disponibles en producción no son fiables. Para reducirlo, la data observability permite trabajar sobre diferentes etapas del incidente: el MTTD mide cuánto se tarda en detectar el problema, el MTTA cuánto se tarda en atender la alerta y el diagnóstico y resolución miden el tiempo necesario para entender y solucionar la causa.

¿Cómo evitar la fatiga de alertas en data observability?

La clave es no intentar monitorizar todo el warehouse desde el primer día. Una estrategia efectiva consiste en identificar primero las tablas críticas, establecer tests y controles de frescura, añadir monitorización continua sobre ellas y posteriormente incorporar detección de anomalías. Además, cada tabla crítica debería tener un propietario, una severidad de alerta claramente definida y un runbook que indique cómo actuar ante un incidente.