Proyecto, sources y ref()

Objetivo

Entender el DAG y separar origen de modelos.

Explicación

source() representa tablas externas gestionadas fuera de dbt; ref() representa modelos de tu proyecto. ref construye dependencias y permite que dbt resuelva nombres por entorno. dbt aporta valor cuando las transformaciones dejan de ser consultas sueltas y pasan a formar un DAG versionado, testeable y documentado. En trabajo real tendrás que justificar dependencias, contratos de datos y cómo despliegas cambios sin romper modelos downstream. Para trabajar Proyecto, sources y ref() de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: dbt compile muestra referencias resueltas y el DAG tiene dependencias correctas. La verificación principal será: dbt build debe ejecutar upstream antes del mart. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

dbt aporta valor cuando las transformaciones dejan de ser consultas sueltas y pasan a formar un DAG versionado, testeable y documentado. En trabajo real tendrás que justificar dependencias, contratos de datos y cómo despliegas cambios sin romper modelos downstream.

Ejemplo real

select * from {{ source('raw','orders') }}
-- mart:
select * from {{ ref('stg_orders') }}

Archivos o datos de entrada

• dbt/dbt_project.yml
• dbt/models/staging/stg_orders.sql

Práctica guiada

Abre sources.yml y stg_orders.sql del proyecto incluido.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: dbt/dbt_project.yml, dbt/models/staging/stg_orders.sql. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Proyecto, sources y ref()».
• Ejecuta la práctica guiada: Abre sources.yml y stg_orders.sql del proyecto incluido. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Añade un stg_customers y haz que un mart dependa de ambos staging. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: dbt compile muestra referencias resueltas y el DAG tiene dependencias correctas. Después ejecuta la comprobación: dbt build debe ejecutar upstream antes del mart.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Hardcodear bases/esquemas rompe portabilidad entre dev/prod.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Añade un stg_customers y haz que un mart dependa de ambos staging.

Resultado esperado

dbt compile muestra referencias resueltas y el DAG tiene dependencias correctas.

Cómo verificarlo

dbt build debe ejecutar upstream antes del mart.

Checklist de validación

• El resultado cumple: dbt compile muestra referencias resueltas y el DAG tiene dependencias correctas.
• Has ejecutado esta verificación y puedes explicar el resultado: dbt build debe ejecutar upstream antes del mart.
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• Hardcodear bases/esquemas rompe portabilidad entre dev/prod.

Qué debes recordar

dbt debe hacer explícitas dependencias, tests y documentación de tus transformaciones.

Preguntas de entrevista

• ¿Qué test o contrato añadirías a este modelo y por qué? Aplícalo concretamente a «Proyecto, sources y ref()».
• ¿Cómo comprobarías que el cambio no rompe modelos downstream? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Añadirás tests de calidad.

Recursos de esta lección