Buenas prácticas #5: dbt, la herramienta detrás de Prophecy

Sesión 5

Mauro Loprete

2026-09-14

Buenas practicas DBX

dbt

La tecnología detrás de Prophecy

Taller semanal · Sesión 5

Mauro Loprete

Arranque de la segunda vuelta del taller. Cambio de plano: las sesiones 1 a 4 fueron sobre el SQL que corre; esta es sobre el proyecto que lo genera. Si bien ya sabemos usar Prophecy, para entender lo que pasa por debajo necesitamos conocer un poco mas de DBT, ya sea para pensar nuevas soluciones, revisar correctamente los diffs y para entender las herramientas que estamos usando desde que plasmamos la lógica en el IDE hasta que termina en producción.

Cómo funciona Prophecy: el camino feliz

Lo que dibujás en el lienzo nunca corre tal cual: se compila dos veces antes de tocar un dato.

Gems visualesse persisten como JSON en .prophecy/

→

Compilador de Prophecytraduce cada gem a SQL + YAML

→

Proyecto dbtlo que se comitea y se revisa en la PR

→

Compilación dbtresuelve Jinja, ref() y el orden

→

WarehouseDatabricks ejecuta el SQL final

• El editor visual es una vista: la verdad que corre en producción es el proyecto del repo
• De la caja naranja en adelante ya no hay nada de Prophecy: es dbt estándar, el tema del resto de la sesión

Todo lo que mergeás y todo lo que corre en producción sale de la caja naranja, no del lienzo.

Este es el mapa de toda la sesión: dos compiladores encadenados. El primero es de Prophecy y es opaco; el segundo es dbt y es abierto, documentado y estándar. La caja naranja es la bisagra: ahí termina la parte propietaria y empieza la parte que cualquiera puede leer, correr y auditar. Recalcar que el JSON de .prophecy/ y el proyecto dbt viven en el mismo repo y viajan juntos en cada commit: por eso los diffs traen ambos. Si bien ya sabemos usar Prophecy, entender este camino sirve para pensar soluciones nuevas, revisar bien los diffs y saber qué pasa desde que la lógica se plasma en el IDE hasta que llega a producción.

El desvío: gems que no compilan a SQL

Las gems con conexiones externas (Excel en SharePoint, archivos en Volumes, otras bases) no se pueden traducir a un SELECT: toman otro camino.

Gem con conexión externaSharePoint · Volumes · bases externas

→

Orquestador de Prophecycódigo propietario, fuera de dbt

→

Tabla temporalescribe el dato en el warehouse

→

Proyecto dbtla referencia como una tabla más

• El tramo rojo levanta el orquestador y abre la conexión antes de mover un solo dato: el costo es de arranque, no de volumen. Leer un Excel de 5 filas puede tardar más de 2 minutos
• Prophecy resuelve esas dependencias por su cuenta: el dato entra al proyecto dbt ya materializado como tabla
• Es el tramo que job_generator todavía no cubre: para generar esos jobs hay que parsear esa lógica propietaria

Pipeline lento: antes de mirar el SQL, preguntate en qué camino están sus gems. El rojo cuesta caro aunque el dato sea chico.

La pregunta que esta slide responde: por qué gems que parecen triviales tardan minutos. La respuesta es que no son SQL: son código propietario que corre en el orquestador de Prophecy, con costo fijo de arranque y conexión que no depende del tamaño del dato. El ejemplo del Excel de 5 filas y más de 2 minutos es real y conviene contarlo. Segundo mensaje: este tramo es la razón por la que job_generator todavía no cubre todos los casos de uso; para eso hay que parsear la lógica propietaria, y es trabajo pendiente de la herramienta. Cierre: una vez que el dato aterriza en la tabla temporal, el resto vuelve a ser el camino feliz de la slide anterior.

Los mensajes del Prophecy IDE

Los carteles que el Studio muestra mientras editás son estas mismas etapas, contadas en vivo:

Initializing projectcarga los archivos del proyecto y prepara el editorStudio

Processing changesdetecta qué archivos dependen de tu cambio y los actualizaProphecy

Generating codetraduce las gems a SQL + YAML: acá se escribe el proyecto dbtProphecy

Compilingcalcula el esquema de salida de cada gemProphecy

DBT initializationprepara el sandbox de dbt y compila los modelosdbt

Runningorquesta la corrida y sus dependenciasAutomate

Running query in warehouseel SQL final corre en Databricks: visible en el Query HistoryWarehouse

• Lo que no es SQL corre por Prophecy Automate: es el orquestador del camino rojo
• Cuanto más grande el proyecto (más gems, más dependencias), más duran estos carteles

El problema: la PR que se aprueba sin leer

Un diff típico de Prophecy: seis archivos que nadie escribió a mano.

Mprophecy/PROJECT_1/models/PIPELINE_1/mov_diarios.sqlModelo · SQL

Mprophecy/PROJECT_1/models/PIPELINE_1/schema.ymlTests y docs

Mprophecy/PROJECT_1/dbt_project.ymlConfig global

Mprophecy/PROJECT_1/.prophecy/models/PIPELINE_1/mov_diarios.jsonMetadata visual

Mprophecy/PROJECT_1/.prophecy/pipeline/PIPELINE_1.jsonMetadata visual

Nprophecy/PROJECT_1/macros/limpiar_monto.sqlMacro

Todo esto corre en producción igual que el código escrito a mano, y la PR es el único filtro antes de que corra.

Nombrar el elefante sin culpar a nadie: las PRs de Prophecy se aprueban rápido porque el diff no se entiende, no por vagancia. La causa es que el equipo diseña en el editor visual y nunca necesitó aprender el formato del proyecto que Prophecy escribe abajo. El argumento para invertir estos 30 minutos: el visual es una vista, el repo es la verdad; lo que se mergea es dbt, no gems. Dejar que el diff intimide un momento antes de pasar a la siguiente slide, que lo ordena en dos mitades.

La regla: el diff tiene dos mitades

Prophecy no inventa un formato propio: comitea un proyecto dbt estándar más la metadata del lienzo.

El proyecto dbtSE REVISA

Modelo · SQLla lógica que corre

Tests y docslo que protege al dato

Config globalalcance: el proyecto entero

Macrouna función, muchos modelos

Dependenciascódigo de terceros

La metadata visualNO SE REVISA A MANO

models/*.jsoncada gem, editable en el lienzo

pipeline/*.jsonconexiones, dependencias, parámetros

El chequeo es de presencia: que ningún JSON falte ni se renombre. La lógica se revisa en el SQL de al lado.

Meta de hoy: que cada archivo del diff te diga qué es. La próxima sesión: qué preguntarle a cada uno, con un diff de ejemplo por cada color.

La regla para llevarse aunque se olvide todo lo demás: todo diff de Prophecy se parte en dos mitades. La izquierda es el proyecto dbt, lo que el compilador escribió para que corra en producción: eso se revisa; hoy aprendemos qué es cada tipo y la sesión 6 enseña qué preguntarle. La derecha es lo que Prophecy guardó para poder redibujar el lienzo: no se lee línea a línea, solo se chequea que ningún archivo desaparezca. Los colores de los chips son el mapa de la serie: cada uno vuelve en la sesión 6 con un diff real de ejemplo y la pregunta que hay que hacerle.

Qué es dbt

dbt viene de data build tool, y va en minúscula. La idea completa:

Cada transformación es un SELECT versionado en git. dbt lo convierte en tabla o vista, en el orden correcto, con tests.

Pieza	Quién se ocupa
La lógica: un SELECT por modelo	Vos, o Prophecy por vos
El DDL: CREATE TABLE AS, MERGE	dbt lo escribe
El orden de ejecución	dbt lo deduce de los ref()
Tests y documentación	Los declarás en YAML, dbt los corre

• dbt no procesa datos: compila SQL y se lo manda a Databricks. El que trabaja es el warehouse de siempre

La definición operativa: dbt es un compilador y orquestador de SELECTs, no un motor. Ese último bullet es la conexión con toda la serie: como dbt no ejecuta nada por su cuenta, todo lo de las sesiones 1 a 4, el Query Profile, los patrones caros, las window functions y el clustering, aplica tal cual a lo que genera. DDL por si alguien pregunta: las sentencias que crean o modifican objetos, CREATE, ALTER, DROP. El pitch de por qué existe dbt: antes de esto las transformaciones eran scripts SQL sueltos sin orden, sin tests y sin lineage; dbt les puso ingeniería de software encima.

Cómo se usa: Core, Cloud y nuestro caso

• dbt Core: la herramienta open source de línea de comandos. Corre donde la invoques: tu máquina, un job, CI
• dbt Cloud: la plataforma comercial de dbt Labs. IDE web, scheduler y ambientes, con Core adentro
• Nuestro caso: Prophecy escribe el proyecto y lo comitea; los jobs lo ejecutan con Core. Nadie tipea dbt run a mano, pero los logs hablan este idioma:

Comando	Qué hace
dbt run	Construye los modelos: crea las tablas y vistas
dbt test	Corre los tests declarados en los YAML
dbt build	run + test, en orden de dependencias
dbt compile	Genera el SQL final sin ejecutar nada (protagonista de la sesión 6)
dbt deps	Instala los paquetes de packages.yml

Solo mencionar Cloud y CLI, sin profundizar: el mensaje es que dbt existe fuera de Prophecy y que el proyecto del repo se puede correr con cualquiera de los dos. Vale la pena instalar dbt Core en una máquina del equipo para la tarea de la semana: pip install dbt-databricks alcanza. Los comandos importan porque aparecen en los logs de los jobs: cuando un job falla, el error dice en qué comando y en qué modelo murió, y saber leer eso ya resuelve la mitad de los tickets.

Qué NO hace dbt

• dbt solo genera SQL: no lee archivos, no abre conexiones, no mueve datos por su cuenta. Transforma lo que ya existe como tabla o lo que Databricks alcanza con SQL (Volumes, conexiones federadas)
• La ingesta la resuelven otras herramientas. La clásica del stack es Fivetran: tan de la mano van que hoy son la misma empresa (dbt Labs y Fivetran se fusionaron en 2025)
• Databricks tiene su propia apuesta: Lakeflow Connect (conectores propios, donde antes dependía de Fivetran) y Spark Declarative Pipelines (lo que antes era DLT, Delta Live Tables). Y en Beta, un editor visual estilo Prophecy: misma idea, JSON que compila a código SDP en SQL o PySpark

La regla: si el dato no se alcanza con un SELECT desde el warehouse, no es un problema de dbt. Es un problema de ingesta.

La frontera que ordena el deck: dbt empieza donde el dato ya es consultable con SQL desde Databricks. Cierra el círculo con la slide del desvío: las gems con código propietario existen precisamente porque dbt no puede ir a buscar un Excel a SharePoint. Y conecta con sources.yml, que viene más adelante: las sources son cómo dbt declara esa frontera, tablas que otro proceso carga y el proyecto solo consume. La fusión Fivetran + dbt Labs se anunció en octubre de 2025; el pitch de ellos es cubrir ingesta y transformación en un solo stack. El editor visual de Databricks en Beta es Lakeflow Designer: vale la pena el paralelismo con Prophecy porque la arquitectura es la misma que la de esta sesión, metadata visual que compila a código abierto que corre en el cluster, o sea que todo lo de hoy aplica igual si algún día se migra de herramienta.

La conexión con Databricks: dbt-databricks

dbt-databricks es el adapter: el paquete que traduce lo que dbt quiere hacer al dialecto y las APIs de Databricks. La conexión vive en profiles.yml:

prophecy-profile:
  target: dev
  outputs:
    dev:
      type: databricks
      host: adb-xxxx.azuredatabricks.net
      http_path: /sql/1.0/warehouses/abc123   # un SQL warehouse
      catalog: dev
      schema: analytics
      token: "{{ env_var('DBT_TOKEN') }}"

• Cada target apunta a un catálogo y esquema de Unity Catalog: eso decide dónde caen los modelos, y es lo que separa dev de prod
• Las queries salen por un SQL warehouse: aparecen en el Query History como cualquier otra (sesión 1)

En Prophecy esta conexión es la fabric que se elige al correr el pipeline: fabric y target son la misma idea, un ambiente de ejecución con sus credenciales y su destino. El token del ejemplo sale de una variable de entorno a propósito: credenciales nunca van al repo; para jobs productivos la opción actual es OAuth machine-to-machine con un service principal. El punto pedagógico del catalog y schema por target: el mismo proyecto, sin tocar una línea, escribe en dev o en prod según contra qué target corra. Eso solo funciona si los modelos no hardcodean nombres, que es el anti-patrón de la slide de ref().

1

El proyecto, archivo por archivo

Lo que ves en el diff

dbt_project.yml: la cédula del proyecto

name: PROJECT_1
profile: databricks
model-paths: ["models"]

vars:
  fecha_inicio: "2020-01-01"

models:
  PROJECT_1:
    staging:
      +materialized: view
    marts:
      +materialized: table

• Uno por proyecto, en la raíz: nombre, rutas y configuración por carpeta
• El bloque models: fija defaults en cascada: todo staging/ sale como vista, todo marts/ como tabla. El + marca que es una config
• vars: define valores globales (ya llegamos)

En una PR, una línea cambiada acá puede cambiar la materialización de cuarenta modelos. Pesa más que cualquier diff de un modelo suelto.

La jerarquía de configuración completa, por si alguien pregunta: dbt_project.yml es el default, el YAML de la carpeta lo pisa, y el config() dentro del modelo pisa a los dos. Por eso el archivo es chico pero peligroso: opera al nivel más general. En los proyectos generados por Prophecy este archivo casi no cambia, así que cuando aparece en un diff es deliberado y merece leerse línea por línea.

Un modelo: un archivo .sql con un SELECT

-- models/marts/mov_diarios.sql
{{ config(materialized='table') }}

SELECT cliente_id, fecha, SUM(monto) AS monto_dia
FROM {{ ref('stg_movimientos') }}
GROUP BY cliente_id, fecha

• El nombre del archivo es el nombre del objeto en el catálogo: mov_diarios.sql crea catalogo.esquema.mov_diarios
• Siempre es un SELECT: el CREATE TABLE AS lo escribe dbt. Si ves DDL a mano en un modelo, algo anda mal
• materialized decide qué se crea: view (default), table, o incremental (tema de una próxima sesión)
• El config() ya lo vimos en la sesión 4: ahí declaramos liquid_clustered_by

Una tabla = un modelo = un dueño. dbt reconstruye la tabla entera desde su SELECT en cada corrida: por eso dos pipelines no pueden escribir la misma tabla, el segundo pisaría al primero.

Primer archivo del diff que ya queda resuelto: un .sql bajo models/ es una tabla o vista futura, y lo primero que se le mira es la materialización. La intuición de costo: view no materializa nada y se recalcula en cada lectura; table reconstruye todo en cada corrida; incremental agrega solo lo nuevo. En los modelos generados por Prophecy cada gem del pipeline visual suele aparecer como una CTE con su nombre adentro del SELECT, así que el archivo es más largo que este ejemplo pero la estructura es la misma. Verificar antes de la sesión con un modelo nuestro y tenerlo abierto para mostrar el paralelismo gem a gem. La cita final responde la queja clásica del equipo, cómo que varios pipelines no pueden escribir la misma tabla: en dbt la tabla no es un lugar al que se le agregan filas, es el resultado materializado de un único SELECT versionado; cada corrida la reconstruye desde ese modelo (o mergea lo nuevo si es incremental, pero siempre desde el mismo modelo), así que cualquier otro escritor queda pisado. Si dos flujos necesitan aportar filas a la misma tabla, el patrón correcto es que cada uno sea su propio modelo y un tercero los una con UNION ALL: el DAG y el lineage siguen diciendo la verdad y nadie pisa a nadie.

ref() y source(): así se arma el DAG

FROM {{ ref('stg_movimientos') }}         -- otro modelo del proyecto
FROM {{ source('core', 'movimientos') }}  -- tabla cruda que carga otro proceso

• dbt reemplaza cada llamada por el nombre completo catalogo.esquema.tabla según el ambiente: el mismo modelo lee de dev en dev y de prod en prod
• Con esas referencias dbt arma el DAG, el grafo de dependencias: de ahí saca el orden de ejecución y el lineage

El anti-patrón que hay que cazar en las PRs:

FROM prod.raw.movimientos    -- hardcodeado: corre, pero...

• Queda fuera del DAG: el orden ya no lo protege, el lineage miente, y en dev sigue leyendo de prod

Un FROM sin llaves es una bandera roja en la PR.

La regla más rendidora de toda la sesión: en un modelo dbt, todo FROM debería ser un ref o un source. DAG ya lo conocen del Query Profile de la sesión 1; es el mismo concepto a otra escala, dependencias entre modelos en vez de operadores dentro de una query. El hardcodeo aparece cuando alguien resuelve algo rápido en el editor SQL de Prophecy y pega el nombre completo. Los tres síntomas del bullet dan para un minuto cada uno: orden no garantizado significa carreras donde el modelo lee datos viejos; lineage mentiroso significa que un impact analysis no encuentra al consumidor; y leer de prod desde dev es el clásico susto de ambientes cruzados.

sources.yml: las tablas que dbt no construye

version: 2
sources:
  - name: core
    database: prod        # en Databricks: el catálogo
    schema: raw
    tables:
      - name: movimientos
        loaded_at_field: fecha_carga
        freshness:
          warn_after: {count: 24, period: hour}

• Declara las tablas crudas que ingesta otro proceso: la frontera entre nuestro proyecto y el resto del mundo
• Es lo que source('core', 'movimientos') va a buscar
• freshness: dbt source freshness avisa si la fuente lleva más de 24 horas sin datos nuevos

Una source nueva en el diff es una dependencia externa nueva: ¿quién carga esa tabla? ¿tiene dueño?

El nombre del archivo es convención: dbt lee cualquier YAML bajo models/, y sources.yml o schema.yml son los nombres habituales; Prophecy genera los suyos. La pregunta del cierre es la que importa en revisión: los modelos internos los protege el DAG, pero una source es una promesa de que otro equipo carga esa tabla. Si nadie firma esa promesa, el pipeline hereda un punto de falla silencioso. El freshness es la versión barata de un data contract: no evita el problema pero lo hace visible en el job en vez de en el dashboard del lunes.

2

Jinja

Variables, macros y paquetes

Por qué el SQL tiene llaves

Jinja es un motor de plantillas: texto con huecos que se rellenan al compilar. dbt lo usa arriba del SQL.

SELECT * FROM {{ ref('stg_movimientos') }}
{% if target.name != 'prod' %}
LIMIT 1000
{% endif %}

Compilado contra dev, queda:

SELECT * FROM dev.analytics.stg_movimientos
LIMIT 1000

• { ... } imprime un valor; {% ... %} es control de flujo: if, for
• Se resuelve antes de ejecutar: Databricks nunca ve una llave, solo recibe el SQL final
• target trae los datos del ambiente contra el que corrés: por eso el LIMIT existe solo fuera de prod

Desdramatizar el Jinja es el objetivo de la sección: las llaves asustan porque parecen otro lenguaje, pero el 95 por ciento de lo que van a ver son ref, source, config y var, o sea las cuatro cosas de esta sesión. El modelo mental correcto: Jinja genera texto SQL, no toca datos. Todo lo que hace Jinja podría hacerse escribiendo el SQL final a mano; existe para no repetir y para que el mismo código sirva en todos los ambientes. El ejemplo del LIMIT en dev es real y útil: desarrollo barato sin tocar la lógica.

Variables: valores que viven fuera del código

# dbt_project.yml
vars:
  fecha_proceso: "2026-09-01"

-- en cualquier modelo
WHERE fecha >= '{{ var("fecha_proceso") }}'

# override puntual, sin tocar el repo
dbt run --vars '{fecha_proceso: "2026-01-01"}'

• var("nombre", "default"): el segundo argumento evita el error si nadie la definió
• Uso típico: fechas de reproceso, flags, umbrales que cambian entre corridas
• El override de la línea de comandos gana sobre el dbt_project.yml

En la PR: si un modelo trae un valor mágico (una fecha, un umbral suelto), la pregunta es si debería ser una var.

La jerarquía completa: default en el código, valor en dbt_project.yml, override por línea de comandos, y gana el más específico. El caso de uso estrella en nuestro contexto es el reproceso: en vez de editar un modelo para recargar desde una fecha, se pasa la var en la corrida y el repo no se toca. Eso convierte una PR de emergencia en un parámetro de ejecución, que es exactamente donde tiene que vivir.

Macros: funciones que generan SQL

-- macros/limpiar_monto.sql
{% macro limpiar_monto(col) %}
    CAST(REPLACE({{ col }}, ',', '.') AS DECIMAL(18, 2))
{% endmacro %}

-- en un modelo
SELECT {{ limpiar_monto('monto_txt') }} AS monto

• Una macro se expande al compilar: el warehouse recibe el CAST, no la macro
• La regla de negocio vive en un solo lugar; sin macro, ese CAST estaría copiado en veinte modelos con tres versiones distintas
• Prophecy genera una en todos los proyectos SQL: generate_schema_name, que decide en qué esquema cae cada modelo. No se borra ni se toca sin charla previa

En la PR: un diff en macros/ alcanza a todos los modelos que la llaman. El radio de impacto no es el archivo, es el proyecto.

Misma lógica que una función en cualquier lenguaje, con la diferencia de que devuelve texto SQL. La de generate_schema_name merece el minuto de detalle: dbt trae un default que concatena el esquema del target con el esquema custom usando guion bajo, tipo default_my_schema, y Prophecy lo pisa con una versión directa que usa el esquema tal cual se declaró en el gem. Está documentado en la doc de Prophecy y si alguien la borra por accidente los modelos caen en esquemas con nombres concatenados raros. Es el ejemplo perfecto de macro con radio de impacto total: una función de diez líneas que decide dónde escribe todo el proyecto.

packages.yml: código de otros

packages:
  - package: dbt-labs/dbt_utils
    version: 1.3.0

• Dependencias del proyecto, como un requirements.txt: dbt deps las instala en dbt_packages/
• dbt_utils es el paquete estrella: tests genéricos y macros que evitan reinventar (deduplicación, pivots, comparar esquemas)
• Lo instalado en dbt_packages/ es código de terceros: no se revisa, no se edita, y no debería estar comiteado
• En Prophecy nadie edita este archivo a mano: se agrega desde Dependencies en los settings del proyecto, y lo elegido aterriza acá
• Tres orígenes: otros proyectos Prophecy (Package Hub), repos de GitHub (fijados por tag, commit o branch) y paquetes del dbt Hub, cuyas macros quedan disponibles en el gem de Macro

En la PR: ¿la versión está fijada? Un paquete sin versión fija es un deploy distinto cada vez que corre dbt deps.

El paralelo con requirements.txt o package.json ordena la slide entera: mismo concepto, mismo riesgo, misma regla de fijar versiones. Los paquetes se buscan en hub.getdbt.com. Si en nuestros repos aparece dbt_packages comiteado conviene limpiarlo y agregarlo al gitignore, mismo tratamiento que node_modules. dbt_utils da para mencionar dos o tres macros concretas si hay tiempo: deduplicate, que es el ROW_NUMBER de la sesión 3 empaquetado, y los tests genéricos como expression_is_true. Lado Prophecy, según su doc de dependencies (link en referencias): se gestionan desde los settings del proyecto o el engranaje de la sección Packages de la barra lateral, lo agregado aparece en esa barra para arrastrar al lienzo, y para dependencias de GitHub existe el flag warn unpinned, que avisa cuando el puntero no tiene versión: la misma regla del cierre, avisada por la propia herramienta.

Cómo encaja todo: del modelo al warehouse

Macros propiasmacros/*.sql

Paquetesdbt_utils y cía

▼▼

Modeloun SELECT con {{ llaves }}

→

Jinjaresuelve ref, source y var · expande macros

→

SQL finalpuro SQL, sin llaves

→

Adapterdbt-databricks: dialecto y APIs

→

Databricksel warehouse ejecuta

• Las macros que expande Jinja vienen de dos lados: las del proyecto (macros/) y las que traen los paquetes de packages.yml
• El adapter vive fuera del proyecto: es el dbt-databricks de profiles.yml, el que traduce al dialecto y las APIs de Databricks

Ningún dato pasa por dbt: el modelo termina siendo SQL final, y ese SQL entra al warehouse por el enchufe del adapter.

El resumen visual de la sección, con los mismos colores de los chips del diff: naranja el modelo, verde las macros, teal los paquetes. Dos aclaraciones que suelen surgir: el adapter no va en packages.yml, es un paquete de Python que se instala con pip y se referencia desde profiles.yml; y si mañana se cambia de warehouse, se cambia el adapter (dbt-snowflake, dbt-bigquery) y el proyecto queda igual, esa es la gracia del diseño. Las macros de paquetes se llaman con prefijo, tipo dbt_utils.deduplicate, y los tests genéricos también son macros por debajo. Buen momento para pausar preguntas antes del cierre de la sesión.

Para esta semana

1. En el proyecto del pipeline que estas trabajando identifica los paquetes utilizados, ver si tiene alguna macro y como se referencian desde los modelos.
2. Revisa en tus últimos PR con cambios “controlables” y fíjate si el cambio de lógica es entendible mirando el diff en los models/
3. Si tenes ganas, instala dbt en tu entorno local y probá correr los modelos del proyecto. . . .

Para la próxima sesión, traé los hallazgos de los puntos 1 y 2.

Tarea deliberadamente de lectura, no de escritura: el objetivo de la sesión era entender lo que hay en el repo, así que la práctica es mirar el repo. El punto 2 casi seguro encuentra algo, porque los hardcodeos existen en cualquier proyecto con historia. La advertencia final es en serio: cambiar un FROM hardcodeado por un ref puede cambiar de qué ambiente lee el modelo, así que es un cambio de comportamiento, no cosmético. Lo que traigan de los puntos 1 y 2 es el insumo directo de la sesión 6, que revisa diffs y PRs reales en vivo.

Próxima sesión

La PR, a fondo

Un diff de ejemplo por cada tipo de archivo, el Job que corre en producción, el checklist completo y revisión de PRs reales del equipo

¿Preguntas? · Mauro Loprete

Hoy quedó el mapa completo del proyecto: qué es cada archivo y cómo encajan las piezas. La sesión 6 es la aplicación: un diff de ejemplo por cada tipo de archivo con la pregunta que hay que hacerle, el Job de producción con sus dbt tasks, dbt compile en vivo, el checklist completo y la revisión de dos o tres PRs reales del equipo. Lo que traiga el equipo de la tarea de esta semana es el insumo directo. Para más adelante queda el otro candidato fuerte: modelos incrementales, con is_incremental, la estrategia de merge del adapter y el full refresh.

Anexo: dbt en tu máquina

# 1. Entorno de Python (3.9+)
python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate

# 2. El adapter trae dbt Core adentro: una sola instalación
pip install dbt-databricks
dbt --version

# 3. Credenciales en ~/.dbt/profiles.yml (el de la slide del adapter)

# 4. Probar contra el proyecto clonado
dbt debug        # valida Python, profiles y conexión
dbt deps         # instala los paquetes de packages.yml
dbt compile      # compila todo sin ejecutar nada

• host y http_path salen de Connection details del SQL warehouse; el token es un token personal de Databricks
• dbt debug primero, siempre: valida la conexión antes de intentar cualquier otra cosa
• Con dbt compile andando llegás con ventaja a la próxima sesión, que lo usa en vivo

Anexo para que cualquiera del equipo deje dbt corriendo local en diez minutos. El token personal se genera en Databricks en User Settings, Developer, Access tokens; va en el profiles.yml de la home, nunca en el repo. El profiles.yml de referencia es el de la slide del adapter, con catalog y schema apuntando a dev. Aclarar que compile no toca datos ni gasta cómputo del warehouse más allá de conectarse, así que es seguro jugar. Si alguien usa uv o pipx, el paquete es el mismo dbt-databricks; lo único que importa es que dbt –version muestre el adapter en la lista.

Referencias

• What is dbt? — doc oficial de dbt
• dbt_project.yml — referencia oficial
• Sources — doc oficial de dbt
• Jinja y macros — doc oficial de dbt
• Packages — doc oficial de dbt
• Conectar dbt Core a Databricks — doc oficial de Databricks
• dbt-databricks — repo del adapter
• generate_schema_name en proyectos SQL — doc de Prophecy
• Mensajes de estado del Studio — doc de Prophecy
• Dependencias en proyectos SQL — doc de Prophecy