SQL 数据血缘关系如何梳理？

sql中隐式血缘关系主要产生于CREATE VIEW/物化视图、CTE多次引用、动态SQL拼接、子查询、触发器NEW/OLD、INSERT/UPDATE语句、pg_depend局限性、分区表名硬编码及外部FDW表等场景。

SQL 中哪些地方会隐式产生血缘关系？

血缘不是写在 SQL 里的元数据，而是从实际执行逻辑中反推出来的依赖链。最常被忽略的是 CREATE VIEW 和 CREATE MATERIALIZED VIEW：它们的定义体里嵌套的 select 语句直接引用了上游表或视图，但这种依赖不会自动注册到系统目录（比如 postgresql 的 pg_depend 对物化视图支持不完整）。另外，WITH 子句中的 CTE 名称看似局部，一旦被后续查询多次引用，就构成了分支血缘；而动态拼接 SQL（如 python 中用 f"SELECT * FROM {table_name}"）则完全脱离静态分析能力。

• INSERT INTO t1 SELECT ... FROM t2 明确建立 t2 → t1 血缘
• UPDATE t1 SET x = (SELECT y FROM t3) 引入子查询级联依赖
• 触发器里的 NEW/OLD 引用虽不显式写表名，但绑定到触发目标表

pg_depend 能信多少？为什么 pg_dump 不导出依赖顺序？

PostgreSQL 的 pg_depend 是目前最接近“官方血缘”的系统表，但它只记录对象级硬依赖（比如函数依赖某个类型），不捕获列级、表达式级或运行时才确定的依赖。例如，一个函数里用 EXECUTE 'SELECT ' || colname || ' FROM t'，pg_depend 根本看不到 t。更麻烦的是，pg_dump 按对象 OID 排序输出，而非按依赖拓扑排序——所以即使你导出了一堆视图和函数，还原时仍可能因上游对象还没建好而报 relation "xxx" does not exist 错误。

• 查列级依赖得结合 pg_rewrite + pg_get_expr() 解析规则树
• pg_dump --inserts 生成 INSERT 语句，但不保证目标表已存在
• 物化视图刷新任务（REFRESH MATERIALIZED VIEW）本身不进 pg_depend，需单独跟踪调度逻辑

如何用 sqlparse 做轻量级血缘提取？

sqlparse 不执行 SQL，只做词法解析，适合 CI 阶段快速扫描。它能把 SELECT a, b FROM users JOIN orders using(user_id) 拆成明确的 FROM 和 JOIN Token，再递归提取所有标识符。但要注意边界情况：

• 子查询里的 FROM 容易被当成外层的，需用括号层级判断作用域
• 别名（FROM logs l）不能直接当源表，要回溯到别名定义处
• union ALL 各分支的 FROM 是并列上游，不是串行依赖

示例片段：

import sqlparse from sqlparse.sql import IdentifierList, Identifier, Parenthesis 
def extract_tables(sql): parsed = sqlparse.parse(sql)[0] tables = set() for token in parsed.flatten(): if isinstance(token, Identifier) and not token.has_alias(): tables.add(token.get_real_name()) elif isinstance(token, IdentifierList): for item in token.get_identifiers(): if not item.has_alias(): tables.add(item.get_real_name()) return tables

增量更新场景下血缘容易断在哪？

etl 流程中，如果每天只跑 INSERT INTO fact_sales SELECT ... FROM staging_sales WHERE dt = '2024-06-01'，血缘看起来是 staging_sales → fact_sales。但一旦 staging_sales 表结构变更（比如删了 amount_usd 字段），下游可能直到某天查报表才报错。更隐蔽的是分区表：代码里写死 FROM sales_202406，但实际调度器按日期模板生成分区名，血缘图里看到的表名和运行时根本对不上。

• 时间字段（dt, event_time）常被用作分区键，但不在 DDL 中体现为外键约束
• INSERT ... ON CONFLICT 的冲突目标列（如 ON CONFLICT (order_id)）隐含对索引的依赖，索引又依赖具体列
• 外部数据源（如 file_fdw 或 postgres_fdw）的远程表名在本地无对应 catalog 记录

真正难的不是画出一张图，而是让血缘信息能随 DDL 变更自动重算、且能关联到具体字段和调度实例。多数团队卡在把正则提取的结果和 airflow DAG 节点对不上这一环。