📚 课程目录第4章血缘关系的粒度

4、血缘关系的粒度：字段级、表级、任务级、系统级

聊血缘关系，有个问题绕不开——你查的「血缘」到底查到多细？

我见过不少团队，一上来就搞字段级血缘，结果搞了三个月还没跑通。也见过一些团队，只盯着系统级血缘看，出了问题连哪个表被改了都找不到。说白了，血缘的粒度决定了你能用它干什么，也决定了你要付出多少成本。

这一节，我把四种粒度掰开揉碎讲清楚。你想想看，搞懂了这些，以后选工具、定方案、排查故障，心里就有谱了。

字段级血缘，就是追踪数据从源头到目标的每一个字段。比如一张报表里的「订单金额」，它到底是从哪个数据库的哪个表的哪个字段算出来的？中间经过了哪些函数、哪些转换？

这是最细的粒度，也是最有价值的粒度。

核心价值：精准定位数据质量问题。某个字段值不对，顺着血缘链路，一眼就能看到是上游哪个字段出了问题。

我在项目中遇到过一件事。某天凌晨，业务方反馈说「昨日销售额」突然翻了三倍。我们查了半小时没头绪。后来我让团队拉出字段级血缘图，发现「销售额」字段的上游有一个「含税金额」字段，前一天刚被改了计算逻辑——把不含税改成了含税。顺着字段级血缘，5分钟定位问题。

但字段级血缘也有代价：

我的建议：核心业务表、财务相关表、监管报表，必须上字段级血缘。日志类、中间表、临时表，用表级就够了。

表级血缘，只追踪表与表之间的依赖关系。A表→B表→C表，谁生谁，谁依赖谁，一目了然。

这是实际工作中用得最多的粒度。为什么？因为大部分故障排查，到表级就够了。

举个例子：某天凌晨跑批任务报错，说「目标表T_DAILY_SALES数据为空」。你查表级血缘，发现它的上游是T_ORDER_DETAIL和T_PRODUCT_INFO。再查一下，T_ORDER_DETAIL昨天确实没更新——好了，问题找到了。你不需要知道具体是哪个字段导致的，知道是哪张表就够了。

我个人习惯是：先上表级血缘，跑通之后再按需补充字段级。别一上来就想搞大而全，容易把自己搞死。

任务级血缘，追踪的是「哪个任务产生了这张表」「哪个任务消费了这张表」。它把表之间的依赖关系，映射到了任务之间的依赖关系。

为什么要单独拎出来说？因为在实际排查中，你经常遇到这种情况：

任务级血缘，就是帮你找到那个「中间人」。

注意：任务级血缘和表级血缘是互补的，不是替代关系。表级血缘告诉你「谁依赖谁」，任务级血缘告诉你「谁在干活」。两个结合起来，才能完整还原数据流转的全貌。

我曾经排查过一个经典案例：某张报表连续三天数据对不上。表级血缘显示上游是两张事实表，数据都没问题。但任务级血缘一查，发现中间有一个「数据清洗任务」，它的代码里写死了某个过滤条件——而这个条件恰好三天前被业务方改了。任务级血缘直接定位到了那个任务，省去了逐行翻代码的功夫。

系统级血缘，是最粗的粒度。它不关心具体字段、具体表、具体任务，只关心「系统A→系统B→系统C」这样的流转关系。

比如：

系统级血缘的价值在于：快速定位故障边界。

举个例子：某天报表系统数据延迟了2小时。你不需要去查具体哪个表、哪个任务，先看系统级血缘：

5分钟定位到系统层面，剩下的交给对应系统的负责人去排查细节。

我的经验：系统级血缘是故障排查的「第一道防线」。出了问题，先看系统级，缩小范围；再看表级/任务级，定位具体对象；最后看字段级，确认根因。这个顺序，能帮你节省至少一半的排查时间。

下面这张图，展示了四种粒度之间的关系。你可以把它理解成一个「层层下钻」的过程：

说了这么多，到底怎么选？我根据实际经验，给一个参考：

一个小技巧：如果你刚开始做血缘治理，别贪多。先上表级血缘，跑通一个链路。等团队熟悉了，再逐步扩展到字段级。我见过太多团队，一上来就想搞全字段级，结果半年过去了，连一条完整的血缘链路都没跑通。

嗯，四种粒度就讲到这里。记住一个原则：粒度越细，价值越大，成本也越高。选哪种，看你的场景，别盲目追求「最细」。