Cómo Instalar y Configurar dbt Core con BigQuery desde CERO
Aprende a instalar dbt Core, conectar un proyecto con Google BigQuery, ejecutar dbt init y construir tus primeros staging models siguiendo una arquitectura preparada para crecer desde un laboratorio hasta un entorno empresarial.
Lo que aprenderás
El objetivo no es únicamente ejecutar el primer comando de dbt. La meta es comprender qué piezas intervienen entre tu estación de desarrollo, dbt Core y BigQuery, y cómo convertir esa conexión inicial en un patrón reproducible de Analytics Engineering.
Stack tecnológico del laboratorio
El flujo utiliza herramientas estándar para desarrollar localmente y ejecutar transformaciones SQL directamente sobre el motor analítico.
Antes de instalar: entiende la arquitectura
dbt no sustituye a BigQuery ni pretende convertirse en una base de datos. dbt actúa como una capa de transformación, modelado, documentación y automatización sobre el data warehouse.
BigQuery ejecuta
- Almacena los datos analíticos.
- Ejecuta las consultas SQL generadas por dbt.
- Escala el procesamiento según el patrón de consulta.
- Aplica controles de acceso mediante Google Cloud IAM.
- Facturación principalmente vinculada al almacenamiento y procesamiento.
dbt orquesta la transformación
- Define modelos SQL como código.
- Construye dependencias entre modelos mediante el DAG.
- Gestiona materializaciones como views y tables.
- Permite tests, documentación y contratos de datos.
- Convierte SQL analítico en un proyecto mantenible y versionable.
Fuentes
│
▼
BigQuery RAW
│
│ dbt source()
▼
STAGING
│
│ dbt ref()
▼
INTERMEDIATE
│
│ lógica de negocio
▼
MARTS
│
▼
BI / Analytics / ML
Matriz de decisión: ¿dónde encaja dbt?
Una decisión arquitectónica importante consiste en no utilizar una herramienta analítica como si fuera una base de datos transaccional. dbt está diseñado alrededor de transformaciones analíticas y dependencias de datos.
| Patrón | Objetivo | Latencia típica | Consistencia / modelo | Coste dominante | Encaje con dbt |
|---|---|---|---|---|---|
| OLTP | Transacciones operacionales | Milisegundos | Modelo relacional y transaccional | CPU, IOPS, memoria | Bajo como destino directo |
| OLAP / Warehouse | Analítica y reporting | Segundos a minutos | Orientado a consultas analíticas | Procesamiento + almacenamiento | Excelente |
| BigQuery + dbt | Transformación analítica como código | Segundos a minutos | Modelos SQL versionados | Query processing + storage | Patrón recomendado |
| Streaming puro | Procesamiento evento a evento | Milisegundos a segundos | Estado y eventos | Throughput + infraestructura | Complementario, no sustituto |
1. Instalar dbt Core con BigQuery
Para este tutorial utilizaremos un entorno virtual de Python y el adaptador dbt-bigquery. El adaptador instala las dependencias necesarias de dbt Core para trabajar con BigQuery.
Comprobar Python
Antes de instalar dbt, comprueba que tienes una versión de Python compatible con la versión del adaptador que vas a utilizar.
python --version
python -m pip --version
Crear un entorno virtual
Evita instalar dbt globalmente. Un entorno virtual permite aislar versiones y dependencias del proyecto.
python -m venv .venv
# Windows PowerShell
.venv\Scripts\Activate.ps1
# macOS / Linux
source .venv/bin/activate
Actualizar pip
python -m pip install --upgrade pip
Instalar el adaptador de BigQuery
Para un proyecto dbt que utiliza BigQuery, el paquete clave es dbt-bigquery.
python -m pip install dbt-bigquery
Verificar la instalación
dbt --version
La salida debe mostrar la versión de dbt Core y el adaptador de BigQuery disponible en el entorno.
2. Preparar BigQuery para dbt
La instalación local de dbt es solo la mitad del problema. El siguiente paso es resolver identidad, autorización y destino de ejecución.
Variables que debes conocer
- Project ID: proyecto de Google Cloud donde se ejecutarán las consultas.
- Dataset: dataset por defecto donde dbt creará las relaciones.
- Location: región o multirregión de BigQuery coherente con tus datos.
- Credentials: identidad utilizada por dbt para autenticarse.
- Threads: número de ejecuciones concurrentes que dbt puede solicitar.
mi_proyecto:
target: dev
outputs:
dev:
type: bigquery
method: service-account
project: "TU_PROJECT_ID"
dataset: "analytics_dev"
keyfile: "/ruta/segura/service-account.json"
location: "EU"
threads: 4
timeout_seconds: 300
priority: interactive
retries: 1
El archivo profiles.yml pertenece a la configuración de conexión de dbt y no debería introducirse en el repositorio Git si contiene información sensible o referencias a credenciales locales.
No subas el JSON de una Service Account a Git
Una de las peores prácticas en un proyecto de datos es almacenar credenciales permanentes dentro del repositorio. Si un secreto termina en Git, eliminar el archivo del último commit no implica que el secreto haya desaparecido del historial.
Para desarrollo local, protege el archivo de credenciales y excluye su ruta del repositorio. Para producción, utiliza mecanismos de identidad gestionada, secret management o Workload Identity cuando la arquitectura lo permita.
3. dbt init: crear el proyecto desde cero
dbt init es el punto de entrada natural para un principiante porque genera la estructura base de un proyecto y guía la configuración inicial.
mkdir dbt-bigquery-tutorial
cd dbt-bigquery-tutorial
dbt init tutorial_dbt_bigquery
Durante el asistente, dbt solicitará información relacionada con el perfil y la conexión. El nombre del perfil debe corresponder con el perfil utilizado en profiles.yml.
tutorial_dbt_bigquery/
├── analyses/
├── macros/
├── models/
│ └── example/
├── seeds/
├── snapshots/
├── tests/
├── dbt_project.yml
└── README.md
¿Qué representa cada directorio?
- models/: SQL y configuraciones de modelos.
- macros/: lógica reutilizable mediante Jinja.
- seeds/: pequeños datasets versionados en archivos CSV.
- snapshots/: captura histórica de cambios en determinados patrones de datos.
- tests/: tests SQL personalizados.
- analyses/: consultas analíticas que no necesariamente se materializan como modelos.
- dbt_project.yml: configuración principal del proyecto.
4. Staging Models: la primera capa seria de dbt
El error habitual al aprender dbt es colocar toda la lógica dentro de un único modelo SQL. Un enfoque más escalable separa la limpieza inicial de las reglas de negocio.
RAW
Representa los datos tal y como llegan desde las fuentes. La prioridad es preservar trazabilidad y minimizar transformaciones destructivas.
STAGING
Normaliza nombres, tipos, campos técnicos y convenciones. El staging debe ser relativamente cercano a la fuente.
INTERMEDIATE
Encapsula transformaciones complejas, joins y lógica reutilizable que no pertenece directamente al modelo final.
MARTS
Expone entidades y métricas orientadas al consumo de negocio, BI, reporting o productos de datos.
{{ config(
materialized='view'
) }}
select
cast(customer_id as int64) as customer_id,
cast(first_name as string) as first_name,
cast(last_name as string) as last_name,
lower(trim(email)) as email,
cast(created_at as timestamp) as created_at
from `TU_PROJECT_ID.raw.customers`
where customer_id is not null
En un proyecto real es preferible declarar la fuente mediante sources.yml y utilizar source() en lugar de acoplar el modelo a un identificador físico escrito directamente en el SQL.
version: 2
sources:
- name: raw
database: TU_PROJECT_ID
schema: raw
tables:
- name: customers
- name: orders
select
cast(customer_id as int64) as customer_id,
lower(trim(email)) as email,
cast(created_at as timestamp) as created_at
from {{ source('raw', 'customers') }}
where customer_id is not null
5. Configurar dbt_project.yml correctamente
La configuración del proyecto debe expresar una convención clara de materialización y estructura. Evita convertir dbt_project.yml en un archivo de excepciones imposibles de mantener.
name: 'tutorial_dbt_bigquery'
version: '1.0.0'
config-version: 2
profile: 'tutorial_dbt_bigquery'
model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]
models:
tutorial_dbt_bigquery:
staging:
+materialized: view
intermediate:
+materialized: view
marts:
+materialized: table
La idea arquitectónica es deliberada: staging puede mantenerse ligero mediante views cuando el patrón de acceso lo justifica, mientras que los marts pueden materializarse como tablas cuando se busca estabilidad, reutilización y evitar recalcular la misma lógica constantemente.
6. Validar la conexión antes de construir modelos
No empieces depurando SQL si todavía no sabes si el problema está en la autenticación, el perfil o el warehouse.
dbt debug
dbt parse
dbt run
dbt test
Qué diagnostica cada comando
- dbt debug: ayuda a validar configuración y conexión.
- dbt parse: comprueba que el proyecto pueda ser interpretado correctamente.
- dbt run: ejecuta los modelos seleccionados.
- dbt test: ejecuta las validaciones definidas en el proyecto.
Antipatrones: dónde se pierde dinero en BigQuery
Que dbt genere SQL automáticamente no significa que el SQL generado sea automáticamente eficiente.
El antipatrón: convertir cada staging model en una tabla gigantesca
Un proyecto puede terminar materializando tablas innecesariamente grandes, recalculando históricos completos y ejecutando transformaciones que podrían resolverse con una estrategia incremental o una mejor selección de columnas.
En BigQuery, la optimización empieza por reducir datos procesados. Selecciona únicamente las columnas necesarias, filtra particiones cuando sea posible, evita recomputar históricos sin necesidad y revisa las consultas que dbt está generando realmente.
No usar SELECT *
Un staging model debería explicitar las columnas relevantes cuando el contrato de datos lo permita.
Particionar conscientemente
Para tablas grandes, diseña las claves de particionamiento pensando en cómo serán consultadas realmente.
Materializar con intención
Una view, una tabla y un modelo incremental tienen costes operativos diferentes. No existe una materialización universalmente correcta.
Implementación práctica de producción
Un staging model robusto debería ser pequeño, determinista, explícito y fácil de probar. La complejidad de negocio debe aparecer en capas posteriores.
{{ config(
materialized='view',
tags=['staging']
) }}
with source_data as (
select
order_id,
customer_id,
order_status,
order_total,
created_at,
updated_at
from {{ source('raw', 'orders') }}
),
cleaned as (
select
cast(order_id as int64) as order_id,
cast(customer_id as int64) as customer_id,
upper(trim(order_status)) as order_status,
cast(order_total as numeric) as order_total,
cast(created_at as timestamp) as created_at,
cast(updated_at as timestamp) as updated_at
from source_data
where order_id is not null
)
select *
from cleaned
version: 2
models:
- name: stg_orders
description: "Normalización inicial de pedidos procedentes de RAW."
columns:
- name: order_id
description: "Identificador único del pedido."
data_tests:
- not_null
- unique
- name: customer_id
description: "Identificador del cliente."
data_tests:
- not_null
- name: order_status
description: "Estado normalizado del pedido."
data_tests:
- not_null
- name: order_total
description: "Importe total del pedido."
Patrones de diseño para un proyecto dbt escalable
El objetivo de un buen proyecto dbt no es tener muchos modelos. Es tener responsabilidades claras y dependencias comprensibles.
Source → Staging
Utiliza source() para establecer explícitamente el contrato entre las fuentes y los modelos iniciales.
- Nombres consistentes.
- Tipos normalizados.
- Limpieza mínima.
Staging → Intermediate
Extrae lógica compleja en modelos intermedios en lugar de crear SQL monolítico en los marts.
- Joins reutilizables.
- Transformaciones complejas aisladas.
- Mayor capacidad de testing.
Intermediate → Marts
Los marts deben estar orientados al consumo y utilizar un lenguaje comprensible para analistas y consumidores de datos.
- Entidades de negocio.
- Métricas.
- Contratos estables.
Tests como contrato
Los tests no son un accesorio. Son una forma de convertir expectativas sobre los datos en reglas ejecutables.
- Not null.
- Unique.
- Relaciones y reglas específicas.
Git como fuente de verdad
Versiona modelos, configuraciones y documentación, pero no secretos ni credenciales.
- Pull requests.
- Code review.
- CI para validaciones.
Observabilidad
En producción necesitas saber qué modelo falló, por qué falló y qué dependencias fueron afectadas.
- Logs de ejecución.
- Tests.
- Lineage.
Framework de implementación paso a paso
Esta secuencia permite pasar de un entorno vacío a una primera implementación reproducible sin mezclar problemas de infraestructura con problemas de SQL.
Preparar el entorno
Instala Python, crea un virtual environment y añade dbt-bigquery.
Resolver identidad
Configura la autenticación contra Google Cloud y verifica permisos sobre el proyecto y datasets necesarios.
Crear el proyecto
Ejecuta dbt init y revisa la estructura que genera en lugar de comenzar a escribir SQL inmediatamente.
Validar dbt debug
Si la conexión falla, resuelve primero autenticación, perfil, región, proyecto y permisos.
Declarar sources
Define las tablas RAW de las que depende el proyecto y evita referencias físicas repetidas en cada modelo.
Construir staging
Normaliza nombres, tipos y campos técnicos. Mantén fuera de esta capa las reglas complejas de negocio.
Añadir tests
Empieza con claves, nullability y relaciones críticas antes de ampliar el conjunto de validaciones.
Optimizar y automatizar
Revisa consultas, materializaciones, particionamiento, costes y después incorpora CI/CD y orquestación.
Comandos esenciales de dbt para este laboratorio
Estos comandos cubren el ciclo básico de desarrollo desde la creación hasta la validación del proyecto.
# Crear proyecto
dbt init tutorial_dbt_bigquery
# Validar configuración
dbt debug
# Parsear proyecto
dbt parse
# Ejecutar todos los modelos
dbt run
# Ejecutar un modelo concreto
dbt run --select stg_customers
# Ejecutar un modelo y sus descendientes
dbt run --select stg_customers+
# Ejecutar tests
dbt test
# Ejecutar modelo y tests asociados
dbt build
# Generar documentación
dbt docs generate
# Servir documentación local
dbt docs serve
Checklist de producción
Antes de considerar que tu proyecto dbt + BigQuery está preparado para evolucionar, verifica estos puntos.
Preguntas frecuentes sobre dbt Core + BigQuery
Respuestas rápidas a las dudas que aparecen normalmente durante el primer proyecto de dbt.
¿Qué necesito para instalar dbt Core con BigQuery?
Necesitas Python, acceso a un proyecto de Google Cloud con BigQuery disponible, credenciales con permisos adecuados y el adaptador dbt-bigquery. La instalación local puede realizarse dentro de un entorno virtual mediante pip.
¿Para qué sirve exactamente dbt init?
dbt init crea la estructura inicial del proyecto dbt y solicita información necesaria para asociarlo a un perfil de conexión. No crea por sí mismo una arquitectura de datos completa: esa parte debe diseñarse posteriormente.
¿Qué debe contener un staging model?
Normalmente debe contener transformaciones cercanas a la fuente: renombrado de columnas, normalización de tipos, limpieza sencilla, estandarización de valores y eliminación de registros técnicamente inválidos. La lógica de negocio compleja debería desplazarse hacia capas intermedias o marts.
