考察点
血缘是数据治理的基础设施，这道题考的是你是否理解血缘「从哪来、准不准、用在哪」。面试官想听到血缘的采集手段（SQL 解析、调度依赖、埋点）各自的覆盖面和坑，以及影响分析在变更、故障、下线三个场景的实际用法。追问常落在字段级血缘的难点和血缘不准怎么办。
参考答案
血缘数据从哪来
主流是三条路，互补使用：
SQL 解析是主力。把调度系统里所有任务的 SQL（Hive、Spark、Flink）用解析器（Apache Calcite、Druid、Antlr 自研）解析成 AST，提取 insert 的目标表和 from/join 的源表，得到表级血缘；再追踪 select 列表里每个字段的表达式来源，得到字段级血缘。覆盖最全，但解析器要兼容公司实际用的各种 SQL 方言和 UDF，工作量不小。
调度依赖是兜底。调度系统里配的任务上下游关系天然蕴含表级血缘，解析不了的任务（Shell 脚本里拼 SQL、读写走代码的 Spark 任务）靠它补上，粒度粗但不会漏。
运行时埋点是补充。在引擎侧 hook（如 Spark 的 Listener、Flink 的 Lineage 接口）上报真实读写关系，能抓到动态分区、临时表这类静态解析难看全的情况。
三条路的结果合并去重，入库（图数据库 Neo4j 或关系库自研存边表），对上提供查询 API 和数据地图展示。
字段级血缘难在哪
表级血缘基本成熟，字段级才是真功夫。难点在于：聚合之后血缘是「多对一且不可逆」——sum(amount) 来自 amount 列没错，但语义上已经变了；case when、UDF 让字段来源变成条件依赖，一个输出列可能依赖输入的多个列（判断条件列 + 取值列），保守做法是把这些依赖全部记录，宁多勿漏；select * 和未指定列名的 insert 要结合 schema 快照推断，schema 演进后历史血缘就对不上了。生产上对核心资产（钱相关链路）做字段级，其余表级够用，别追求全量字段级，投入产出不成比例。
血缘用在哪：四个场景
影响分析是最核心的用途。改一张 DWS 表的口径前，顺着下游血缘拉出所有受影响的表、任务、报表和负责人，评估改动半径，挨个通知。没有血缘时，改口径靠群里吼，必然漏，漏了就是事故。
问题定位。下游报表数字不对，顺着上游血缘逐层对比各层数据，定位是哪一层开始出错的，比拍脑袋逐张查快一个量级。结合 DQC 告警效果更好——血缘告诉你这次 DQC 熔断影响了哪些下游。
口径溯源。业务方问「这个 GMV 是怎么算的」，从报表字段一路回溯到 ODS 源表，每一层的加工逻辑串起来就是口径说明，这也是指标文档自动化的基础。
下线评估与成本治理。一张表想下线，看血缘确认无下游（或者下游已迁移）；找「无人消费的表」做存储治理，血缘的出度为零就是最直接的判据。
血缘不准怎么办
血缘不可能 100% 准，工程上的态度是标注置信度：SQL 静态解析的标高置信，调度依赖推断的标中置信，允许用户在数据地图上报错纠错。重要变更的影响分析别只信血缘，再配合查询日志（最近 90 天谁扫过这张表）兜底——有些临时查询不经过调度，血缘抓不到但查询引擎的审计日志里有。
可能的追问
- 临时表和中间结果会不会污染血缘？ 会，要过滤：按命名规范识别临时表（tmp_、temp_），或按生命周期识别（从未被其他任务消费的中间产物），展示时折叠，存储时保留以便排查。
- 跨系统的血缘怎么办，比如 Hive 到 ClickHouse？ 靠数据集成任务（DataX、SeaTunnel 配置）解析源端和目标端，把同步任务也建成血缘边；Flink 实时链路同理，从 Flink SQL 或作业配置里提取 source/sink。
- 血缘数据量级多大，怎么存？ 中型数仓几千张表、几万个任务，表级边几十万条，关系库完全够；做字段级且要支持多层递归查询时，图数据库（Neo4j、NebulaGraph）查询体验更好，但要接受多维护一个组件的成本。