dbt para analistas: transforma datos con SQL

dbt (data build tool) permite a los analistas transformar datos crudos dentro de un data warehouse usando solo sentencias SELECT de SQL, control de versiones y unos cuantos archivos YAML. Escribes un modelo por cada concepto de negocio, dbt calcula en qué orden construirlos, prueba los resultados y genera la documentación. Si ya sabes SQL, dbt es el camino más corto para pasar de "persona que escribe consultas" a "persona que construye pipelines de datos confiables".

Qué es dbt (y qué no es)

dbt vive en la T de ELT. Tus datos ya están cargados en un warehouse como Snowflake, BigQuery, Databricks, Redshift, PostgreSQL o Microsoft Fabric. dbt se conecta a ese warehouse, ejecuta tu SQL allí y guarda el resultado como tablas o vistas. No extrae datos de los sistemas de origen ni dibuja gráficos. Piénsalo como la capa que convierte tablas crudas y desordenadas en tablas limpias y probadas en las que Power BI, Tableau o Excel pueden confiar.

Si todavía no tienes clara la diferencia entre ETL y ELT, lee primero ETL vs ELT; dbt cobra sentido cuando entiendes por qué los equipos modernos cargan primero y transforman después.

dbt Core vs la plataforma dbt

Hay dos formas principales de usar dbt:

• dbt Core es la herramienta de línea de comandos de código abierto. Se instala con Python, editas los archivos en cualquier editor (VS Code es muy popular) y ejecutas comandos en una terminal.
• La plataforma dbt (antes llamada dbt Cloud) es el producto alojado de dbt Labs. Agrega un editor en el navegador, programación de trabajos, documentación publicada y funciones para equipos. dbt Labs también ha ido lanzando un motor nuevo llamado Fusion, con análisis más rápido y validación de SQL más inteligente.

Los planes, las versiones gratuitas y la disponibilidad del motor cambian con frecuencia, así que revisa las páginas oficiales de precios y documentación de dbt Labs antes de decidir. Para aprender, dbt Core en tu propia computadora no cuesta nada.

Por qué a los analistas les encanta dbt

Antes de dbt, muchos equipos guardaban la lógica de negocio en un enredo de consultas guardadas, procedimientos almacenados y pasos de Power Query que solo una persona entendía. dbt trae hábitos de ingeniería de software a la analítica sin obligarte a aprender un lenguaje nuevo:

• Modularidad: cada modelo es un archivo SQL. Los modelos se referencian entre sí con ref(), así que la lógica se escribe una vez y se reutiliza.
• Orden de dependencias automático: dbt lee las llamadas a ref() y arma un grafo (un DAG), de modo que las tablas siempre se construyen en la secuencia correcta.
• Pruebas: declaras reglas como "order_id es único" o "status es uno de estos valores" y dbt las verifica en cada ejecución.
• Documentación: las descripciones viven junto al código y dbt genera un sitio navegable con un diagrama de linaje.
• Control de versiones: todo es texto, así que vive en Git con revisiones e historial.

Tu primer proyecto de dbt, paso a paso

Este es un flujo mínimo con dbt Core y PostgreSQL. Las mismas ideas sirven para cualquier warehouse compatible; solo cambia el adaptador.

1. Instala dbt y un adaptador en un entorno virtual de Python: python -m pip install dbt-core dbt-postgres.
2. Crea un proyecto con dbt init shop_analytics. dbt te pide los datos de conexión y los guarda en ~/.dbt/profiles.yml, fuera de la carpeta del proyecto, para que las contraseñas nunca lleguen a Git.
3. Verifica la conexión con dbt debug.
4. Declara tus fuentes (las tablas crudas) en un archivo YAML.
5. Escribe modelos de staging que limpian y renombran las columnas crudas.
6. Escribe modelos de marts que unen y agregan los modelos de staging en tablas listas para el negocio.
7. Ejecuta y prueba con dbt build, que corre modelos y pruebas en orden de dependencias.

Un modelo de staging

Los modelos de staging son delgados: uno por tabla de origen, con cambios de nombre, conversión de tipos y limpieza ligera. Guarda esto como models/staging/stg_orders.sql:

select
    id                      as order_id,
    customer_id,
    cast(order_date as date) as order_date,
    lower(status)           as status,
    amount_cents / 100.0    as amount
from {{ source('shop', 'raw_orders') }}
where id is not null

La función {{ source() }} apunta a una tabla cruda declarada en YAML. Las llaves dobles son Jinja, un lenguaje de plantillas que dbt usa para hacer el SQL dinámico.

Un modelo de mart

Los marts responden preguntas de negocio. Guarda esto como models/marts/fct_customer_revenue.sql:

with orders as (
    select * from {{ ref('stg_orders') }}
    where status = 'completed'
)

select
    customer_id,
    count(*)          as order_count,
    sum(amount)       as lifetime_revenue,
    min(order_date)   as first_order_date,
    max(order_date)   as last_order_date
from orders
group by customer_id

Como este modelo usa ref('stg_orders'), dbt sabe que primero debe construir stg_orders. El estilo con CTE que ves aquí es el estándar en proyectos de dbt; si los CTE son nuevos para ti, revisa CTE y subconsultas en SQL.

Fuentes y pruebas en YAML

Guarda esto como models/staging/_shop.yml:

version: 2

sources:
  - name: shop
    schema: raw
    tables:
      - name: raw_orders

models:
  - name: stg_orders
    description: "One row per order, cleaned from raw_orders."
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null
      - name: status
        data_tests:
          - accepted_values:
              values: ['placed', 'shipped', 'completed', 'returned']

Las versiones recientes de dbt usan la clave data_tests; los proyectos más antiguos usan tests, que todavía funciona. Ejecuta dbt build y dbt crea ambos modelos y corre las tres pruebas. Si mañana aparece un ID de pedido duplicado, la prueba falla y te enteras antes de que tu dashboard muestre ingresos equivocados.

Materializaciones: vistas, tablas y modelos incrementales

Una materialización le dice a dbt cómo guardar un modelo en el warehouse.

Se define al inicio de un modelo con {{ config(materialized='table') }} o para una carpeta completa en dbt_project.yml. Un patrón común es usar vistas para staging y tablas para marts.

Cómo organizar un proyecto de dbt

La mayoría de los equipos sigue una estructura de tres capas:

• staging/: un modelo por tabla de origen, con el prefijo stg_.
• intermediate/: joins y lógica de negocio reutilizable (opcional), con el prefijo int_.
• marts/: tablas finales de hechos y dimensiones (fct_, dim_) que alimentan las herramientas de BI.

Esta organización encaja muy bien con un esquema de estrella, que es con lo que mejor trabaja Power BI. Las ideas de modelado dimensional de Fundamentos de data warehouse se aplican directamente a tu carpeta de marts.

Errores comunes de principiante

• Escribir nombres de tablas fijos en lugar de usar ref() y source(). Pierdes el grafo de dependencias y la posibilidad de cambiar de entorno.
• Meter todo en un solo modelo gigante. Divide la lógica en staging y marts para poder probar cada pieza.
• Saltarse las pruebas y las descripciones. Toman minutos y son la razón principal por la que un proyecto de dbt sigue siendo confiable a medida que crece.
• Desarrollar directamente en producción. Usa un esquema de desarrollo personal (definido en tu perfil) y lleva los cambios a producción mediante Git.

Las pruebas de dbt son solo una parte de una práctica más amplia; Calidad y gobierno de datos para equipos BI explica cómo encajan con la responsabilidad sobre los datos, las definiciones y el monitoreo.

Próximos pasos

Instala dbt Core, conéctalo a una base de datos PostgreSQL gratuita o a la prueba de un warehouse en la nube y reconstruye un reporte que ya mantienes como un conjunto de modelos de staging y marts. Agrega pruebas unique y not_null, ejecuta dbt docs generate y dbt docs serve para ver tu grafo de linaje y conecta Power BI a la tabla del mart. Cuando eso funcione, prueba un modelo incremental en tu tabla más grande. Ese proyecto, por sí solo, es una pieza sólida para tu portafolio y la base para roles de analytics engineering.

Mira: lecciones en video

▶

▶

Preguntas frecuentes