面试官问'你们怎么做数据血缘'——改一张表你敢不敢直接改？

// 没有血缘追踪导致的事故
 
// 我改了：dwd_user_events.user_country → country_code
// 我知道的下游：dws_user_daily, dws_activation_daily
// 我不知道的下游：某分析师的临时报表SQL
 
// 问题本质：
// 1. 没有完整的表级血缘 → 不知道所有下游
// 2. 没有字段级血缘 → 不知道哪些下游用了这个字段
// 3. 临时SQL脱离管理 → 影子依赖无法追踪
 
// 教训：任何表结构变更前，必须先做影响分析
// 而影响分析的前提是有一套可查询的血缘数据

# 简化版的SQL血缘解析脚本
import re
import os
 
def extract_lineage(sql_text):
    # 提取INSERT目标表
    target = re.findall(
        r'INSERT\s+(?:INTO|OVERWRITE)\s+(?:TABLE\s+)?(\w+\.?\w+)',
        sql_text, re.IGNORECASE)
    # 提取FROM和JOIN的源表
    sources = re.findall(
        r'(?:FROM|JOIN)\s+(\w+\.?\w+)',
        sql_text, re.IGNORECASE)
    # 过滤掉子查询别名和临时表
    sources = [s for s in sources
              if not s.startswith('tmp_')]
    return {'target': target, 'sources': sources}
 
# 扫描所有ETL SQL文件，构建血缘表
# 输出格式：source_table, target_table, etl_script
# 存入一张MySQL表，供查询使用

有了这张血缘表，改任何表之前只需要查一下：

-- 查询某张表的所有下游依赖
SELECT target_table, etl_script
FROM data_lineage
WHERE source_table = 'dwd_user_events';
 
-- 查询某张表的所有上游来源
SELECT source_table, etl_script
FROM data_lineage
WHERE target_table = 'dws_user_daily';
 
-- 查询N层依赖（递归查询）
-- 改了ODS表，想知道最终影响哪些报表
WITH RECURSIVE downstream AS (
  SELECT target_table, 1 AS depth
  FROM data_lineage WHERE source_table = 'ods_user_events'
  UNION ALL
  SELECT l.target_table, d.depth + 1
  FROM data_lineage l JOIN downstream d
  ON l.source_table = d.target_table
  WHERE d.depth < 5  -- 最多追踪5层
)
SELECT DISTINCT target_table, depth FROM downstream;

这套方案虽然简单，但在某出海硬件品牌用了两年多，覆盖了100+个ETL作业的血缘关系，在EMR迁移时起到了关键作用——迁移前先查血缘确认影响范围，避免了很多遗漏。

变更管理：改表前必须做的三件事

有了血缘数据后，每次做表结构变更或ETL逻辑变更前，我要求团队必须做三件事：

// 变更前必做的三件事
 
// 1. 影响分析
// 查血缘表，列出所有直接和间接下游
// 确认每个下游是否会受影响
// 输出一份影响分析文档
 
// 2. 通知下游负责人
// 发消息给每个受影响表的负责人
// 说明变更内容、变更时间、是否需要配合修改
// 给对方至少3个工作日的准备时间
 
// 3. 灰度发布
// 先在测试环境跑一遍，确认下游不报错
// 上线后观察一天，确认数据正确
// 保留回滚方案（旧代码不删，用分支管理）

面试高频追问

追问一：你们有做字段级血缘吗？怎么实现？

诚实回答即可。'我们做到了表级血缘，字段级血缘没有完全实现。字段级血缘需要深度解析SQL的SELECT列表和表达式，实现难度比表级高很多——特别是遇到SELECT *、子查询别名、CTE引用时，解析逻辑非常复杂。如果要做字段级血缘，我会建议上专业工具——阿里云DataWorks有内置的字段级血缘，Databricks的Unity Catalog也支持。对于我们当时的团队规模（3-5人），表级血缘已经能覆盖90%的影响分析需求。'

追问二：临时查询（Ad-hoc SQL）怎么纳入血缘管理？

这是一个很实际的痛点。'临时查询是血缘管理的盲区——分析师直接连数仓跑SQL，这些SQL不在ETL管理系统中。我的做法是两层防护：第一，在数仓层面开启查询日志（Databricks的Query History、Hive的audit log），定期分析查询日志找出被频繁引用但不在血缘系统中的表，纳入管理。第二，建立规范——临时查询可以自由跑，但如果一个临时查询被做成了定时任务，必须在调度系统中注册并录入依赖关系。不注册的定时任务定期清理。'

追问三：血缘数据怎么保持更新？不会过期吗？

'关键是自动化而不是手动维护。我的解析脚本配成了定时任务，每天扫描一次代码仓库的ETL SQL文件，自动更新血缘表。代码仓库有变更就会触发血缘更新。如果用CI/CD流程，可以在每次SQL提交时自动触发血缘解析——这样血缘数据和代码始终保持同步。手动维护的血缘一定会过期，自动化解析的血缘才可靠。'

实战踩坑

除了前面提到的字段改名事故，我还遇到过一个更隐蔽的血缘问题。在某出海硬件品牌做存储成本优化时，我按'90天无查询'标准清理了一批表（第13篇讲过这个坑）。其中有一张dim_channel_mapping表，查询日志显示90天没人用过。

但实际上，这张表被一个季度汇总报表引用——这个报表每个季度才跑一次，恰好在我统计的90天窗口之外。我的血缘系统只覆盖了ETL管理中的SQL，而这个季度汇总报表是分析师在Jupyter Notebook里写的，不在ETL系统中。

// 血缘盲区导致误删表
 
// 血缘系统覆盖的：100+个ETL作业的SQL
// 血缘系统遗漏的：
// - 分析师在Notebook里写的SQL
// - BI工具直连查询的表
// - 季度/年度才跑一次的低频任务
 
// 改进措施：
// 1. 扩大血缘覆盖范围
//    解析Notebook中的SQL + BI工具的数据源配置
// 2. 清理表前增加'公示期'
//    标记为待清理 → 通知全团队 → 等待2周 → 无异议再清理
// 3. 低频使用≠无用
//    清理标准从'90天无查询'改为'180天无查询 + 无人认领'

教训：血缘系统的价值取决于覆盖范围。只覆盖ETL SQL的血缘是不完整的，分析师的Ad-hoc查询、BI工具的直连查询、低频定时任务——这些都是血缘盲区。扩大覆盖范围是血缘系统持续演进的方向。

总结

数据血缘解决的是'改了A表会影响谁'的问题。没有专业工具也能做——用SQL解析脚本自动构建表级血缘，配合变更管理三步法（影响分析→通知下游→灰度发布）。面试时讲你怎么用'土方法'解决了血缘问题，比说用了什么工具更有深度。记住：血缘的核心价值不是画一张好看的关系图，而是在每次变更前能快速做出准确的影响分析。

下一篇聊一个产品+技术交叉的话题：面试官问'你怎么设计指标体系'——从需求到指标的完整方法论

你们有做数据血缘吗？用的什么方案？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长