面向使用 dbt + DataHub 构建数据平台的中大型数据工程团队。核心痛点:dbt 模型层的 Schema 变更(字段重命名、类型修改等)经 PR 合并后,会沿血缘向下游传播,导致看板断裂、ETL 失败、报表口径错乱;而传统 CI 只能跑测试,无法基于真实血缘判断"这次改动到底影响谁、谁负责、是否安全"。
ChangeNode 把 dbt Schema 变更控制嵌入 GitHub PR 流程,在合并前用 真实 base/head Schema Diff + DataHub 字段级血缘 + 隔离 Runner 验证证据给出确定性结论:允许、拒绝还是需人工审批。
核心功能概要: 在合并之前,看清并控制每一次 dbt Schema 变更。
- 真实 base/head Schema Diff:分别构建 PR 的 base 与 head,在隔离 DuckDB 中读取真实输出Schema,而非从文本改动猜测结构变化。
- 受限 DataHub 上下文:通过 Streamable HTTP MCP Gateway查询精确字段路径、负责人和治理信号,超出固定 scope 直接拒绝。
- 确定性风险与状态机:Schema 类型、保护标签、允许动作和状态转换由代码判定;新的 PR head会使旧决策与证据失效,杜绝"用旧决策套新代码"。
- 持久化补丁范围:LLM 只接收已批准的 SQL 文件;schema YAML坐标由策略确定性修改,范围漂移在提案前阻断。
- 隔离 Runner 证据:在断网、非 root、受限资源的容器内执行固定 dbt命令,只有验证通过才允许创建修复 commit。
- GitHub-first 决策:Apply / Reject / Retry 只通过当前 head 的 GitHub Check actions 进入,绑定 App、仓库、installation、head,不提供绕过 GitHub 身份的审批入口。
关于系统内触发与决策相关功能的开发工作：GitHub App 统一接收 PR/Check/Merge 事件;GitHub Check Action 作为唯一决策入口;绑定 App/repository/installation/head
关于上下文与记忆平面相关功能的开发工作：DataHub 提供生产 Schema 与字段级血缘,经 MCP Gateway受限查询;写回由确定性服务调用,不交给 LLM
关于执行与验证平面相关功能的开发工作：隔离 Runner(断网、非 root、资源/超时限制)跑 dbt build 生成证据;commit 先持久化,再独立推进分支
评论