dbt para equipos que empiezan: guía práctica

dbt ha pasado de ser una herramienta nicho en 2019 a ser prácticamente el estándar para la capa de transformación en stacks de datos modernos. Si tu empresa trabaja con Snowflake, BigQuery, Redshift, DuckDB o incluso Postgres, y el equipo escribe transformaciones en SQL, dbt es la herramienta que probablemente deberías estar usando.

¿Por qué dbt (y no otro enfoque)?

• Las transformaciones son SQL nativo, no un DSL propietario que hay que aprender.
• Todo está en Git: cada transformación es un archivo .sql versionable, revisable con pull requests y desplegable con CI/CD.
• Los tests de calidad se definen en YAML junto al modelo, sin herramientas adicionales.
• La documentación del linaje de datos se genera automáticamente a partir del código — si el código cambia, la documentación se actualiza.
• dbt Core es open source y gratuito; dbt Cloud añade interfaz web, scheduling y CI/CD gestionado.

Estructura de proyecto dbt recomendada para empezar

Tests declarativos: la parte más valiosa de dbt

Los tests en dbt son declaraciones sobre cómo deben ser los datos, escritas en YAML junto al modelo. Los cuatro tests nativos cubren los casos más frecuentes: not_null (el campo no puede ser nulo), unique (no puede haber duplicados), accepted_values (el campo solo puede tener ciertos valores), relationships (la clave foránea debe existir en otra tabla). Añadiendo dbt-expectations (que replica la sintaxis de Great Expectations en dbt) puedes testear rangos, proporciones, patrones regex y muchos más criterios sin salir del framework.

Estrategia de tests por capa

No todos los modelos necesitan el mismo nivel de testing. Una estrategia práctica es ajustar los tests a la capa del modelo:

El error más habitual es no poner tests en staging y confiar en que los datos de origen siempre llegan bien. En la práctica, las fuentes cambian sin aviso: un campo que antes nunca era nulo empieza a serlo, un sistema cambia el formato de fecha o un proceso de carga empieza a duplicar registros. Los tests en staging son la primera línea de defensa.

dbt-expectations: tests avanzados sin código custom

El paquete dbt-expectations amplía enormemente la capacidad de testing sin necesidad de escribir macros custom. Algunos de los tests más útiles en contexto empresarial:

• expect_column_values_to_be_between: valida que un importe, porcentaje o métrica está dentro de un rango razonable. Perfecto para detectar anomalías en datos financieros.
• expect_column_proportion_of_unique_values_to_be_between: detecta si de repente un campo que debería ser diverso empieza a repetirse (señal de problema en la fuente).
• expect_table_row_count_to_be_between: alerta si una tabla tiene muchos menos o muchos más registros de lo esperado. Ideal para detectar cargas fallidas o duplicaciones.
• expect_column_values_to_match_regex: valida formatos (NIF, email, código postal) sin necesidad de lógica custom.

Cómo integrar dbt en el flujo de trabajo del equipo

1. 1Desarrollo local: cada analista trabaja en su branch, ejecuta 'dbt run' y 'dbt test' localmente contra una schema de desarrollo en el warehouse.
2. 2Pull request: cuando el trabajo está listo, abre un PR. Los tests se ejecutan automáticamente en CI (GitHub Actions, dbt Cloud CI).
3. 3Merge y despliegue: tras la revisión, el merge actualiza la rama principal y el pipeline de producción ejecuta 'dbt run' + 'dbt test' contra las tablas de producción.
4. 4Scheduling: dbt Cloud, Airflow o Dagster pueden orquestar la ejecución programada (cada hora, diaria, semanal) sin infraestructura adicional.

Errores frecuentes al adoptar dbt en empresa

Después de ver varios equipos adoptar dbt, hay patrones de error que se repiten con frecuencia:

• Meter toda la lógica en un solo modelo SQL gigante en lugar de descomponerlo en capas. Si un modelo tiene más de 200 líneas, probablemente necesita dividirse.
• No usar ref() para referenciar modelos. Sin ref(), dbt no puede construir el grafo de dependencias y el linaje se pierde.
• Hardcodear nombres de esquema o base de datos. Usa variables de entorno y el archivo profiles.yml para que el mismo código funcione en desarrollo y producción.
• Ignorar la documentación. Las descriptions en YAML parecen opcionales, pero son lo que hace que un proyecto dbt sea mantenible cuando el equipo crece o cuando alguien nuevo se incorpora.
• Ejecutar dbt run sin dbt test después. Los tests solo valen si se ejecutan. Configura CI para que un test fallido bloquee el merge.

dbt y calidad de datos: cómo encajan

Una de las mayores ventajas de dbt es que convierte la calidad de datos en parte del pipeline, no en un proceso separado. Cada vez que se ejecutan las transformaciones, los tests validan que los resultados cumplen las expectativas. Si un test falla, el pipeline se detiene antes de que los datos incorrectos lleguen al dashboard. Este enfoque se alinea con lo que en gobierno del dato y calidad llamamos calidad integrada: no auditas después, sino que validas durante.

En la práctica, esto significa que un equipo con dbt bien configurado puede garantizar a negocio que los dashboards muestran datos que han pasado validaciones explícitas. No es una garantía absoluta (ninguna herramienta lo es), pero es un salto cualitativo respecto a transformaciones SQL sueltas sin ningún control.

Cuándo dbt no es la herramienta adecuada

dbt es excelente para transformación de datos en SQL dentro de un warehouse. Pero no cubre todo el pipeline:

• Ingesta de datos: dbt no extrae datos de fuentes. Necesitas herramientas como Fivetran, Airbyte o scripts de ingesta para mover los datos al warehouse.
• Orquestación compleja: para pipelines que combinan ingesta, transformación, ML y notificaciones, necesitas un orquestador (Airflow, Dagster, Prefect) que llame a dbt como un paso más.
• Procesamiento de datos no estructurados: si trabajas con imágenes, audio, PDFs o datos que no encajan en tablas SQL, dbt no es la herramienta.
• Transformaciones que requieren Python intensivo: aunque dbt soporta modelos Python, su punto fuerte sigue siendo SQL. Para ML o procesamiento pesado en Python, mejor usar un entorno dedicado.

Si necesitas diseñar un stack de datos completo donde dbt sea la capa de transformación, nuestro servicio de plataforma de datos parte del diagnóstico de tu situación actual para recomendarte las piezas que encajan, no solo dbt sino todo lo que lo rodea.

Para más contexto, puedes consultar la documentación oficial de dbt.

Preguntas frecuentes sobre dbt para empresas

¿Necesito saber Python para usar dbt?

No para el día a día. dbt usa SQL para las transformaciones. Python es necesario para instalarlo (pip install dbt-core) y para crear nodos de código Python si los necesitas, pero el 95% del trabajo en dbt es SQL y YAML.

¿dbt Core es suficiente o necesito dbt Cloud?

Para equipos pequeños (1–3 personas), dbt Core con scheduling en Airflow, Dagster o incluso cron es suficiente. dbt Cloud añade una interfaz web cómoda, CI/CD integrado, linaje visual y gestión de entornos, lo que lo hace más conveniente para equipos medianos o para organizaciones que no quieren gestionar la infraestructura de orquestación.

¿Con qué warehouses es compatible dbt?

Los adapters oficialmente soportados incluyen Snowflake, BigQuery, Redshift, Databricks, Postgres, DuckDB, Azure Synapse, SQL Server y varios más. Para la mayoría de stacks de empresa mediana en España (Postgres, BigQuery, Snowflake), el soporte es completo y maduro.

¿Cuánto tiempo tarda un equipo en adoptar dbt?

Si el equipo ya escribe SQL con soltura, la curva de aprendizaje de dbt es de 1-2 semanas para lo básico (crear modelos, ejecutar tests, entender el flujo). Dominar las buenas prácticas (materialización incremental, macros, paquetes, CI/CD) lleva algo más, típicamente 1-2 meses de uso real. Lo más importante no es la herramienta en sí, sino adoptar la disciplina de versionado, testing y documentación que dbt facilita.

¿Merece la pena dbt si solo tengo un analista de datos?

Sí, especialmente si ese analista escribe transformaciones SQL que otros consumen en dashboards. dbt aporta versionado (puedes revertir cambios), tests (sabes si algo se rompe antes de que lo vea el director financiero) y documentación (cuando esa persona se vaya de vacaciones o cambie de puesto, alguien puede entender qué hace cada transformación). El coste de adopción para una persona es bajo y el beneficio a medio plazo es alto.