dbt (Data Build Tool): Qué es y cómo funciona. Guía práctica en español

¿Qué es dbt (Data Build Tool)?

dbt (Data Build Tool) es una herramienta open source que se ha convertido en el estándar de la industria para la transformación de datos dentro del data warehouse. A diferencia de las herramientas ETL tradicionales (como Informatica, Talend o Pentaho), dbt se centra exclusivamente en la T de ELT (Extract, Load, Transform): asume que los datos ya están cargados en el warehouse y se encarga de transformarlos usando SQL.

La propuesta de valor es sencilla pero potente: escribes sentencias SELECT en SQL, y dbt se encarga de convertirlas en tablas y vistas materializadas, gestionar las dependencias entre transformaciones, ejecutar tests de calidad, y generar documentación automática con linaje de datos. Todo ello con control de versiones vía Git, como si fuera código de software.

En este artículo te explicamos cómo funciona dbt, qué problemas resuelve, y cómo empezar a usarlo con un ejemplo práctico.

¿Por qué dbt ha revolucionado el data engineering?

Antes de dbt, las transformaciones de datos se gestionaban típicamente mediante herramientas ETL visuales (como Informatica, Talend, Pentaho o SSIS), scripts SQL sueltos sin versionado, o código Python/Spark personalizado. Estos enfoques presentaban problemas comunes:

• SQL disperso y sin documentar: queries repartidos en scripts sueltos, stored procedures, y herramientas ETL donde es difícil rastrear qué hace cada transformación.
• Dependencias frágiles: si cambias una tabla, no sabes qué reportes o modelos se rompen porque no hay un mapa de dependencias.
• Falta de testing: los datos se transforman sin validaciones automáticas, y los errores se descubren cuando un directivo ve cifras incorrectas en un dashboard.
• Sin control de versiones: no hay historial de quién cambió qué, ni posibilidad de hacer rollback.

dbt resuelve estos problemas aplicando principios de ingeniería de software al trabajo con datos:

Modularidad. Cada transformación es un "modelo" (un archivo .sql con una sentencia SELECT). Los modelos se referencian entre sí mediante la función ref(), lo que permite construir pipelines complejos de forma modular y reutilizable.

Versionado con Git. Todo el proyecto dbt se almacena en un repositorio Git. Cada cambio en la lógica de transformación queda registrado, se puede revisar mediante pull requests, y se puede revertir si causa problemas.

Tests automáticos. dbt incluye un framework de testing que permite definir validaciones sobre los datos: unicidad de claves, integridad referencial, valores no nulos, rangos válidos, y tests personalizados con SQL.

Documentación automática. Con los comandos dbt docs generate y dbt docs serve, dbt genera un sitio web de documentación completo que incluye la descripción de cada modelo, las columnas, el SQL compilado, y un grafo de linaje (lineage graph) interactivo que muestra cómo fluyen los datos a través de todos los modelos.

Materialización flexible. Cada modelo puede materializarse como tabla, vista, vista materializada o modelo incremental. Esto permite optimizar el rendimiento y los costes según el caso de uso.

Arquitectura y conceptos clave de dbt

Modelos

Un modelo en dbt es simplemente un archivo .sql que contiene una sentencia SELECT.

- Ejemplo de un modelo básico (models/staging/stg_clientes.sql):

SELECT
    id AS cliente_id,
    TRIM(nombre) AS nombre,
    LOWER(email) AS email,
    fecha_registro,
    CASE 
        WHEN tipo = 'E' THEN 'Empresa'
        WHEN tipo = 'P' THEN 'Particular'
        ELSE 'Desconocido'
    END AS tipo_cliente
FROM {{ source('crm', 'clientes_raw') }}

La función {{ source() }} referencia una tabla origen definida en un archivo YAML

La función ref()

La verdadera magia de dbt está en la función ref(). Cuando un modelo referencia a otro con {{ ref('stg_clientes') }}, dbt entiende automáticamente que existe una dependencia y construye el grafo de ejecución (DAG). No necesitas definir manualmente el orden de ejecución — dbt lo calcula.

-- models/marts/dim_clientes_activos.sql
SELECT
    c.cliente_id,
    c.nombre,
    c.tipo_cliente,
    COUNT(p.pedido_id) AS total_pedidos,
    SUM(p.importe) AS facturacion_total
FROM {{ ref('stg_clientes') }} c
LEFT JOIN {{ ref('stg_pedidos') }} p ON c.cliente_id = p.cliente_id
WHERE p.fecha_pedido >= DATEADD(month, -12, CURRENT_DATE)
GROUP BY 1, 2, 3

Capas de modelado o transformación

dbt recomienda organizar los modelos en capas (un patrón que ha dado excelentes resultados en la práctica):

Staging (stg_): Limpieza básica de los datos en crudo. Renombrado de columnas, casting de tipos, filtrado de registros eliminados. Un modelo staging por cada tabla fuente.

Intermediate (int_): Transformaciones intermedias que combinan múltiples fuentes staging. Joins, agregaciones parciales, cálculos de negocio intermedios.

Marts (dim_, fct_): Los modelos finales orientados al consumo. Tablas de dimensiones (dim_customers, dim_products) y tablas de hechos (fct_orders, fct_revenue) listas para ser consultadas por herramientas de BI o analistas.

Jinja y macros

dbt utiliza Jinja2 como motor de plantillas, lo que permite escribir SQL dinámico. Las macros son funciones reutilizables escritas en Jinja+SQL que evitan la duplicación de código. Por ejemplo, una macro para convertir timestamps a una zona horaria específica puede usarse en decenas de modelos sin repetir la lógica.

Tests

dbt soporta dos tipos de tests: los tests genéricos (unique, not_null, accepted_values, relationships) que se configuran en archivos YAML, y los tests singulares que son queries SQL personalizados que devuelven filas si hay un problema.

Ejemplo de tests declarativos en archivos YAML:

# models/staging/schema.yml
models:
  - name: stg_clientes
    columns:
      - name: cliente_id
        tests:
          - unique
          - not_null
      - name: email
        tests:
          - unique
      - name: tipo_cliente
        tests:
          - accepted_values:
              values: ['Empresa', 'Particular', 'Desconocido']

Cuando ejecutas dbt test, dbt genera y ejecuta queries que validan cada condición. Si un test falla, lo sabes antes de que los datos lleguen a producción.

Seeds y snapshots

Seeds son archivos CSV que se cargan directamente en el warehouse — útiles para datos de referencia pequeños (códigos de país, mapeos de categorías). Snapshots capturan el estado histórico de tablas que cambian, implementando Slowly Changing Dimensions de forma automática.

Documentación y linaje

Con dbt docs generate y dbt docs serve, dbt genera un sitio web navegable con toda la documentación del proyecto, incluyendo un grafo interactivo de dependencias (DAG) que muestra cómo fluyen los datos desde las fuentes originales hasta los marts finales. Esta documentación se actualiza automáticamente cada vez que cambias un modelo.

dbt Core vs dbt Cloud

dbt se distribuye en dos versiones:

dbt Core es la versión open source, gratuita, que se ejecuta desde la línea de comandos. Se instala con pip install dbt-core más el adaptador correspondiente a tu warehouse (por ejemplo, dbt-snowflake, dbt-bigquery, dbt-postgres). Es la opción preferida por equipos técnicos que quieren control total sobre su infraestructura.

dbt Cloud es la versión SaaS gestionada por dbt Labs. Incluye un IDE web, programación de ejecuciones, CI/CD integrado, gestión de entornos, y hosting de documentación. Tiene un plan gratuito para desarrolladores individuales y planes de pago para equipos.

Para empezar, dbt Core es más que suficiente. Si tu equipo crece o necesitas orquestación en producción, dbt Cloud simplifica enormemente la operación.

Bases de datos compatibles

dbt funciona con los principales data warehouses del mercado a través de adaptadores:

• Snowflake — Integración nativa, rendimiento excelente
• BigQuery (Google Cloud) — Soporte completo
• Redshift (AWS) — Soporte completo
• Databricks / Spark — Adaptador oficial
• PostgreSQL — Ideal para desarrollo local y proyectos pequeños
• DuckDB — Perfecto para pruebas locales sin servidor
• SQL Server / Azure Synapse — Adaptadores de la comunidad

Cómo empezar con dbt: tu primer proyecto

Requisitos previos

Para seguir esta guía necesitas: Python 3.8 o superior instalado, acceso a un data warehouse (PostgreSQL local sirve para empezar), y familiaridad básica con SQL y la línea de comandos.

Paso 1: Instalación

# Crear un entorno virtual (recomendado)
python -m venv dbt-env
source dbt-env/bin/activate  # Linux/Mac
# dbt-env\Scripts\activate   # Windows

# Instalar dbt con el adaptador de tu base de datos
pip install dbt-postgres
# Otros: dbt-snowflake, dbt-bigquery, dbt-duckdb, dbt-sqlserver

# Verificar la instalación
dbt --version

Paso 2: Crear un nuevo proyecto

# Inicializar un proyecto nuevo
dbt init mi_proyecto_dbt

# Navegar al directorio del proyecto y verificar la conexión
cd mi_proyecto_dbt
dbt deug

dbt te pedirá seleccionar el tipo de base de datos y creará la estructura de directorios estándar con carpetas para models, tests, macros, seeds y snapshots, y los archivos de configuración dbt_project.yml y profiles.yml.

Paso 3: Configurar la conexión

Edita el archivo ~/.dbt/profiles.yml con los datos de conexión a tu data warehouse:

mi_proyecto_dbt:
  target: dev
  outputs:
    dev:
      type: postgres
      host: localhost
      user: mi_usuario
      password: mi_password
      port: 5432
      dbname: mi_base_datos
      schema: dbt_dev
      threads: 4

# Verificar la conexión
dbt debug

Paso 4: Crear tu primer modelo

Creamos un modelo staging que limpia los datos crudos de pedidos:

-- models/staging/stg_pedidos.sql
WITH source AS (
    SELECT * FROM {{ source('raw', 'pedidos') }}
)
SELECT
    id AS pedido_id,
    cliente_id,
    CAST(fecha AS DATE) AS fecha_pedido,
    ROUND(importe, 2) AS importe,
    CASE estado
        WHEN 'C' THEN 'Completado'
        WHEN 'P' THEN 'Pendiente'
        WHEN 'X' THEN 'Cancelado'
    END AS estado
FROM source
WHERE importe > 0

Y un modelo mart que calcula métricas de negocio:

-- models/marts/fct_ventas_mensuales.sql
SELECT
    DATE_TRUNC('month', fecha_pedido) AS mes,
    COUNT(DISTINCT cliente_id) AS clientes_activos,
    COUNT(pedido_id) AS total_pedidos,
    SUM(importe) AS facturacion,
    AVG(importe) AS ticket_medio
FROM {{ ref('stg_pedidos') }}
WHERE estado = 'Completado'
GROUP BY 1
ORDER BY 1

Paso 5: Ejecutar y documentar

# Ejecutar todos los modelos
dbt run

# Ejecutar los tests
dbt test

# Generar y servir la documentación
dbt docs generate
dbt docs serve

Al ejecutar dbt docs serve, se abrirá un navegador con la documentación completa del proyecto, incluyendo el grafo de linaje interactivo.

dbt en el ecosistema moderno de datos

dbt no trabaja solo — se integra como la capa de transformación dentro de un stack de datos más amplio:

Ingesta: Airbyte, Fivetran, Stitch, o herramientas ETL tradicionales cargan los datos en bruto al warehouse.

Almacenamiento: Snowflake, BigQuery, Redshift, Databricks o PostgreSQL almacenan tanto los datos en bruto como los transformados.

Transformación: dbt transforma los datos en bruto en modelos analíticos listos para consumo.

Orquestación: Apache Airflow, Dagster o Prefect programan y coordinan las ejecuciones de dbt junto con otros procesos.

Visualización: Power BI, Tableau, Looker, Metabase o Superset consumen los modelos dbt para crear dashboards y análisis.

Casos de uso: cuándo usar dbt

dbt es especialmente potente cuando necesitas: consolidar datos de múltiples fuentes en un warehouse centralizado, crear una capa semántica con métricas de negocio consistentes, implementar data quality checks automatizados, documentar el linaje y la lógica de transformación de datos, o migrar pipelines ETL legacy a un enfoque ELT moderno.

Este último caso es particularmente relevante. Hay consultoras especializadas de Business Intelligence que ya están utilizando dbt junto con herramientas de IA como Claude Code para migrar stacks ETL legacy (Pentaho, SSIS, Informatica) a arquitecturas modernas con dbt + Snowflake, logrando reducir los tiempos de migración en más de un 80%.

Este enfoque es especialmente relevante para organizaciones con grandes inversiones en stacks legacy que quieren modernizar sin asumir el riesgo de una reescritura manual completa.

Recursos para seguir aprendiendo

La documentación oficial de dbt es excelente y está en continua actualización. El apartado de buenas prácticas es de lectura obligatoria antes de empezar un proyecto real. La comunidad de dbt es muy activa, con más de 100.000 miembros en su Slack y una conferencia anual (Coalesce) con sesiones técnicas de alto nivel.

Conclusión

dbt ha cambiado la forma en que equipos de datos trabajan con transformaciones SQL. Su enfoque modular, la integración con Git, los tests automáticos y la documentación generada hacen que sea la herramienta estándar de facto para la capa de transformación en arquitecturas de datos modernas. Si ya sabes SQL, la curva de aprendizaje es suave y los beneficios son inmediatos. En próximos artículos de Dataprix profundizaremos en casos de uso avanzados, incluyendo la migración de ETL legacy a dbt con ayuda de herramientas de IA.