数据血缘
总结
| 记忆点 | 内容 |
|---|---|
| 血缘本质 | 数据从哪来、到哪去的依赖链路 |
| 三大场景 | 影响分析、问题溯源、治理抓手 |
| 采集方式 | SQL解析为主 + 调度平台补充 |
| 存储模型 | 一张关系表：上游→下游+任务名 |
| 落地建议 | 小团队不用上重量级工具，一张表+可视化就够 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
进阶 | 大数据面试 · 数仓建模系列
| 面试真题 你们有没有建数据血缘？血缘在日常工作中是怎么用的？ |
|---|
血缘解决什么问题？
数仓越建越大，表越来越多。三个灵魂拷问：这张表的数据从哪来的？（上游依赖）改了这张表会影响谁？（下游影响）报表数据异常到底是哪一层出了问题？（问题溯源）
没有血缘，这三个问题只能靠人工翻SQL、问同事、猜。有血缘，秒级定位。
| Wood的实战经验 我做埋点治理时，要下线一批旧事件。没有血缘的话根本不敢删——谁知道哪张报表还在用？有了血缘之后，查一下下游依赖链，确认没人用才敢下线。两周清理了200多个废弃事件，释放了大量计算资源。 血缘不只是一个「好看的功能」，它是数仓治理的基础设施。没有血缘，DAY 14的生命周期管理、DAY 16的中间表治理、DAY 18的问题溯源全都没法高效做。 |
|---|
血缘的三大应用场景
场景一：影响分析（改之前先查）
场景：dim_user表要加一个字段需要重跑。问题：重跑会影响哪些下游？血缘查询一下就知道：dim_user → dwd_order_detail → dws_trade_user_1d → ads_daily_report，影响2条链路、5张表、1个报表、1个API。不查血缘直接改，下游可能静默出错几天才被发现。
场景二：问题溯源（出了问题往上追）
场景：ads_daily_report的GMV突然翻倍。血缘溯源路径：ads ← dws ← dwd ← ods。逐层对数：ods行数正常，dwd行数翻倍——问题在DWD层！原因：JOIN dim_user时拉链表没加过滤。有血缘的话，几分钟就能定位到问题层，没有血缘可能要排查半天。
场景三：治理抓手（谁建的？还有用吗？）
血缘 + 查询日志 = 表活跃度画像。有上游无下游→末端表，确认是否为废弃表；有下游无产出→上游任务可能已停，下游在用旧数据（很危险！）；无上游无下游→孤岛表，大概率可以下线。
血缘怎么建？
采集方式主要有三种：
SQL解析（最常用）：解析INSERT/SELECT语句提取表关系。覆盖面广，但需要处理动态SQL。
调度平台：从Airflow/DataWorks任务依赖中提取。简单可靠，但只有任务级粒度。
HDFS审计日志：从文件访问记录推断依赖。最底层但噪音大。
实际项目中通常组合使用：SQL解析为主 + 调度平台补充。
存储模型很简单，一张关系表就够：
| CREATE TABLE meta_lineage ( source_table STRING, -- 上游表 target_table STRING, -- 下游表 source_fields STRING, -- 上游字段（可选，字段级血缘） target_fields STRING, -- 下游字段 job_name STRING, -- ETL任务名 update_time TIMESTAMP ) |
|---|
| Wood的实战经验 小团队不需要上Atlas/DataHub这种重量级方案。我们3个人的团队，用SQL解析+一张血缘关系表+一个简单的可视化页面就够用了。核心是能回答前面说的三个灵魂拷问。先解决有没有的问题，再考虑好不好的问题。 如果你们用DataWorks，它内置了血缘功能，直接开启就行，不用自己建。这是平台选型时一个很重要的考虑因素。 |
|---|
| 面试加分提示 面试不会问你用了什么工具，会问你血缘解决了什么问题： 「我们建了表级血缘，主要通过SQL解析ETL脚本来采集上下游关系。三个核心应用：第一，表变更前查影响分析，避免盲改导致下游出错；第二，数据异常时沿着血缘快速溯源，定位到具体哪层出问题；第三，结合查询日志做表活跃度分析，识别废弃表。我做埋点治理时就靠血缘确认了200多个事件没有下游依赖才敢下线。」 关键：说出具体场景和血缘帮你解决了什么问题，比说用了什么工具有价值100倍。 |
|---|