Logo GCP con Eduardo

GCP con Eduardo

Descarga el código de la lección

Cómo Instalar y Configurar dbt Core con BigQuery desde CERO (Tutorial Staging)
✦ Guía Técnica & Arquitectura

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.

Instalar dbt Core Crear un entorno Python aislado e instalar el adaptador específico para BigQuery.
Configurar BigQuery Entender perfiles, credenciales, proyecto, dataset, región y concurrencia.
Ejecutar dbt init Generar la estructura de un proyecto y comprender el papel de cada directorio.
Crear staging models Separar fuentes de lógica de negocio y establecer una primera capa transformacional.

Stack tecnológico del laboratorio

El flujo utiliza herramientas estándar para desarrollar localmente y ejecutar transformaciones SQL directamente sobre el motor analítico.

dbt Core dbt-bigquery Google BigQuery Python SQL Jinja Git Analytics Engineering

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.
Arquitectura conceptual dbt → BigQuery
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.

Terminal Python
python --version

python -m pip --version

Crear un entorno virtual

Evita instalar dbt globalmente. Un entorno virtual permite aislar versiones y dependencias del proyecto.

Terminal venv
python -m venv .venv

# Windows PowerShell
.venv\Scripts\Activate.ps1

# macOS / Linux
source .venv/bin/activate

Actualizar pip

Terminal Package manager
python -m pip install --upgrade pip

Instalar el adaptador de BigQuery

Para un proyecto dbt que utiliza BigQuery, el paquete clave es dbt-bigquery.

Terminal dbt-bigquery
python -m pip install dbt-bigquery

Verificar la instalación

Terminal Verification
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.
profiles.yml ~/.dbt/profiles.yml
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.

Antipatrón crítico

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.

Terminal dbt init tutorial
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.

Estructura inicial Project layout
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.

models/staging/stg_customers.sql Production pattern
{{ 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.

models/staging/sources.yml Source definition
version: 2

sources:
  - name: raw
    database: TU_PROJECT_ID
    schema: raw

    tables:
      - name: customers
      - name: orders
models/staging/stg_customers.sql Recommended reference
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.

dbt_project.yml Core configuration
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.

Terminal Debugging sequence
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.

FinOps

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.

FINOPS / 01

No usar SELECT *

Un staging model debería explicitar las columnas relevantes cuando el contrato de datos lo permita.

FINOPS / 02

Particionar conscientemente

Para tablas grandes, diseña las claves de particionamiento pensando en cómo serán consultadas realmente.

FINOPS / 03

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.

models/staging/stg_orders.sql dbt + BigQuery
{{ 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
models/staging/stg_orders.yml Data quality
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.

PATTERN / 01

Source → Staging

Utiliza source() para establecer explícitamente el contrato entre las fuentes y los modelos iniciales.

  • Nombres consistentes.
  • Tipos normalizados.
  • Limpieza mínima.
PATTERN / 02

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.
PATTERN / 03

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.
PATTERN / 04

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.
PATTERN / 05

Git como fuente de verdad

Versiona modelos, configuraciones y documentación, pero no secretos ni credenciales.

  • Pull requests.
  • Code review.
  • CI para validaciones.
PATTERN / 06

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.

CLI cheat sheet dbt Core
# 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.

Entorno aislado dbt instalado dentro de un entorno reproducible y con versiones controladas.
Credenciales seguras Ningún secreto ni Service Account JSON se encuentra versionado.
Fuentes declaradas Las tablas RAW tienen una definición explícita y trazable.
Tests activos Las columnas críticas tienen expectativas de calidad ejecutables.

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.

Sobre el Autor: Eduardo Martínez Agrelo

AI & Data Architect

Eduardo Martínez Agrelo es AI & Data Architect especializado en arquitectura de datos, ingeniería de datos, analítica avanzada e inteligencia artificial. Su enfoque combina fundamentos técnicos, decisiones arquitectónicas y prácticas orientadas a entornos empresariales, con especial atención a escalabilidad, gobierno, rendimiento y eficiencia de costes.