¿Cómo sé qué se rompe downstream antes de cambiar un modelo de dbt?

Una columna renombrada o un modelo eliminado se ven seguros en el diff de un PR si nada downstream lo referencia visiblemente en el mismo archivo - eso no dice nada sobre qué lo consume realmente tres modelos más allá.

El grafo de linaje ya existe - probablemente no lo está leyendo

Cada ejecución de dbt produce manifest.json, que codifica por completo el grafo de dependencias del proyecto - las fuentes upstream y los consumidores downstream de cada modelo, ya calculados. dbt ls --select +my_model+ lista todo lo upstream y downstream de un modelo dado directamente desde ese grafo, sin abrir dbt docs ni rastrear la estructura de carpetas a mano.

Las exposures convierten "downstream" en algo concreto

Una entrada en exposures.yml liga un modelo a un consumidor real fuera del propio DAG de dbt - un dashboard, una sincronización reverse-ETL, un reporte que alguien realmente mira. Sin exposures, "nada depende de este modelo" solo significa que nada dentro de dbt depende de él, lo cual es una afirmación más débil y a menudo engañosa si el consumidor real es una herramienta de BI que dbt no puede ver.

Hacer esto antes de un cambio disruptivo, no después

Correr dbt ls --select +model_name contra el selector de un modelo modificado como chequeo de CI pre-merge detecta el caso donde un renombrado o una columna eliminada rompe tres marts downstream antes de que el PR se fusione - no después de que alguien note días más tarde que un dashboard está silenciosamente mal.