上周跟一个做零售的数仓负责人喝咖啡，他差点把手里的美式喷出来。
花了小两百万上的血缘系统，上线三个月，除了给集团做数字化汇报的时候点开截个图，平时没人碰。上月算季度GMV的时候差了12万，整个团队翻了三小时的血缘看板，愣是没找到问题出在哪——最后还是做了五年数仓的老员工凭记忆，想起前一周临时跑了个渠道数据修正脚本，才把窟窿填上。
大部分人对血缘的认知从根上就偏了
很多厂商给客户演示血缘，一上来就是满屏的彩色连线，节点大小不一，链路从底层数据库一直串到前端报表，看着特别震撼。
可你真用的时候就会发现，这些线全是死的。
说白了，大部分早期的血缘工具，都是靠静态扫描调度系统里的SQL脚本生成的。固定跑的天级任务、小时级任务，确实能扫到。可那些分析师临时跑的修正脚本、业务部门自己导的Excel数据、甚至是直接在生产库改的测试数据，这些链路根本抓不到。
数据血缘追踪的核心，从来不是把链路画得多炫酷，而是能精准回答两个问题：当前你看到的这个数，到底是从哪几个表的哪几个字段算出来的；如果我要改这个字段的逻辑，会影响到下游哪些报表、哪些业务接口、甚至哪些正在跑的生产任务。
刚才那个零售的朋友遇到的问题，就是典型的链路缺失。他上的那个系统，连临时任务的入口都没对接，等于血缘图从一开始就缺了一大块，真出问题的时候，当然没人敢信。
没用。真的没用。
粒度错了，投入再多都是白搭
很多公司做血缘，一开始想省成本，先做表级的。就是A表关联到B表，B表关联到C表，画个粗线条的链路就行。
觉得反正以后业务涨起来了，再补字段级的也来得及。
可真到要补的时候才发现，早就晚了。
什么叫表级血缘？就是你知道用户表和订单表有关系，但你不知道用户表的“注册渠道”字段，被订单表的哪个计算逻辑用了，更不知道下游的新客占比报表、渠道ROI接口，是不是都在调用这个字段。
上次跟一个做金融科技的朋友聊，他们之前图省事做了半年表级血缘，后来要调整“风险等级”字段的计算规则，挨个给下游的开发打电话问，一共找了27个相关的人，开了三次会才把影响范围摸清楚。就这，上线之后还是漏了一个给风控部门供数的接口，导致当天的风险预警数据错了，差点出合规问题。
麻烦就在这。你当初省的那点事，最后全变成还不完的债。
字段级血缘的成本确实高。要把每一段SQL里的字段映射、计算逻辑拆解开，还要实时同步每天新增的任务逻辑，不是扫一遍脚本就能搞定的。但如果一开始就只做表级的，等系统跑了一年，积累了几百张没人敢动的老表，几千个逻辑模糊的字段，你再想往细了拆，成本比一开始就做字段级高至少三倍。
还有个容易被忽略的点，就是血缘的更新机制。很多公司的血缘图是三个月跑一次静态扫描生成的，做完就扔在那，过半年再看，里面的链路早就和实际跑的任务对不上了。没人敢用的血缘，和没有血缘有什么区别？
别追大而全，先啃最痛的那一块
我见过太多公司做数据治理，一上来就要做全域血缘，从业务库到数仓到报表到业务应用，恨不得把所有系统的所有字段全串起来，做个全集团统一的资产地图。
做了一年，项目还没上线，业务部门早就没耐心了。
真的，别信厂商给你画的饼。什么全域打通、全链路追溯，听着好听，真落地的时候，你连自己内部二十多个业务系统的接口都摸不清，谈什么全域？
不如先找最痛的那个场景切入。比如刚才那个零售的朋友，最痛的就是核心经营指标出问题的时候找根因太慢，那一开始就不用管别的，先把GMV、复购率、客单价这三个核心指标的全链路血缘做透——从业务端的下单数据落库，到数仓的清洗、聚合，到最后给老板看的经营报表，每一个字段的计算逻辑、每一个环节的负责人都标清楚。
真出问题的时候，顺着链路找，半小时就能定位到是哪个环节出了错，比花几百万做个全量的空架子有用多了。