📚 课程目录第4章字段级血缘构建

4、字段级血缘构建：字段映射关系、表达式解析、UDF函数血缘追踪

字段级血缘，说白了就是搞清楚「这个字段从哪来、经过了什么运算、变成了什么」。

表级血缘只能告诉你 A 表依赖 B 表，但字段级血缘能精确到 A.col1 是从 B.col2 + C.col3 算出来的。我做过一个故障排查，上游改了字段精度，下游报表直接崩了。如果没有字段级血缘，你根本不知道谁依赖了那个字段。

这一章，我们就来拆解字段级血缘构建的三个核心环节：字段映射、表达式解析、UDF 追踪。

4.1 字段映射关系：从 SQL 中提取「谁等于谁」

字段映射是血缘分析的基础。你要能从 SELECT 语句里，把输出字段和输入字段一一对应起来。

4.1.1 直接映射

最简单的场景：

SELECT user_id AS uid FROM users;

输出字段 uid 直接等于输入字段 user_id。这种映射，解析 SQL 的 SELECT 列表和 FROM 子句就能拿到。

4.1.2 间接映射

稍微复杂一点：

SELECT a.order_id, b.user_name
FROM orders a
JOIN users b ON a.user_id = b.user_id;

这里 order_id 来自 orders 表，user_name 来自 users 表。你需要解析 JOIN 条件和表别名，才能确定每个字段的源表。

我的经验： 解析表别名时，我习惯先构建一个「别名 → 真实表名」的映射表。遇到 a.order_id 就去查这个映射，比每次都去扫描 FROM 子句快得多。

4.1.3 多级映射

更复杂的场景是嵌套查询或 CTE：

WITH base AS (
  SELECT user_id, amount FROM transactions
),
agg AS (
  SELECT user_id, SUM(amount) AS total FROM base GROUP BY user_id
)
SELECT user_id, total FROM agg;

最终输出的 total 字段，血缘要追溯到 transactions.amount，中间经过了 SUM 聚合。这种多级映射，需要递归解析 CTE 或子查询。

注意： 我曾经遇到过一个坑——CTE 里用了相同的字段名，但含义完全不同。比如 base 里的 amount 是原始金额，agg 里的 total 是汇总金额。如果只按字段名匹配，就会把血缘链搞错。一定要按「字段路径」来追踪，而不是字段名。

4.2 表达式解析：拆解运算逻辑

字段映射只是第一步。很多字段不是直接复制过来的，而是经过运算得到的。比如：

SELECT price * quantity AS total_amount FROM orders;

这里 total_amount 的血缘，不是简单地等于 price 或 quantity，而是两者的乘积。表达式解析就是要拆解这种运算关系。

4.2.1 表达式树

我通常把表达式解析成一棵树。拿上面的例子来说：

根节点：*（乘法运算）
左子节点：price（来自 orders 表）
右子节点：quantity（来自 orders 表）

这样，血缘关系就变成了：total_amount → price 和 quantity，且运算类型是乘法。

4.2.2 常见表达式类型

表达式类型	示例	血缘关系
算术运算	`a + b`, `a * b`	输出依赖所有输入字段，运算类型为 +、* 等
字符串拼接	`CONCAT(first_name, ' ', last_name)`	输出依赖 `first_name` 和 `last_name`
条件表达式	`CASE WHEN a > 0 THEN b ELSE c END`	输出依赖 `a`、`b`、`c`，且条件为 `a > 0`
聚合函数	`SUM(a)`, `COUNT(b)`	输出依赖 `a` 或 `b`，且聚合类型为 SUM、COUNT

关键点： 表达式解析不仅要记录「依赖了哪些字段」，还要记录「经过了什么运算」。这样在排查故障时，你才能知道是数据变了，还是运算逻辑变了。

4.2.3 嵌套表达式

实际生产中的 SQL 往往很复杂：

SELECT ROUND(price * (1 - discount), 2) AS final_price FROM orders;

这个表达式需要解析成多层：

最内层：1 - discount（减法）
中间层：price * (结果)（乘法）
最外层：ROUND(结果, 2)（函数调用）

每一层都要记录输入字段和运算类型。我习惯用递归下降解析器来处理这种嵌套结构，代码清晰，也容易扩展。

4.3 UDF 函数血缘追踪：处理黑盒逻辑

UDF（用户自定义函数）是血缘分析中最头疼的部分。因为 UDF 的代码逻辑对血缘分析工具来说是个黑盒。

4.3.1 UDF 的输入输出关系

即使不知道 UDF 内部怎么算的，我们至少能知道它的输入和输出：

SELECT my_udf(col1, col2) AS result FROM table;

这里 result 的血缘是：依赖 col1 和 col2，经过 my_udf 函数处理。这个信息已经很有用了。

4.3.2 UDF 元数据注册

我建议建立一个 UDF 元数据注册表，记录每个 UDF 的：

UDF 名称	输入参数	输出类型	副作用	确定性
`my_udf`	`col1: int, col2: string`	`string`	无	是
`random_id`	`seed: int`	`int`	无	否
`send_alert`	`msg: string`	`boolean`	发送告警	是

我的做法： 对于确定性 UDF（相同输入永远得到相同输出），我会在血缘图中标注为「纯函数」，可以放心做缓存和优化。对于有副作用的 UDF（比如发送告警、写日志），我会特别标注，避免在血缘回溯时误触发。

4.3.3 UDF 内部血缘（进阶）

如果 UDF 的源码你也能拿到，就可以做更细的追踪。比如一个 UDF 内部调用了其他函数或表：

-- UDF 内部逻辑
CREATE FUNCTION calculate_score(base_score, bonus) RETURNS int
BEGIN
  DECLARE final_score INT;
  SET final_score = base_score + bonus;
  RETURN final_score;
END;

这种情况下，你可以解析 UDF 的源码，构建内部的血缘关系：final_score → base_score + bonus。

注意： 解析 UDF 源码需要额外的语言解析器（比如 SQL、Python、Java）。我建议先做「外部血缘」（输入输出级别），等资源充足了再深入「内部血缘」。不要一开始就想做到完美，容易陷入泥潭。

4.4 字段级血缘构建的整体流程

把上面三个环节串起来，字段级血缘构建的整体流程是这样的：

这个流程看起来简单，但实际做起来有很多细节。我建议你从最简单的 SQL 开始，逐步增加复杂度。先搞定直接映射，再处理表达式，最后挑战 UDF。

4.5 实战：一个完整的字段级血缘示例

我们来看一个综合例子：

WITH raw AS (
  SELECT user_id, amount, discount FROM transactions
),
calc AS (
  SELECT 
    user_id,
    amount * (1 - discount) AS net_amount,
    my_udf(user_id, amount) AS risk_score
  FROM raw
)
SELECT 
  user_id,
  net_amount,
  risk_score
FROM calc
WHERE net_amount > 0;

这个 SQL 的字段级血缘关系如下：

输出字段	源字段	运算类型	中间步骤
`user_id`	`transactions.user_id`	直接映射	raw → calc → 最终输出
`net_amount`	`transactions.amount`, `transactions.discount`	乘法、减法	raw → calc（运算）→ 最终输出
`risk_score`	`transactions.user_id`, `transactions.amount`	UDF `my_udf`	raw → calc（UDF）→ 最终输出

排查场景： 假设 risk_score 突然异常。通过字段级血缘，你能立刻定位到：问题可能出在 my_udf 函数本身，或者它的输入字段 user_id 和 amount。你不需要去查 net_amount 或 discount，因为血缘图告诉你它们不相关。

4.6 避坑指南

字段名冲突： 不同表可能有相同字段名。我习惯用「表名.字段名」作为血缘图中的唯一标识，避免混淆。
通配符展开： SELECT * 需要展开成具体字段列表。我建议在解析阶段就把 * 替换成实际字段，不要留到运行时。
子查询别名： 子查询的别名可能和表名重复。我会在血缘图中给子查询加一个特殊前缀（比如 sub_），避免冲突。
UDF 版本管理： UDF 可能会更新。我建议在血缘图中记录 UDF 的版本号，这样回溯时能知道用的是哪个版本的逻辑。