数据治理中的数据血缘追踪别做成飘在半空的看板

上周在软件大道堵了四十分钟，下车直奔一家做制造类数字化的客户会议室，刚坐下对方数据团队的负责人就把电脑转过来——满屏五颜六色的节点连线，说是花了大价钱上的血缘系统。

这系统看着真热闹。

真出问题的时候，它一点用没有。

上次财务对账发现应付账款模块的数字对不上，团队找了三个人翻了两天的日志，才发现是三个月前某张临时同步的表把核心字段覆盖了。那个所谓的血缘系统，根本没把临时脚本、手动导出的Excel算进去。

说白了，你画的图，是你“愿意承认”的链路，不是真实跑在系统里的链路。

先把最容易踩的坑说在前头

很多厂商在卖方案的时候会给你看一张从源头业务库到最终BI报表的全链路示意图，节点颜色分的清清楚楚，哪层是ODS哪层是DW哪层是ADS，看着特别规整。但没人会告诉你，企业里跑了快十年的旧系统里，有三成以上的取数逻辑根本没在数仓的统一调度平台上。

要么是老员工写的存在本地电脑里的Python脚本，要么是业务部门每周手动从系统导出来丢给数据团队的Excel，这些东西，不在你的血缘采集范围内，那你画的全链路图，本质上就是个半拉子工程。

别信厂商的PPT。那些把血缘系统吹的能覆盖企业所有数据流转环节的方案，你只要问他一句，能不能把业务部门存在共享文件夹里的、每周手动更新的Excel的取数链路也自动采集到，多半对方就开始含糊其辞。

很多团队刚启动数据治理中的数据血缘追踪工作时，总想着要一步到位把所有链路都采全，光对接采集端就耗了小半年，最后发现系统上线了，没人愿意天天维护那些零散的手动操作记录，最后就成了个给领导演示用的摆设。

真正有用的血缘，得能扛住临时变更的冲击

之前对接过一个零售行业的团队，做的血缘系统是基于调度平台的元数据自动采集的，平时看着挺顺。去年大促前一周，运营团队临时加了个活动取数需求，数据开发为了赶进度，没走正规的上线流程，直接在生产库上改了个视图的字段映射。

结果大促当天的转化率报表比实际值高了三个百分点，运营拿着这个数据给老板报喜，差点把全年的营销预算都砸进去。

找原因的时候，那个基于调度平台的血缘系统，根本没捕捉到这个手动改的视图变更——因为这操作根本没进调度日志。

你说气人不气人。

很多团队一开始做血缘的时候，总想着要把所有链路都做的100%完整，恨不得连员工手动改个字段值的操作都记下来，结果搞了大半年，光采集端的对接就把团队拖垮了。我见过最离谱的，是为了补全血缘链路，专门招了两个实习生，每天对着几百个Excel文件手动录字段映射，录了三个月，人离职了，之前录的东西没人接，系统直接躺平。

麻烦在于，企业里的临时变更从来不会跟着你的流程走。你不能要求所有取数需求都严格走开发、测试、上线的全流程，尤其是业务节奏快的时候，临时插的需求太多了，你的血缘系统如果跟不上这些临时变更的记录，那它的可信度会越来越低，最后没人愿意用。

别把血缘的价值想的太满

很多厂商吹的，血缘能帮你做根因分析，能帮你算数据资产价值，能帮你做合规审计，听着都对，但你得结合自己的实际情况来。

如果你团队一共就三个数据开发，数仓里的表加起来不到两百张，那你根本不需要上那种几十万的商业血缘系统，写个简单的脚本，把调度平台里的任务依赖、表字段映射关系爬下来，存在元数据库里，足够用了。

这事没那么玄。

很多人在做数据治理的时候，总把血缘当成整个治理体系里的核心部分，要花一半以上的预算在这上面，结果钱花了，团队的核心数据质量问题还是没解决——比如数仓里的核心指标定义不统一，同一个“销售额”，财务算的、运营算的、销售算的差了快10%，这种问题，你就算把血缘链路画到字段级，也解决不了根本问题。

上次在软件大道跟那个客户的技术负责人吃饭，他说现在想通了，之前花大价钱做的全链路看板，现在也就给客户参观的时候打开看看，平时团队真要排查问题，还是先翻最近的变更记录，再顺着数仓的表找依赖，反而比看那个没收录临时脚本的血缘系统快。

现在很多开源的血缘采集工具，能自动识别SQL解析里的字段映射，甚至能把脚本里的临时表依赖也抓下来，不用手动录。但就算有工具，你也得定期去核对采集的链路是不是和实际跑的一致——比如三个月前改的个任务，工具是不是没识别到？别等出问题了才发现。

血缘这东西，不是一劳永逸的。你每次上线新的取数任务、每次调整字段映射、甚至每次手动跑个临时脚本，都得把对应的链路更新到你的血缘系统里，不然时间长了，你的系统里存的链路就和真实跑的东西差的越来越远，最后就成了个没人信的摆设。

别上来就追求完美。你如果连最核心的那二十张支撑日常经营报表的表的链路都没摸清楚，就算你把边缘业务的那些没人用的临时表的血缘都采全了，对实际工作也没半点帮助。