技能介绍

问题：dbt 的血缘并不直接摆在你面前

在 dbt 项目里，血缘通常被理解成 dbt Cloud 上那张可视化图。但在本地 CLI 或私有化环境里，这些信息其实散落在两处：dbt docs generate 产出的 manifest.json 构件里，每个节点的 depends_on 字段记录了上游依赖；而 ref() 和 source() 的语义本身又写在 Jinja 代码中。想画一张依赖图，或者排查某个模型改动会波及哪些下游，要么依赖 dbt Cloud 的界面，要么自己解析这份结构复杂的 JSON。前者对本地项目不可用，后者手工处理容易出错，也很难沉淀成可复用的脚本。

它如何工作：从两条构件路径提取

这个技能的思路是复用两条官方构件通道，而不是重写一套解析逻辑：

本地构件：读取 manifest.json，定位类型为 model 的节点，从 depends_on 字段读出上游节点标识；
Cloud API：调用 dbt Cloud API v2，获取指定项目或环境下的 DAG 与节点依赖元数据。

提取过程大致分为几步：

载入构件，枚举目标节点，按需过滤掉 test、seed 等非模型节点；
解析每个节点 depends_on 中的 ref() 与 source() 语义，得到上游节点标识；
汇总为有向图，节点代表模型，边由上游指向下游；
将图结构交给 DAG 渲染与可视化环节。

适用边界与注意点

本地路径依赖 manifest.json 的标准字段。如果项目结构变更后没有重新生成构件，提取出的血缘会滞后，建议提取前重新执行 dbt docs generate。
dbt Cloud API v2 路径需要有效的服务令牌，并受速率限制约束，适合跨项目汇总视图，不适合对大量本地仓库做批量刷新。
宏生成的动态 ref()（通过变量传入不同模型名）可能让静态的 depends_on 指向不存在的节点，需要退回编译后的完整 manifest。
按 tag 等条件筛选出的 DAG 子集并不等同于项目完整血缘，排查影响范围时要确认过滤条件是否合理。