HUB dbt

MODELING.SQL()

Lógica de Negocio & Calidad

Todo es un SELECT

En dbt, olvídate de escribir CREATE TABLE IF NOT EXISTS... o gestionar UPDATES complejos. Un modelo es simplemente un archivo .sql con una sentencia SELECT. dbt envuelve ese SELECT en el DDL correcto para Spark.

models/clientes_vip.sql
SQL JINJA
/*
    Lógica de Negocio Pura:
    Solo define CÓMO se ven los datos resultantes.
*/

with pedidos as (
    -- No usamos FROM 'tabla_fisica', usamos ref()
    select * from {{ ref('stg_pedidos') }}
),

calculo_metricas as (
    select
        cliente_id,
        sum(monto) as total_gastado,
        count(pedido_id) as n_pedidos
    from pedidos
    group by cliente_id
)

select * from calculo_metricas
where total_gastado > 1000

Cuando ejecutas dbt run, dbt compila este archivo en Spark SQL:
CREATE TABLE analytics.clientes_vip AS SELECT ...

01

La Función Mágica: ref()

DEPENDENCY GRAPH

La regla de oro en dbt: Nunca escribas el nombre físico de una tabla (ej: `analytics.tabla_a`). Siempre usa {{ ref('nombre_modelo') }}. Esto permite a dbt construir el Árbol de Dependencias (DAG) y ejecutar los modelos en el orden correcto.

graph LR A[stg_pedidos] -->|ref| B[int_ventas_diarias] A -->|ref| C[int_clientes_metricas] B -->|ref| D[fact_ventas_mensuales] C -->|ref| E[dim_clientes_vip] style A fill:#78350f,stroke:#fff style B fill:#1e3a8a,stroke:#fff style C fill:#1e3a8a,stroke:#fff style D fill:#14532d,stroke:#fff style E fill:#14532d,stroke:#fff
BRONZE
SILVER
GOLD
02

Configuración y Materialización

View vs Table vs Incremental

Puedes decirle a dbt cómo guardar el resultado en Spark usando un bloque de configuración Jinja al inicio del archivo.

View
{{ config(materialized='view') }}

Rápido. No ocupa espacio. Se recalcula cada vez que se consulta. Ideal para capas intermedias o Bronze.

Table
{{ config(materialized='table') }}

Dbt hace un DROP + CREATE. Los datos se guardan en Parquet/Delta. Rápido de leer, lento de construir. Ideal para dimensiones pequeñas.

Incremental
{{ config(materialized='incremental') }}

Solo procesa los datos nuevos. Vital para Big Data en Spark. Dbt hace un MERGE inteligente.

03

Calidad como Código

SCHEMA.YML & TESTS

Aquí reemplazamos las "Expectations" de DLT. En dbt, definimos las reglas de calidad en un archivo YAML junto a la documentación. Si un test falla, dbt alerta en la consola.

models/schema.yml YAML
version: 2

models:
  - name: clientes_vip
    description: "Tabla derivada que contiene solo clientes con gasto > 1000"
    columns:
      - name: cliente_id
        description: "Clave primaria del cliente"
        tests:
          - unique      # Test Genérico 1: No puede haber duplicados
          - not_null    # Test Genérico 2: No puede ser nulo

      - name: total_gastado
        tests:
          - accepted_values: # Test Genérico 3: Validar valores permitidos (ejemplo)
              values: [0, 100, 200]
              quote: false
              severity: warn  # Solo advertir, no fallar el pipeline

Tests Genéricos

Vienen incluidos "de caja".

  • unique
  • not_null
  • accepted_values
  • relationships (integridad referencial FK)

Documentación

El mismo archivo schema.yml alimenta un sitio web de documentación automático.

$ dbt docs generate && dbt docs serve
Anterior
Setup & Config
Siguiente Paso
Documentación & Ops