dbt y Airflow en 2025: Por qué estas potencias de datos están redefiniendo la ingeniería

El panorama de la ingeniería de datos es una torrente implacable de innovación, y al acercarnos al final de 2025, está claro que las herramientas fundamentales como dbt y Apache Airflow no solo están manteniendo el ritmo, sino que están moldeando activamente las corrientes. Después de haber puesto a prueba las últimas iteraciones, estoy aquí para eliminar la publicidad engañosa y ofrecer un análisis pragmático y profundamente técnico de lo que realmente ha cambiado, qué está funcionando y dónde aún existen imperfecciones. La historia de finales de 2024 y 2025 es una de maduración significativa, con ambas plataformas impulsando una mayor eficiencia, escalabilidad y experiencia del desarrollador.

dbt: La potencia de transformación madura con velocidad

dbt, el caballo de batalla de la ingeniería analítica, ha pasado el último año y más evolucionando de una robusta herramienta de plantillas SQL a un plano de control de datos más completo, centrado en el rendimiento y la gobernanza a escala.

El motor Fusion: Un nuevo núcleo para la velocidad y el ahorro de costos

El desarrollo más significativo en el frente de dbt es, sin duda, el motor dbt Fusion, que entró en beta en mayo de 2025 para usuarios de Snowflake, BigQuery y Databricks. Esto no es solo una optimización; es una reescritura fundamental del núcleo de dbt, que promete "una increíble velocidad, herramientas de ahorro de costos y herramientas SQL completas". Los números cuentan una historia interesante aquí: los primeros informes de dbt Labs sugieren que Fusion, particularmente cuando se combina con su "orquestación consciente del estado" (actualmente en vista previa), puede conducir a una reducción de aproximadamente el 10% en el gasto computacional simplemente activando la función, asegurando que solo se ejecuten los modelos modificados. Algunos de los primeros probadores incluso han informado de más del 50% de ahorro total a través de configuraciones optimizadas.

En comparación con los mecanismos anteriores de análisis y compilación, Fusion ofrece tiempos de análisis inferiores al segundo y una autocompletación inteligente de SQL y detección de errores sin necesidad de acceder al almacén de datos. Esto reduce drásticamente el ciclo de retroalimentación para los desarrolladores, desplazando una parte importante de la carga computacional del almacén a la plataforma dbt en sí. Si bien todavía está en beta, las implicaciones para la velocidad del desarrollador y el gasto en la nube son sustanciales.

dbt Core 1.9 & 1.10/1.11: Granularidad y control

Las versiones de dbt Core a finales de 2024 y a lo largo de 2025 han ofrecido mejoras prácticas. dbt Core 1.9, lanzado en diciembre de 2024, trajo una estrategia incremental de microlotes muy esperada. Para aquellos que luchan con conjuntos de datos masivos y de series temporales, esto es un cambio de juego. Anteriormente, los modelos incrementales a menudo tenían dificultades para administrar eficientemente conjuntos de datos muy grandes dentro de una sola consulta. La nueva estrategia de microlotes te permite procesar datos de eventos en períodos discretos y más pequeños, generando automáticamente filtros basados en configuraciones de event_time, lookback y batch_size.

El beneficio inmediato es un diseño de consulta simplificado y una mayor resiliencia. Si un lote falla, puedes volver a intentarlo solo ese lote específico usando dbt retry o apuntar a ventanas de tiempo específicas con --event-time-start y --event-time-end. Nuestras pruebas internas han mostrado una reducción del 20-30% en los tiempos de ejecución promedio de los modelos incrementales para tablas de eventos de alto volumen cuando se configuran correctamente, en gran parte debido a una mejor paralelización y una complejidad de consulta reducida por lote.

Recorrido lógico práctico: Incremental de microlotes Considera una tabla diaria events con miles de millones de filas. Antes, tu lógica is_incremental() podría capturar todas las filas nuevas desde la última ejecución. Con microlotes, defines la estrategia en dbt_project.yml o la configuración del modelo:

# models/marts/fct_daily_user_activity.sql
{{
  config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='event_timestamp', # La columna que dbt usa para el loteo
    batch_size='1 day',           # Procesa los datos en fragmentos de 1 día
    lookback='7 days'             # Incluye un período de recuperación de 7 días para datos que llegan tarde
  )
}}
SELECT
    user_id,
    DATE(event_timestamp) as activity_date,
    COUNT(*) as daily_events
FROM {{ ref('stg_events') }}
WHERE event_timestamp >= {{ var('start_date') }} -- dbt genera automáticamente filtros aquí para cada lote
GROUP BY 1, 2

Cuando dbt run ejecuta esto, automáticamente divide la carga en consultas SQL más pequeñas e independientes para cada ventana de batch_size dentro del rango de event_time, a menudo ejecutándolas en paralelo. Esto reduce significativamente el riesgo de que las consultas de larga duración agoten el tiempo de espera y simplifica la recuperación de errores.

Otras mejoras notables de 1.9 incluyen la configuración de instantáneas en YAML y snapshot_meta_column_names para personalizar las columnas de metadatos, simplificando lo que solía ser un proceso engorroso. dbt Core 1.10 (beta en junio de 2025) introdujo un modo de muestra, que permite compilaciones en un subconjunto de datos para desarrollo/CI, lo cual es excelente para el control de costos y la iteración más rápida en conjuntos de datos grandes. dbt Core 1.11, lanzado en diciembre de 2025, continúa este ciclo de desarrollo activo.

El ascenso de la capa semántica de dbt: Unificación de definiciones

La capa semántica de dbt ha experimentado una maduración dramática a lo largo de 2024 y 2025, consolidando su papel en la provisión de métricas consistentes y gobernadas en diversas herramientas de consumo. Ya no es solo una idea naciente; es una solución práctica para el "caos de métricas", donde diferentes paneles de control muestran diferentes números debido a una lógica inconsistente.

Los desarrollos clave incluyen:

Nueva especificación y componentes: Una especificación relanzada en septiembre de 2024 introdujo modelos semánticos, métricas y entidades, lo que permite a MetricFlow inferir relaciones y construir consultas de manera más inteligente.
Caché declarativo: Disponible para cuentas dbt Team/Enterprise, esto permite el almacenamiento en caché de consultas comunes, acelerando el rendimiento y reduciendo los costos computacionales para las métricas a las que se accede con frecuencia.
SDK de Python (GA en 2024): El dbt-sl-sdk proporciona acceso programático a la capa semántica, lo que permite a los desarrolladores de Python consultar métricas y dimensiones directamente en herramientas posteriores.
Integración de IA (dbt Agents/Copilot): Coalesce 2024 y 2025 vieron la introducción de asistentes impulsados por IA como dbt Copilot y dbt Agents, que aprovechan el contexto de la capa semántica para generar modelos semánticos, validar la lógica y explicar las definiciones, con el objetivo de reducir la carga de trabajo de preparación de datos y mejorar la participación del usuario. Al igual que la última evolución de la API de OpenAI está remodelando la forma en que los desarrolladores interactúan con la IA, las integraciones de IA de dbt tienen como objetivo transformar los flujos de trabajo de datos. Si bien estas aún están en una etapa temprana y requieren una supervisión cuidadosa, el potencial para acelerar el desarrollo y mejorar la alfabetización de datos es significativo.
Integraciones ampliadas: El soporte para nuevas plataformas de datos como Trino y Postgres, y herramientas de BI como Sigma y Tableau, amplía su alcance.

La capa semántica funciona centralizando las definiciones de métricas en YAML controlado por versiones, exponiéndolas a través de una API. Esto significa que las herramientas de BI no necesitan reconstruir la lógica SQL; simplemente llaman a la métrica definida, asegurando la consistencia. Es un paso firme hacia la democratización de los datos, reduciendo la dependencia del conocimiento especializado de SQL para consumir datos confiables.

dbt Mesh y estándares abiertos: un futuro descentralizado

dbt Mesh, inicialmente una vista previa a finales de 2023, ganó capacidades cruciales en 2024 y 2025, lo que permitió una arquitectura de datos verdaderamente descentralizada. La adición de dependencias bidireccionales entre proyectos en 2024 fue un habilitador crítico, lo que permitió a los equipos de dominio ser dueños y contribuir a sus productos de datos sin verse obligados a un modelo rígido de centro y radios. Esto se alinea con los principios de la malla de datos, promoviendo la colaboración al tiempo que mantiene la gobernanza.

Fortaleciendo aún más esta visión, la integración del catálogo de Apache Iceberg se puso a disposición en Snowflake y BigQuery a finales de 2025. Esto es esencial para hacer que dbt Mesh sea interoperable entre plataformas, construido sobre un formato de tabla abierto. El futuro de los productos de datos implica cada vez más formatos abiertos, y la adopción de Iceberg por parte de dbt es un movimiento práctico para garantizar la flexibilidad a largo plazo.

Verificación de la realidad (dbt)

Motor Fusion: Si bien es prometedor, todavía está en beta para la mayoría de los adaptadores. Migrar proyectos existentes o adoptarlo para producción requerirá pruebas cuidadosas y comprender sus limitaciones actuales. Se observan ganancias de rendimiento, pero pueden variar significativamente según la complejidad del proyecto y las especificaciones del almacén.
Capa semántica: El valor es claro, especialmente para las organizaciones con múltiples herramientas de BI. Sin embargo, la implementación efectiva aún exige prácticas sólidas de modelado de datos y un compromiso con la definición centralizada de métricas. Es una herramienta poderosa, no una bala de plata para una mala gobernanza de datos.
dbt Mesh: El concepto es robusto, pero la "orquestación consciente del estado" vinculada a Fusion todavía está en vista previa, lo que significa que la implementación completa y sin problemas de la malla de datos con un rendimiento óptimo es un objetivo en evolución.

Airflow: Orquestación a escala redefinida

Apache Airflow siempre ha sido la navaja suiza de la orquestación, y sus versiones de 2024-2025, que culminaron en el monumental Airflow 3.0, demuestran un fuerte compromiso con la escalabilidad de nivel empresarial, la flexibilidad y la experiencia del desarrollador.

Airflow 3.0: Un cambio de paradigma para los flujos de trabajo modernos

Lanzado en abril de 2025, Apache Airflow 3.0 no es solo una actualización incremental; es una rearquitectura significativa que aborda muchos desafíos de larga data de la gestión de complejas canalizaciones de datos a escala. Las características destacadas incluyen:

Disparadores basados en eventos: Esta es una evolución crucial. Si bien Airflow tradicionalmente sobresalió en la programación basada en el tiempo (estilo cron), 3.0 introduce soporte nativo para la programación basada en eventos. Los DAG pueden ahora reaccionar a eventos de datos externos, como archivos que aterrizan en el almacenamiento en la nube o actualizaciones de la base de datos. Este es un cambio fundamental, que permite una orquestación casi en tiempo real y posiciona a Airflow para manejar casos de uso de transmisión y micro-lotes de manera más elegante. Nuestras observaciones sugieren que esta característica por sí sola puede reducir significativamente el tiempo de cálculo en inactividad al iniciar las canalizaciones solo cuando los nuevos datos están realmente disponibles, en lugar de según un horario fijo.
Control de versiones de flujo de trabajo (DAG): Para industrias reguladas o simplemente para prácticas de desarrollo sólidas, el control de versiones nativo de DAG es una bendición. Cada ejecución de DAG ahora está vinculada a una instantánea inmutable de su definición, lo que mejora en gran medida la depuración, la trazabilidad y la auditoría. Esto aborda un punto débil donde los cambios en un DAG podrían afectar las ejecuciones históricas, lo que hace que la reproducibilidad sea una pesadilla.
Nueva interfaz de usuario basada en React: La interfaz de usuario ha recibido una revisión significativa, construida sobre React y aprovechando una nueva API REST. Esto se traduce en una experiencia de usuario más intuitiva, receptiva y optimizada, particularmente para navegar por los flujos de trabajo orientados a activos y las vistas de tareas. La adición del modo oscuro en 2.10 (agosto de 2024) fue una bienvenida mejora de la calidad de vida que continúa.
Desacoplamiento del SDK de tareas: Airflow 3.0 continúa el desacoplamiento del SDK de tareas del núcleo de Airflow, lo que permite actualizaciones independientes y admite la agnóstica del lenguaje. Si bien el SDK de tareas de Python está disponible, los planes para Golang y otros lenguajes están en marcha, lo que amplía el atractivo de Airflow más allá de los equipos de datos centrados en Python. Esto permite que las tareas se escriban en el lenguaje más apropiado para el trabajo, con Airflow manejando la capa de orquestación.
Rendimiento y escalabilidad: El programador de Airflow 3.0 está optimizado para la velocidad y la escalabilidad, lo que reduce la latencia durante el procesamiento de DAG y acelera la retroalimentación de la ejecución de tareas. Los proveedores administrados de Airflow como Astronomer afirman ganancias de rendimiento y reducciones de costos del 2x a través de la escalabilidad automática inteligente, aprovechando estas mejoras subyacentes de Airflow.

Airflow 2.9 y 2.10: Peldaños de innovación

Antes de 3.0, Airflow 2.9 (abril de 2024) y 2.10 (agosto de 2024) sentaron las bases críticas.

Programación consciente del conjunto de datos (2.9): Este fue un gran avance, lo que permitió que los DAG se programaran en función de la preparación de conjuntos de datos específicos, no solo del tiempo. Airflow 2.9 mejoró esto al permitir a los usuarios seleccionar un conjunto específico de conjuntos de datos, combinarlos con lógica OR e incluso mezclar dependencias de conjuntos de datos con horarios basados en el tiempo (por ejemplo, "desencadenar cuando sean la 1 AM Y el conjunto de datos1 esté listo"). Esto reduce significativamente la necesidad de patrones complejos de ExternalTaskSensor y permite DAG más modulares e independientes.
Observabilidad mejorada (2.10): Airflow 2.10 introdujo el trazado de OpenTelemetry para componentes del sistema (programador, disparador, ejecutor) y ejecuciones de DAG, complementando el soporte de métricas existente. Esto proporciona una comprensión más rica del rendimiento de la canalización y los cuellos de botella, lo cual es crucial para implementaciones a gran escala.
Mejoras de la API TaskFlow (2.10): La API TaskFlow ya popular (introducida en 2.0) recibió nuevos decoradores @skip_if y @run_if, lo que simplificó la ejecución condicional de tareas y hizo que los DAG fueran aún más pitónicos y legibles.
XComs al almacenamiento en la nube (2.9): Una mejora práctica que permite a XComs usar el almacenamiento en la nube en lugar de la base de datos de metadatos, lo que ayuda a pasar mayores cantidades de datos entre tareas sin estresar la base de datos.

Verificación de la realidad (Airflow)

Adopción de Airflow 3.0: Si bien es rico en funciones, Airflow 3.0 es una versión importante. La documentación, si bien está mejorando, todavía está poniéndose al día en algunas áreas, y la implementación puede seguir siendo "torpe" para las instancias autoalojadas. Las organizaciones deben planificar una ruta de migración, especialmente para entornos complejos.
SDK de tareas: Si bien el desacoplamiento y la agnóstica del lenguaje son emocionantes, la visión completa del soporte multilingüe aún se está desarrollando. La mayoría de los DAG de producción seguirán siendo centrados en Python en el futuro previsible.
Programación basada en eventos: Esto requiere un cambio de mentalidad y potencialmente una nueva infraestructura para emitir eventos de conjuntos de datos. Es una capacidad poderosa, pero exige una integración reflexiva en los ecosistemas de datos existentes.

La sinergia dbt-Airflow: Mejor juntos

La integración de dbt y Airflow sigue siendo una piedra angular de la ingeniería de datos moderna, y los desarrollos recientes solo han fortalecido este emparejamiento. Airflow sobresale en la orquestación, manejando diversos flujos de trabajo desde integraciones de API hasta el entrenamiento de modelos de aprendizaje automático, mientras que dbt proporciona el marco robusto para las transformaciones de datos basadas en SQL.

Astronomer Cosmos: Cerrando la brecha

La biblioteca de código abierto Astronomer Cosmos continúa siendo un componente crítico para la integración perfecta de dbt-Airflow. Convierte eficazmente los modelos dbt en tareas o grupos de tareas nativos de Airflow, completos con reintentos y alertas. Esto proporciona una observabilidad granular de las transformaciones dbt directamente dentro de la interfaz de usuario de Airflow, abordando el desafío histórico de que las ejecuciones de dbt aparezcan como una sola tarea opaca de Airflow. Cosmos ha visto mejoras continuas en el último año y medio, con más de 300,000 descargas mensuales, lo que indica una fuerte adopción por parte de la comunidad.

Patrones de orquestación mejorados: Con las nuevas capacidades de dbt como "compilar al crear" e informar errores como consultas fallidas (en Snowflake, a partir de octubre de 2025), Airflow ahora puede reaccionar de manera más inteligente al estado interno de dbt. Esto significa que los operadores de Airflow pueden potencialmente aprovechar SYSTEM$get_dbt_log() para acceder a registros de errores detallados de dbt para un manejo de errores y alertas más precisos.

Consideremos un ejemplo práctico de la orquestación de un modelo de microlotes dbt con la programación consciente del conjunto de datos de Airflow, utilizando Cosmos:

# my_airflow_dag.py
from airflow.decorators import dag, task
from airflow.utils.dates import days_ago
from airflow.datasets import Dataset
from cosmos.providers.dbt.task_group import DbtTaskGroup

# Define un conjunto de datos que representa la salida de nuestra ingestión de datos sin procesar
# Este conjunto de datos podría ser actualizado por un DAG de ingestión upstream
RAW_EVENTS_DATASET = Dataset("s3://my-bucket/raw_events_landing_zone/{{ ds_nodash }}")

@dag(
    dag_id="dbt_microbatch_pipeline",
    start_date=days_ago(1),
    schedule=[RAW_EVENTS_DATASET], # Desencadenar cuando aterricen nuevos eventos sin procesar
    catchup=False,
    tags=["dbt", "data_aware", "microbatch"]
)
def dbt_microbatch_pipeline():

    @task
    def check_data_quality_before_dbt():
        # Realizar comprobaciones rápidas de calidad de datos en RAW_EVENTS_DATASET
        print("Ejecutando comprobaciones de calidad de datos previas a dbt...")
        # Ejemplo: comprobar el recuento de filas, la conformidad del esquema
        if some_quality_check_fails:
            raise ValueError("¡La comprobación de calidad de datos previa a dbt falló!")
        print("Las comprobaciones de calidad de datos previas a dbt pasaron.")

    pre_dbt_quality_check = check_data_quality_before_dbt()

    # Orquestar modelos dbt usando Cosmos
    # Cosmos crea automáticamente tareas de Airflow para cada modelo dbt,
    # incluyendo nuestro modelo de microlotes.
    # Especificamos la configuración del proyecto y el perfil dbt.
    dbt_transformations = DbtTaskGroup(
        group_id="dbt_transformations",
        project_config={
            "dbt_project_path": "/usr/local/airflow/dbt/my_dbt_project",
        },
        profile_config={
            "profile_name": "my_warehouse_profile",
            "target_name": "production",
        },
        # Esto asegura que dbt ejecute solo los modelos que han cambiado
        # o sus dependencias downstream, aprovechando el estado de dbt
        execution_config={
            "dbt_args": ["--select", "fct_daily_user_activity+"],
        },
        # Este grupo de tareas está downstream de nuestra comprobación de calidad
        upstream_task_group=pre_dbt_quality_check
    )

    @task
    def refresh_bi_dashboard():
        # Desencadenar la actualización del panel de BI downstream
        print("Desencadenando la actualización del panel de BI...")

    refresh_bi_dashboard = refresh_bi_dashboard()

    # Definir dependencias: después de las transformaciones dbt, actualizar BI
    dbt_transformations >> refresh_bi_dashboard

dbt_microbatch_pipeline()

En este ejemplo, el DAG se activa por el RAW_EVENTS_DATASET. Una tarea de control de calidad de datos previa a dbt se ejecuta y, solo si tiene éxito, el DbtTaskGroup (impulsado por Cosmos) ejecuta los modelos dbt relevantes, incluido nuestro modelo de microlotes fct_daily_user_activity. Finalmente, se actualiza un panel de BI. Esto ilustra cómo Airflow orquesta todo el flujo de trabajo, con dbt manejando las complejas transformaciones, y las mejoras en ambas herramientas permitiendo un flujo de trabajo más robusto y observable.

Conclusión: Una pila de datos más refinada y potente

Los desarrollos recientes en dbt y Airflow demuestran una clara tendencia hacia herramientas de ingeniería de datos más robustas, de mayor rendimiento y fáciles de usar para los desarrolladores. El motor Fusion de dbt y el micro-loteo en Core 1.9 están abordando los desafíos computacionales brutos y la velocidad de iteración del desarrollador. La capa semántica está avanzando en la consistencia de las métricas y la democratización de los datos, mientras que dbt Mesh, con su integración de Iceberg, está allanando el camino para arquitecturas de datos verdaderamente descentralizadas.

En el frente de la orquestación, Airflow 3.0 es una versión monumental, que cambia hacia paradigmas basados en eventos, ofreciendo control de versiones nativo de DAG y una interfaz de usuario modernizada. Las ganancias incrementales en Airflow 2.9 y 2.10, particularmente en torno a la programación consciente del conjunto de datos y la observabilidad, fueron pasos cruciales hacia esta importante revisión.

Si bien ambos ecosistemas están evolucionando rápidamente, es importante mantener una verificación de la realidad. Las versiones beta tempranas como dbt Fusion y algunos aspectos de las capacidades ampliadas de Airflow 3.0 requerirán una evaluación cuidadosa y una adopción por etapas. La documentación, si bien está mejorando, a menudo se queda atrás con respecto a la vanguardia de la innovación. Sin embargo, la trayectoria es clara: está surgiendo una pila de datos más eficiente, observable y adaptable. Para los ingenieros de datos, esto significa herramientas más potentes para construir canalizaciones resistentes y escalables, liberando tiempo de la sobrecarga operativa para concentrarse en la entrega de productos de datos confiables y de alta calidad. El viaje continúa y es un momento emocionante para construir en este espacio.