Что на самом деле внутри dbt run_results.json, и почему его стоит читать напрямую?

Не нужен ни аккаунт dbt Cloud, ни история запросов в хранилище, ни дополнительная инструментация — в target/run_results.json уже есть тайминг по каждой модели за каждый запуск с момента последней очистки target.

Форма файла: один объект результата на ноду

Массив results содержит по одной записи на каждую модель, тест или seed, который выполнялся: unique_id, status («success», «error», «skipped»), execution_time в секундах, thread_id и массив timing, разбивающий это время на фазы compile и execute с реальными таймстемпами.

Thread ID говорит о параллелизме, а не только об идентификаторе

dbt выполняет модели параллельно, в пределах переданного --threads. Если самые медленные модели у вас имеют один и тот же thread_id и выполнялись строго последовательно, а не параллельно с чем-то ещё — это проблема формы DAG (цепочка зависимостей, вынуждающая последовательное выполнение), а не медленности конкретной модели. Стоит проверить, прежде чем тратить вечер на оптимизацию SQL, который никогда и не был узким местом.

Чего он не расскажет

Только тайминг, не стоимость. В run_results.json нет данных о прочитанных байтах или потраченных кредитах — для оценки стоимости вычислений в Snowflake или BigQuery всё равно нужна собственная история запросов хранилища, связанная с запуском dbt через комментарий запроса или query ID, если ваш адаптер его логирует. Это реальный пробел, а не то, что стоит замалчивать.