SQL指标血缘梳理的核心是显性化、可追溯、可维护地呈现指标值的来源、加工过程及下游影响，需结合静态解析与运行时验证，建立可信依赖网络。
SQL指标血缘梳理的核心，是把“一个指标值从哪来、经过哪些加工、影响哪些下游”这条链路显性化、可追溯、可维护。不是单纯画图，而是围绕数据生产流程建立可信的依赖关系网络。
明确血缘追踪的边界和粒度
血缘不是越细越好，也不是越粗越省事。关键看使用场景：
- 运维排查：需要精确到字段级（如ods_user表的reg_time字段 → dw_user_d表的first_login_day字段 → ads_user_summary表的new_user_cnt指标）
- 影响评估：关注表级或任务级依赖（改了某张中间表，哪些报表/接口会失效）
- 治理落地：需关联业务语义（指标定义文档、口径说明、责任人）
建议初期以“SQL脚本→输入表→输出表→字段映射”为最小追踪单元，再逐步挂载业务标签。
从SQL解析入手，自动提取结构化依赖
手工标注不可持续。必须借助SQL解析能力还原真实依赖：
- 用ANTLR或sqlglot解析SQL AST，识别FROM/JOIN子句中的表名、SELECT中的字段别名、INSERT INTO目标表
- 特别注意：CTE（WITH子句）要展开递归解析，视图需穿透到基表，UDF需配置映射规则
- 对INSERT/UPDATE语句，区分写入目标（output）和读取源（input）；对SELECT语句，只提取input
解析结果存为三元组：(source_table, source_field) → (target_table, target_field) → (job_id, sql_file)
打通调度系统与元数据平台，补全运行时上下文
静态解析只能看到“可能的依赖”，真实血缘还需运行时验证：
- 接入调度系统（如Airflow、DolphinScheduler）的task DAG，将SQL任务节点与上下游任务绑定
- 采集执行日志中的实际扫描表（如Spark的HiveScan事件、Trino的QueryCompletedEvent）
- 将字段级血缘与调度周期、负责人、SLA等级等元数据打标，支撑影响分析和告警联动
例如：某日志表字段被修改后，系统自动比对历史执行快照，标记出最近7天内引用该字段但未更新的SQL任务。
设计轻量可用的血缘查询与展示方式
血缘价值在用，不在存。提供两类核心能力：
- 正向追踪：选中一张表/一个字段 → 查看所有下游指标、报表、API服务（支持按层级展开、过滤离线/实时链路）
- 反向溯源：输入指标名称或报表ID → 展示完整上游路径，高亮最近一次变更节点和风险点（如跨集群读取、无主键JOIN）
- 前端展示避免堆砌全图，优先呈现关键路径+变更热点+责任人浮层，支持导出影响范围清单
不复杂但容易忽略：给每个血缘关系打上“可信度分”（如解析得出=0.8，日志验证=1.0，人工标注=0.95），方便使用者判断依据强度。
