dbt para Analistas de Datos en 2026: Modelado SQL, Testing Automatizado y Preguntas de Entrevista

El ecosistema de datos moderno exige que los analistas dominen herramientas que van mas alla de las consultas ad-hoc en SQL. dbt (data build tool) se ha posicionado como el estandar de facto para la capa de transformacion en pipelines ELT, y en 2026 constituye una competencia tecnica que aparece en la gran mayoria de las descripciones de empleo para roles de dbt data analyst en America Latina y a nivel global.

Con dbt Core v2.0 en fase alpha y la version v1.12 consolidada como release estable, la herramienta permite gestionar el ciclo completo de transformacion de datos: dbt modeling con SQL versionado en Git, testing automatizado de calidad y documentacion generada a partir del propio codigo. Este articulo recorre los fundamentos necesarios para trabajar con dbt de manera profesional y prepararse para las dbt interview questions que plantean los procesos de seleccion actuales.

Arquitectura de un proyecto dbt: capas staging, intermediate y marts

La organizacion interna de un proyecto dbt sigue un principio fundamental: separar las responsabilidades en capas bien definidas. Cuando esta separacion no existe, el resultado inevitable son decenas de consultas SQL monoliticas que duplican logica, dificultan el debugging y generan inconsistencias entre reportes.

La convencion que la comunidad y la documentacion oficial de dbt recomiendan utiliza tres capas:

• Staging -- Modelos delgados cuya unica funcion es renombrar columnas, convertir tipos de datos y aplicar filtros basicos sobre las tablas crudas. Se crea exactamente un modelo de staging por cada tabla de origen, sin joins ni agregaciones.
• Intermediate -- Modelos que contienen la logica de negocio intermedia: joins entre modelos de staging, filtros complejos y calculos que sirven como bloques reutilizables. Estos modelos no se consultan directamente desde herramientas de BI.
• Marts -- Los modelos de salida que alimentan dashboards, reportes y analisis. Cada mart representa una metrica de negocio concreta (ingresos mensuales, usuarios activos, tasa de conversion) o una entidad dimensional (clientes, productos).

El siguiente ejemplo muestra un modelo de staging que limpia datos de pagos provenientes de Stripe:

-- models/staging/stripe/stg_stripe__payments.sql
with source as (
    select * from {{ source('stripe', 'payments') }}
),

renamed as (
    select
        id as payment_id,
        amount / 100.0 as amount_usd,  -- Stripe stores cents
        status as payment_status,
        created::timestamp as created_at,
        customer_id
    from source
    where status != 'failed'  -- Filter invalid records early
)

select * from renamed

A partir del modelo de staging, un modelo mart puede calcular los ingresos mensuales netos con logica de negocio claramente separada:

-- models/marts/finance/fct_monthly_revenue.sql
with payments as (
    select * from {{ ref('stg_stripe__payments') }}
),

monthly as (
    select
        date_trunc('month', created_at) as revenue_month,
        count(*) as total_transactions,
        sum(amount_usd) as gross_revenue,
        sum(case when payment_status = 'refunded' then amount_usd else 0 end) as refunds
    from payments
    group by 1
)

select
    revenue_month,
    total_transactions,
    gross_revenue,
    refunds,
    gross_revenue - refunds as net_revenue  -- Key business metric
from monthly

La ventaja concreta de esta separacion es el aislamiento de cambios. Si Stripe modifica el esquema de su tabla de pagos, la actualizacion se realiza unicamente en el modelo de staging. Todos los modelos downstream que consumen stg_stripe__payments a traves de ref() siguen funcionando sin modificaciones.

Materializaciones: seleccionar la estrategia adecuada para cada modelo

Uno de los conceptos mas relevantes en dbt modeling es la materializacion, que determina como se persiste cada modelo en el data warehouse. Una eleccion incorrecta puede generar costos de computo elevados en tablas que deberian ser vistas, o consultas lentas en modelos que requieren tablas precalculadas.

dbt ofrece cuatro materializaciones principales:

| Materialization | Use Case | Rebuild Behavior | |----------------|----------|-------------------| | view | Lightweight staging models, low query frequency | Recreated as SQL view on each run | | table | Mart models queried often by dashboards | Full table rebuild on each run | | incremental | Large fact tables (events, logs) | Appends/merges new rows only | | ephemeral | Reusable CTEs, never queried directly | Compiled inline as subquery |

La materializacion incremental merece atencion especial porque aborda el problema de rendimiento mas critico en proyectos de data analytics dbt: procesar tablas de eventos o logs con miles de millones de registros en cada ejecucion resulta prohibitivo tanto en tiempo como en costo.

-- models/marts/product/fct_page_views.sql
{{ config(
    materialized='incremental',
    unique_key='page_view_id',
    incremental_strategy='merge'
) }}

with events as (
    select
        event_id as page_view_id,
        user_id,
        page_url,
        session_id,
        event_timestamp
    from {{ ref('stg_snowplow__events') }}
    where event_type = 'page_view'

    {% if is_incremental() %}
        -- Only process new events since last run
        and event_timestamp > (select max(event_timestamp) from {{ this }})
    {% endif %}
)

select * from events

El macro is_incremental() actua como un condicional inteligente. En la primera ejecucion del modelo, cuando la tabla destino no existe, dbt procesa la totalidad de los datos. En ejecuciones posteriores, la clausula adicional filtra exclusivamente los registros nuevos, reduciendo trabajos que antes tomaban horas a unos pocos minutos. La clave para que este patron funcione correctamente es contar con una columna temporal confiable (como event_timestamp) que permita identificar las filas nuevas sin ambiguedad.

Testing de calidad de datos: tests de esquema y tests personalizados

Una de las contribuciones mas significativas de dbt al flujo de trabajo analitico es la formalizacion del testing de datos. Antes de dbt, las validaciones de calidad dependian de scripts ad-hoc o de la revision manual de dashboards. Con dbt, los tests se definen de forma declarativa, se ejecutan con un solo comando (dbt test) y bloquean el pipeline si detectan violaciones.

Existen dos categorias de tests en dbt. Los tests de esquema se configuran en archivos YAML y cubren las validaciones mas comunes:

# models/staging/stripe/_stripe__models.yml
version: 2

models:
  - name: stg_stripe__payments
    description: "Cleaned payment records from Stripe"
    columns:
      - name: payment_id
        description: "Unique payment identifier"
        tests:
          - unique
          - not_null
      - name: payment_status
        tests:
          - accepted_values:
              values: ['succeeded', 'pending', 'refunded']
      - name: amount_usd
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= 0"  # No negative payments

Cuando la logica de validacion excede lo que YAML puede expresar, los tests singulares escritos en SQL proporcionan flexibilidad total. La regla es directa: si la consulta devuelve filas, el test falla.

-- tests/assert_revenue_not_negative.sql
-- This test fails if any month has negative net revenue
select
    revenue_month,
    net_revenue
from {{ ref('fct_monthly_revenue') }}
where net_revenue < 0  -- Should never happen

Este mecanismo resulta particularmente valioso para capturar errores que no son evidentes a nivel de columna individual sino que emergen de la interaccion entre multiples transformaciones. Una regla de negocio como "los ingresos netos mensuales nunca deben ser negativos" no puede expresarse con tests de esquema, pero un test singular la valida de manera precisa.

Jinja y macros: eliminar la repeticion de logica SQL

dbt incorpora el motor de plantillas Jinja para hacer el SQL dinamico y reutilizable. Las dos funciones fundamentales son ref() (para referenciar otros modelos de dbt) y source() (para referenciar tablas crudas definidas en archivos de configuracion). Pero el verdadero poder de Jinja se manifiesta en los macros personalizados, que permiten encapsular patrones SQL repetitivos en funciones reutilizables.

Un caso frecuente en proyectos que procesan datos financieros es la conversion de centavos a dolares. Sin macros, esta logica se repite en decenas de modelos con variaciones sutiles que generan inconsistencias:

-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ({{ column_name }} / 100.0)::numeric(12, 2)
{% endmacro %}

-- Usage in any model
select
    payment_id,
    {{ cents_to_dollars('amount_cents') }} as amount_usd,
    {{ cents_to_dollars('tax_cents') }} as tax_usd
from {{ source('stripe', 'payments') }}

En tiempo de compilacion, dbt reemplaza la invocacion del macro por SQL estandar. Si en algun momento la precision decimal necesita cambiar de numeric(12, 2) a numeric(14, 4), la modificacion se realiza en un unico archivo y se propaga automaticamente a todos los modelos que utilizan el macro. Este principio DRY (Don't Repeat Yourself) resulta indispensable en proyectos con mas de 50 modelos donde la consistencia entre transformaciones monetarias es un requisito de auditoria.

Preguntas de entrevista sobre dbt para analistas de datos

Los procesos de seleccion para roles de analisis de datos en 2026 incluyen con frecuencia creciente preguntas especificas sobre dbt. Los entrevistadores buscan comprension practica, no definiciones de manual. A continuacion se presentan las dbt interview questions que aparecen de manera recurrente.

P1: Cual es la diferencia entre ref() y source() y por que importa?

source() apunta a las tablas crudas que las herramientas de ingesta depositan en el warehouse, y se definen en un archivo sources.yml. ref() apunta a otros modelos de dbt. La diferencia critica es que ref() construye el DAG (grafo aciclico dirigido), la estructura que dbt utiliza para determinar el orden de ejecucion de los modelos y rastrear el linaje de datos completo. Reemplazar ref() por nombres de tabla hardcodeados rompe la capacidad de dbt para detectar dependencias, lo que puede provocar que los modelos se ejecuten en un orden incorrecto y produzcan resultados erroneos.

P2: En que situaciones conviene usar un modelo incremental en lugar de una tabla?

Los modelos incrementales son la opcion correcta cuando se cumplen dos condiciones: los datos de origen tienen una columna temporal confiable que permite identificar registros nuevos, y el volumen de la tabla es lo suficientemente grande como para que una reconstruccion completa resulte costosa o lenta. Tablas de eventos de producto, logs de aplicacion y datos de series temporales son candidatos ideales. Las tablas de dimensiones pequenas (clientes, productos, categorias) deben permanecer como materializacion table porque el overhead de la logica incremental no se justifica ante volumenes reducidos.

P3: Como implementa dbt las dimensiones de cambio lento (SCD Tipo 2)?

A traves de los snapshots. Un snapshot monitorea una tabla fuente y registra cada cambio detectado agregando columnas dbt_valid_from y dbt_valid_to, lo que permite reconstruir el historial completo de un registro. dbt ofrece dos estrategias de deteccion: timestamp (compara una columna updated_at) y check (compara directamente los valores de las columnas especificadas). Los snapshots se ejecutan con el comando dbt snapshot, independiente de dbt run, y se almacenan en un directorio separado del proyecto.

P4: Describa el patron staging/intermediate/marts y su proposito.

Staging limpia y estandariza los datos crudos: un modelo por tabla de origen, sin joins, sin agregaciones. Intermediate contiene la logica de negocio intermedia: joins entre stagings, calculos derivados y filtros que sirven como componentes reutilizables. Marts son las salidas finales que consumen los dashboards y los analistas. La razon fundamental de esta separacion es que un cambio en el esquema de origen impacta exclusivamente el modelo de staging correspondiente, sin requerir modificaciones en cadena a traves de toda la base de modelos.

P5: Que diferencia existe entre los tests de esquema y los tests singulares?

Los tests de esquema se declaran en YAML y validan restricciones estandar: unique, not_null, accepted_values y relationships. Los tests singulares son consultas SQL ubicadas en el directorio tests/ cuya logica es completamente libre: cualquier fila devuelta indica una falla. Ademas, dbt permite crear tests genericos personalizados, que son macros parametrizados reutilizables entre modelos. La recomendacion practica es utilizar tests de esquema para restricciones de datos comunes y reservar los tests singulares para reglas de negocio complejas que involucran multiples columnas o modelos.

Buenas practicas de dbt en proyectos de produccion

Un proyecto dbt que funciona bien con 10 modelos puede volverse inmanejable al llegar a 100 si no se establecen convenciones desde el inicio. Las siguientes practicas representan el consenso de la comunidad de dbt para mantener la calidad y escalabilidad a largo plazo.

Convenciones de nomenclatura estrictas. Los modelos de staging llevan el prefijo stg_, los intermediate utilizan int_, las tablas de hechos usan fct_ y las dimensiones dim_. Los subdirectorios se organizan por fuente de datos (models/staging/stripe/, models/staging/salesforce/), lo que permite a cualquier integrante del equipo localizar un modelo en segundos.

Documentacion integrada en el codigo. Cada modelo y cada columna relevante deben incluir una propiedad description en el archivo YAML correspondiente. El comando dbt docs generate produce un sitio web con documentacion navegable y un DAG visual interactivo que resulta invaluable tanto para el onboarding de nuevos integrantes como para auditorias de linaje de datos.

Monitoreo de frescura de fuentes. Las verificaciones de source freshness permiten detectar fallas en la ingesta antes de que contaminen los modelos downstream:

# models/staging/stripe/_stripe__sources.yml
version: 2

sources:
  - name: stripe
    database: raw
    schema: stripe
    freshness:
      warn_after: {count: 12, period: hour}
      error_after: {count: 24, period: hour}
    loaded_at_field: _fivetran_synced
    tables:
      - name: payments
      - name: customers

El comando dbt source freshness consulta la columna loaded_at_field para verificar que los datos se hayan actualizado dentro de la ventana configurada. Si los datos de pagos tienen mas de 24 horas de retraso, el pipeline arroja un error antes de ejecutar transformaciones sobre informacion desactualizada, evitando que dashboards y reportes presenten metricas incorrectas.

Para complementar las habilidades de SQL que se aplican dentro de los modelos dbt, las guias sobre funciones de ventana SQL y CTEs y SQL avanzado para entrevistas cubren los patrones de consulta que aparecen con mayor frecuencia en modelos de staging y marts.

Conclusion

• dbt gestiona la capa de transformacion en pipelines ELT, ejecutando SQL directamente en el data warehouse sin depender de un motor de procesamiento externo
• La arquitectura por capas staging/intermediate/marts aisla la limpieza de datos crudos de la logica de negocio, haciendo que cada cambio sea predecible y contenido en su capa correspondiente
• Las materializaciones incrementales eliminan la necesidad de reconstruir tablas completas en cada ejecucion, reduciendo drasticamente los tiempos y costos de procesamiento en tablas de gran volumen
• Los tests de esquema en YAML cubren validaciones estandar (unicidad, nulidad, valores permitidos), mientras que los tests singulares en SQL permiten validar reglas de negocio arbitrariamente complejas
• Los macros Jinja centralizan la logica SQL repetitiva y garantizan consistencia en todas las transformaciones que comparten un patron comun
• El monitoreo de frescura de fuentes detecta interrupciones en la ingesta de datos antes de que afecten los modelos y reportes downstream
• La preparacion para entrevistas de dbt data analyst debe priorizar la comprension practica de escenarios reales (linaje del DAG, seleccion de materializaciones, estrategias de testing) sobre la memorizacion de definiciones teoricas