dbt

Junior

¿Qué hay realmente dentro de run_results.json de dbt, y por qué vale la pena leerlo directamente?

Cada ejecución de dbt escribe este archivo en target/, lo abras o no. Ya contiene la respuesta a «qué modelo es lento».

Leer en:
execution_time thread_id / concurrencia status
Cuánta señal aporta cada campo para investigar un modelo lento - no es un desglose medido.

No hace falta cuenta de dbt Cloud, ni historial de consultas del warehouse, ni instrumentación adicional - target/run_results.json ya tiene el tiempo por modelo de cada ejecución desde la última vez que limpiaste el directorio target.

La forma del archivo: un objeto de resultado por nodo

El array results tiene una entrada por cada modelo, test o seed que se ejecutó, cada una con un unique_id, un status («success», «error», «skipped»), un execution_time en segundos, un thread_id, y un array timing que desglosa ese tiempo en fases de compilación y ejecución con timestamps reales.

# los 10 modelos más lentos de la última ejecución jq -r '.results[] | [.unique_id, .execution_time] | @tsv' target/run_results.json | sort -k2 -n -r | head -10

El thread_id habla de concurrencia, no solo de identidad

dbt ejecuta modelos en paralelo hasta el número de --threads que hayas indicado. Si tus modelos más lentos comparten el mismo thread_id y se ejecutaron uno detrás de otro en lugar de solaparse con otro trabajo, eso es un problema de forma del DAG - una cadena de dependencias que fuerza ejecución en serie - no un problema de lentitud por modelo. Vale la pena revisarlo antes de pasarte una tarde optimizando SQL que nunca fue el cuello de botella.

Lo que no te puede decir

Solo tiempos, no costo. run_results.json no tiene cifras de bytes escaneados ni de créditos consumidos - para el costo de cómputo en Snowflake o BigQuery necesitas igualmente el historial de consultas propio del warehouse, cruzado con la ejecución de dbt mediante un comentario de consulta o un query ID si tu adaptador lo registra. Es un vacío real, no algo que convenga disimular.

Este es exactamente el archivo que leen las reglas de dbt de opti-pipe - sin necesidad de cuenta de dbt Cloud ni credenciales del warehouse, solo el archivo que tu último dbt run ya escribió en disco.

Mira cómo se ve esto en tu propio pipeline.

Sube un event log real de Spark, un run_results.json de dbt, o una exportación de métricas de Flink, y recibe recomendaciones concretas que requieren tu aprobación - no otra regla general.