Dbt Source Freshness: Prevenga datos obsoletos en 2026

Normalmente te das cuenta de que los datos están desactualizados cuando otra persona lo nota primero.

Un líder de finanzas te envía un mensaje porque los números de ayer todavía aparecen en el panel de control de hoy. El orquestador muestra luz verde. Los modelos de dbt se crearon correctamente. Nada parece roto hasta que rastreas el problema río arriba y te das cuenta de que la tabla de origen dejó de recibir registros nuevos. Esa es la parte incómoda de los problemas de puntualidad. A menudo fallan sin que nadie se dé cuenta.

Muchos equipos aprenden esta lección de la misma manera. Invierten en pruebas de transformación, documentación y linaje, pero no añaden una comprobación directa de si los datos sin procesar siguen llegando a tiempo. Si ya estás analizando qué significan los datos desactualizados en la práctica, la frescura de origen de dbt (dbt source freshness) es una de las formas más limpias de cerrar esa brecha. Te ofrece una respuesta operativa sencilla a una pregunta de alto valor: ¿se ha actualizado esta fuente cuando se suponía que debía hacerlo?

Eso es importante porque los datos desactualizados rara vez se quedan aislados. Una ingesta retrasada puede fluir hacia los paneles ejecutivos, los modelos de ingresos, las funciones de ML y los informes de auditoría antes de que nadie se dé cuenta de que la fuente es antigua. Si estás ajustando tu proceso para identificar fallas de confiabilidad de datos, las comprobaciones de frescura deben estar cerca de la parte superior de la lista. No reemplazan las pruebas de calidad, pero detectan un tipo de falla que las pruebas estándar de esquema y lógica no detectan.

Tabla de contenidos

• El problema de los datos desactualizados

  • Las fallas silenciosas son las más costosas

  • Por qué este problema pasa desapercibido en equipos maduros

• Entendiendo dbt Source Freshness

  • Qué es

  • Qué no es

  • Las tres piezas que más importan

• Configuración de comprobaciones de frescura en tu proyecto

  • Un ejemplo práctico de YAML

  • Cómo elegir umbrales

  • Qué funciona en proyectos reales

• Ejecución de comprobaciones e interpretación de resultados

  • Qué significan los estados

  • Por qué importa el código de salida

  • Estrategia de programación

• Errores comunes y técnicas avanzadas

  • Los modos de falla que aparecen primero

  • Qué cambiar cuando lo básico es estable

  • Una lista de verificación práctica para robustecer el sistema

• Más allá de la frescura: Construyendo un flujo de trabajo de Observability completo

  • Dónde se detiene dbt

  • Qué añaden después los equipos maduros

  • Un modelo de madurez práctico

El problema de los datos desactualizados

Los incidentes de datos más frustrantes no siempre son ruidosos. Un trabajo puede completarse, los registros pueden parecer normales y los modelos río abajo aún pueden materializarse sobre entradas desactualizadas.

Es por eso que los datos desactualizados provocan problemas de confianza tan rápidamente. Al usuario de negocio no le importa si Airflow, Dagster o dbt técnicamente "se ejecutaron". Le importa que la métrica en el panel coincida con la realidad. Si una fuente de pagos dejó de cargarse de la noche a la mañana, una ejecución de transformación exitosa simplemente vuelve a publicar información antigua.

Las fallas silenciosas son las más costosas

Una cadena de fallas típica se ve así:

• Un extractor río arriba se detiene. La tabla de origen mantiene la última marca de tiempo de ayer.

• dbt sigue ejecutando modelos río abajo. Las transformaciones tienen éxito porque la tabla existe y el esquema sigue coincidiendo.

• Los paneles se actualizan según lo programado. Las partes interesadas asumen que los datos están al día porque la capa de BI se actualizó.

• La confianza cae rápidamente. Una vez que alguien detecta la brecha, todos los números cercanos a ese panel se vuelven sospechosos.

Este es exactamente el problema que dbt source freshness está diseñado para detectar. Comprueba si una fuente se ha actualizado lo suficientemente rápido como para coincidir con la frecuencia esperada.

Los problemas de frescura rara vez comienzan como "mal SQL". Por lo general, comienzan porque "los datos dejaron de llegar y nadie estaba controlando el reloj".

Por qué este problema pasa desapercibido en equipos maduros

Los equipos a menudo tienen una sólida cobertura de pruebas para valores nulos, unicidad, relaciones y valores aceptados. Esas comprobaciones importan, pero responden a preguntas diferentes. Una fuente puede superar todas las pruebas de calidad y, aun así, estar desactualizada.

Esa distinción es de suma importancia para los datos operativos. Los informes sobre ingresos, pagos, gastos de marketing, inventario y aquellos sensibles a Compliance o aspectos clínicos dependen de la puntualidad, no solo de la exactitud. Si la fila más reciente es antigua, los modelos de tablas río abajo perfectamente estructurados seguirán contando una historia equivocada.

La solución práctica es sencilla. Establece un contrato de frescura en las fuentes de datos sin procesar que importan, conecta el resultado con la orquestación y detén el pipeline cuando la fuente no haya llegado en su ventana de tiempo esperada. Eso transforma los datos desactualizados de un ticket de soporte reactivo en una señal de ingeniería procesable.

Entendiendo dbt Source Freshness

dbt source freshness es una forma integrada de monitorear si las tablas de origen están llegando a tiempo. Ha sido una característica principal de dbt desde 2019, y funciona comparando la marca de tiempo más reciente en un campo loaded_at_field con los umbrales configurables warn_after y error_after. Si los datos son más antiguos que el período permitido, el comando dbt source freshness finaliza con un código diferente de cero, lo que puede fallar los trabajos de CI y bloquear el trabajo río abajo, tal como se documenta en dbt source testing.

Si necesitas una explicación comercial de este concepto, esta guía de frescura de datos y por qué es importante para las decisiones comerciales es un complemento útil para los detalles de implementación.

Qué es

dbt source freshness funciona como una comprobación de SLA para la llegada de datos sin procesar.

Defines una fuente en sources.yml, apuntas dbt a la columna de marca de tiempo que representa cuándo llegaron los registros y le indicas qué tan antigua puede llegar a ser esa fuente antes de que emita una advertencia o un error. Luego, dbt consulta el valor máximo de ese campo y lo compara con la hora actual.

Eso lo hace muy efectivo para fuentes con una frecuencia conocida. Si una tabla de ventas debe actualizarse diariamente, un error de frescura te indica que los datos más recientes son más antiguos que esa ventana aceptada.

Qué no es

dbt source freshness no es un marco de calidad completo por sí solo.

No te dice si los valores son correctos, si una clave primaria está duplicada, si una clave externa todavía se resuelve o si la lógica de negocio cambió río arriba. Tampoco comprende de forma nativa comportamientos de llegada complejos más allá del umbral que definas.

Por eso lo considero un detector de humo, no una investigación de incendios. Te indica que el flujo de datos puede haberse detenido. No explica todos los motivos.

Regla práctica: Utiliza comprobaciones de frescura para la puntualidad, y luego utiliza pruebas de dbt y otros monitoreos para la exactitud, integridad y desviación de datos.

Las tres piezas que más importan

Cuando alguien configura esto por primera vez, le digo que se concentre en tres decisiones de configuración:

1. Elige el loaded_at_field correcto
   Este campo debe reflejar la llegada de datos o la frescura de la carga, no una marca de tiempo aleatoria de un evento comercial.

2. Establece umbrales realistas
   warn_after debería indicarte que la fuente tiende a retrasarse. error_after debería indicarle a tu pipeline que deje de confiar en ella.

3. Elige el alcance adecuado
   No todas las fuentes merecen el mismo nivel de monitoreo. Comienza con las tablas que alimentan paneles de alta visibilidad, informes financieros o características de ML.

Si defines bien esos tres puntos, dbt source freshness se vuelve operativamente útil muy rápido.

Configuración de comprobaciones de frescura en tu proyecto

La configuración reside en tu archivo YAML de origen. Eso es una buena noticia porque mantiene las reglas de puntualidad cerca de las definiciones de origen que tu equipo ya mantiene.

El comando dbt source freshness se basa en un bloque de freshness en el YAML de origen, donde defines warn_after y error_after con un período y conteo como {count: 1, period: day}. Cuando se ejecuta, dbt compara el valor máximo de loaded_at_field con la hora actual y guarda los resultados en target/sources.json, lo que facilita alimentar otras herramientas y visualizaciones con el resultado, como se muestra en la documentación de configuración de frescura de dbt.

Un ejemplo práctico de YAML

Aquí tienes un patrón limpio que puedes adaptar:

version: 2

sources:
  - name: stripe
    schema: raw_stripe
    tables:
      - name: charges
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 30, period: minute}
          error_after: {count: 60, period: minute}

      - name: payouts
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 12, period: hour}
          error_after: {count: 24, period: hour}

  - name: salesforce
    schema: raw_salesforce
    tables:
      - name: opportunities
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 1, period: day}
          error_after: {count: 2, period: day}

version: 2

sources:
  - name: stripe
    schema: raw_stripe
    tables:
      - name: charges
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 30, period: minute}
          error_after: {count: 60, period: minute}

      - name: payouts
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 12, period: hour}
          error_after: {count: 24, period: hour}

  - name: salesforce
    schema: raw_salesforce
    tables:
      - name: opportunities
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 1, period: day}
          error_after: {count: 2, period: day}

version: 2

sources:
  - name: stripe
    schema: raw_stripe
    tables:
      - name: charges
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 30, period: minute}
          error_after: {count: 60, period: minute}

      - name: payouts
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 12, period: hour}
          error_after: {count: 24, period: hour}

  - name: salesforce
    schema: raw_salesforce
    tables:
      - name: opportunities
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 1, period: day}
          error_after: {count: 2, period: day}

Este ejemplo hace tres cosas útiles:

• Utiliza una sola convención para marcas de tiempo de carga. _etl_loaded_at es explícito y fácil de estandarizar entre las herramientas de ingesta.

• Establece diferentes umbrales por tabla. Los cargos y los pagos no tienen el mismo patrón de llegada, por lo que no deben compartir la misma regla de frescura.

• Mantiene las reglas legibles. Cualquier persona que revise el proyecto puede comprender la expectativa operativa sin leer documentación externa.

Cómo elegir umbrales

El error que veo con más frecuencia es copiar los mismos valores en todas partes. Los umbrales de frescura deben reflejar el comportamiento real de ingesta y la tolerancia comercial.

Utiliza esta tabla como apoyo para tomar decisiones, no como una plantilla para aplicar ciegamente.

Qué funciona en proyectos reales

Algunos hábitos facilitan la configuración:

• Prefiere las marcas de tiempo de ingesta sobre las de negocio. created_at podría describir cuándo actuó un cliente, pero no siempre describe cuándo llegó esa fila a tu almacén de datos.

• Mantén la frescura cerca de la propiedad de los datos. Si un equipo es propietario de una fuente, asegúrate de que esté de acuerdo con los umbrales en la revisión del código.

• Documenta las excepciones. Algunas fuentes llegan tarde por diseño durante los fines de semana, al final del mes o después del procesamiento de un proveedor externo.

Si comienzas con tus fuentes sin procesar más importantes y defines bien sus reglas, la primera implementación de dbt source freshness suele requerir menos esfuerzo que la depuración que evita más adelante.

Ejecución de comprobaciones e interpretación de resultados

Una vez que el archivo YAML está en su lugar, puedes ejecutar la comprobación con el comando que tu equipo utilizará constantemente:

dbt source freshness

No necesitas ejecutarlo en todo momento para todo. dbt también admite la ejecución específica de nodos, como dbt source freshness --select source:stripe.charges, lo cual es útil cuando estás depurando una tabla volátil o validando un cambio sin la sobrecarga de una comprobación completa de todo el proyecto.

Qué significan los estados

El resultado es simple, y esa es una de las razones por las que se integra bien en CI y en la orquestación:

• PASS dbt indica que la marca de tiempo más reciente está dentro de tu umbral aceptable.

• WARN significa que la fuente es más antigua que warn_after, pero aún no supera error_after.

• ERROR significa que la fuente cruzó el umbral de falla y debe considerarse desactualizada.

Ese estado WARN es muy útil operativamente. Te brinda una señal temprana de que una fuente tiende a retrasarse, al mismo tiempo que te permite decidir si detienes el trabajo dependiente.

Por qué importa el código de salida

El código de salida del comando es lo que convierte la frescura de ser un simple panel de control a convertirse en un punto de control activo.

If a source fails freshness, dbt exits non-zero. That lets GitHub Actions, GitLab CI, Airflow, Dagster, or dbt Cloud jobs stop downstream execution automatically. In practice, that means you can prevent stale source data from propagating into marts, dashboards, and exports.

Una comprobación de frescura que solo escribe un registro es Observability. Una comprobación de frescura que bloquea las ejecuciones incorrectas río abajo es un control operativo.

Estrategia de programación

Una regla práctica de la guía de frescura de origen de dbt de Secoda es ejecutar comprobaciones al menos con el doble de frecuencia que el ritmo de datos esperado. Su ejemplo es cada 30 minutos para cargas horarias. Esto te da suficiente cobertura para detectar una actualización omitida antes de que los datos desactualizados se hagan visibles río abajo.

Un buen flujo de trabajo ligero se ve así:

1. Ejecuta la frescura antes de los trabajos de transformación para fuentes críticas.

2. Falla rápido en caso de error para que las entradas desactualizadas no alimenten modelos de confianza.

3. Dirige los resultados de WARN a las alertas para que los ingenieros puedan investigar de manera anticipada.

4. Usa ejecuciones selectivas en desarrollo cuando pruebes una fuente o una ruta de ingesta específica.

Este es uno de esos controles que es pequeño en código pero enorme en impacto.

Errores comunes y técnicas avanzadas

La mayoría de las configuraciones de dbt source freshness fallan por razones triviales, no por causas exóticas. El comando funciona. La configuración es válida. Pero el resultado operativo es ruidoso, lento o confuso.

La trampa más grande es asumir que cualquier columna de marca de tiempo servirá. No es así.

Los modos de falla que aparecen primero

Un resumen útil de las notas avanzadas de implementación de frescura de dbt destaca tres problemas comunes. Las columnas de marcas de tiempo no indexadas pueden aumentar la latencia de las consultas entre un 40 y un 60 por ciento, los desajustes de zona horaria pueden provocar alertas falsas y omitir un filter en tablas grandes puede generar una incidencia un 25 por ciento mayor de datos desactualizados no detectados.

Esos no son casos hipotéticos extremos. Aparecen rápidamente en producción.

• Semántica de marca de tiempo incorrecta
  Si loaded_at_field apunta a la marca de tiempo de un evento en lugar de a una marca de tiempo de llegada al almacén, dbt puede reportar que una tabla está fresca incluso cuando la ingesta se ha retrasado.

• Confusión de zonas horarias
  Si tus registros se almacenan en UTC pero tu lógica de comparación se ejecuta con respecto a la hora del sistema local, puedes generar falsas alertas de desactualización que acostumbren al equipo a ignorar las fallas de frescura.

• Escaneos pesados en tablas históricas
  En tablas grandes de datos sin procesar, una consulta de frescura sin un filtro útil puede desperdiciar recursos de cómputo y, aun así, no mostrar la historia operativa que te interesa en ese momento.

Qué cambiar cuando lo básico es estable

Una vez que las comprobaciones esenciales son confiables, puedes usar dbt de manera más selectiva.

Un patrón útil es construir solo a partir de fuentes que se hayan actualizado recientemente. El selector source_status:fresher+ ayuda a activar modelos río abajo desde fuentes que cambiaron, lo cual es muy adecuado cuando tu proyecto contiene una mezcla de sistemas río arriba de alta y baja frecuencia.

No trates cada comprobación de frescura como una alarma binaria. Algunas deberían ser reglas de control de acceso. Otras deberían ser reglas de enrutamiento para compilaciones selectivas.

Una lista de verificación práctica para robustecer el sistema

Cuando un equipo me pide que revise su configuración, suelo comprobar primero estos elementos:

• Indexa o optimiza la ruta de la marca de tiempo donde tu almacén de datos lo admita, especialmente en tablas de origen de gran tamaño.

• Estandariza en UTC las marcas de tiempo de carga almacenadas y mantén explícito el comportamiento de comparación.

• Agrega un filter para tablas históricas de gran tamaño para que dbt evalúe la ventana operativa reciente en lugar de escanear un historial irrelevante.

• Ajusta los umbrales después de observar el comportamiento de llegada real en lugar de definirlos permanentemente desde el primer día.

• Separa las fuentes críticas de las no críticas para que un flujo inestable y de poco valor no bloquee la entrega confiable de datos en el resto del sistema.

La función dbt source freshness es fácil de activar. Hacer que sea confiable requiere un poco más de criterio de ingeniería.

Más allá de la frescura: Construyendo un flujo de trabajo de Observability completo

Los umbrales estáticos de frescura resuelven un problema importante, pero no solucionan todo el problema de puntualidad de los datos.

Una fuente puede llegar "a tiempo" de acuerdo con error_after y, aun así, llegar lo suficientemente tarde como para alterar el trabajo de los analistas, los informes ejecutivos o la generación de funciones río abajo. Esa brecha se hace más clara en sistemas de producción reales donde los retrasos no se distribuyen de manera uniforme. El intervalo promedio puede parecer correcto mientras que retrasos graves y poco comunes continúan surgiendo exactamente en el peor momento.

La investigación resumida en las mejores prácticas de frescura de origen de Paradime apunta directamente a este problema desatendido: el 70% de los incidentes de datos desactualizados se deben a retrasos que superan en 3 veces el intervalo promedio, razón por la cual definir umbrales basados en el promedio o incluso en percentiles puede pasar por alto eventos importantes de retraso extremo.

Dónde se detiene dbt

dbt source freshness hace una pregunta directa: ¿es la marca de tiempo más reciente más antigua que el umbral?

Eso es útil, pero limitado. Por sí solo, no te dirá si un flujo que suele llegar a una hora predecible se está retrasando hoy, si los retrasos están empeorando con el tiempo o si una fuente es técnicamente "fresca" pero ya está incumpliendo la expectativa bajo la cual operan los usuarios de negocio.

Aquí es donde un Observability más amplio empieza a ser importante. Ya no solo estás probando la obsolescencia. Estás monitoreando el comportamiento de la puntualidad.

Qué añaden después los equipos maduros

Los equipos suelen expandirse en tres direcciones:

1. Monitoreo de puntualidad
   Hacen un seguimiento de cuándo se espera que lleguen los datos, no solo de si están desactualizados actualmente.

2. Aprendizaje de patrones
   Comparan la llegada de hoy con las normas históricas en lugar de depender únicamente de umbrales fijos.

3. Respuesta integrada
   Conectan las señales de frescura, esquema, anomalías y validación para que la respuesta ante incidentes comience con contexto.

Un ejemplo son los flujos de trabajo de Data Observability creados en torno al monitoreo dentro de la base de datos. La capacidad comprobada que importa aquí es que el componente de puntualidad de digna monitorea la llegada de datos frente a patrones aprendidos y programaciones de usuarios, y ejecuta análisis dentro de la base de datos del cliente en lugar de hacerlo mediante consultas externas, como se describe en la descripción general de puntualidad de digna. Eso lo convierte en una capa diferente a la comprobación de umbral estático de dbt, no en un reemplazo.

Un modelo de madurez práctico

La progresión suele verse así:

El modelo mental práctico es simple. dbt source freshness te dice cuándo una fuente está desactualizada. El monitoreo de puntualidad te ayuda a detectar cuándo se está retrasando.

Esa diferencia es fundamental en entornos donde una sola carga omitida o retrasada tiene un impacto desproporcionado, especialmente cuando los retrasos extremos ocurren de manera tan infrecuente como para eludir los umbrales simplistas, pero con la suficiente frecuencia como para seguir quebrando la confianza de la organización.

Si tu equipo ya usa dbt source freshness y quiere una mayor visibilidad de las llegadas tardías, validación a nivel de registro y flujos de trabajo de Observability dentro de la base de datos, digna es una opción a evaluar junto con tu infraestructura actual.