dbt run执行卡住无报错 单模型运行正常问题排查求助

全量执行dbt run无报错卡进度、单模型单独执行全部正常、数据库侧查不到运行中查询，这类问题基本不是模型SQL语法错误，按以下优先级排查即可：

• 优先调整线程配置
  先打开对应环境的profiles.yml，把threads参数改成2再重新跑全量。这是最高发的诱因：单模型执行时单线程资源占用低，不会触发调度问题；全量跑时如果线程数开得过高（≥8），很容易触发dbt线程调度死锁、或者数仓连接池被打满，进程会直接挂起，既不会抛错，也不会真的把查询提交到数仓执行层，所以你查不到运行中的任务。如果改2线程能正常跑通，再逐步往上调线程数，找到当前环境可承载的合理阈值即可。
• 排查隐性循环依赖
  显性循环依赖dbt会在启动阶段直接报错，但如果是宏里的动态ref()引用、ephemeral模型嵌套带来的隐性循环，单模型执行时不会触发全链路依赖解析，全量调度到循环节点时就会直接卡死。可以执行dbt ls --resource-type model --output json导出所有模型的依赖链，逐一核对有没有跨模型的循环引用。
• 开debug日志定位卡壳节点
  执行带debug参数的全量命令dbt run --debug，等进程卡到第89步时看最后一行日志的输出：
  • 如果日志停在模型编译阶段，说明是Jinja渲染逻辑卡了，常见原因是宏里写了无超时配置的外部请求、本地文件读取逻辑死锁，单模型执行时参数分支没触发这段逻辑，全量跑到对应模型时才会触发死等。
  • 如果日志停在数据库连接提交阶段，就是连接泄漏导致的：之前跑完的模型没有正确释放数据库连接，到当前节点时连接池已经耗尽，又没有配置连接超时规则，进程就会一直挂起。可以在dbt_project.yml里加全局超时配置解决：

    models:
      +query_timeout: 300
      +connect_timeout: 30
    

• 清理残留锁和临时表
  如果你用的是支持事务的数仓（Postgres、Redshift、Snowflake等），之前异常中断的dbt任务可能残留未提交的事务、或者持锁的临时表，全量跑到依赖这些锁资源的模型时，会一直等待锁释放，且因为查询还没进入执行层，你查运行中任务列表看不到记录。这种情况手动清理当前账号持有的所有锁、临时表，或者重启数仓连接后再重试即可。

90%以上同现象的问题都是线程数配置过高导致的，优先试第一个方案，基本能直接解决。

内容的提问来源于stack exchange，提问作者Raghad