📚 课程目录第1章数据血缘基础概念

一、数据血缘基础概念

各位同学好，我是老张。做数据治理这些年，我见过太多因为数据出问题而彻夜排查的团队。说实话，很多人对数据血缘的理解还停留在「知道有这么个东西」的层面。今天这一章，咱们就把数据血缘的底裤扒干净，看看它到底是什么、能干什么。

数据血缘，说白了就是数据的「族谱」。它记录了数据从产生、经过哪些加工、最终流向哪里的完整路径。我习惯把它比作一个数据家族的族谱——你不仅能知道某个数据字段的「父母」是谁，还能看到它被哪些「亲戚」引用过。

数据血缘的核心定义：描述数据在产生、处理、流转到消亡全过程中，数据与数据之间、数据与系统之间、数据与业务之间的关联关系。

举个例子。你看到报表里的「昨日销售额」是 100 万。这个数字怎么来的？数据血缘会告诉你：它来自订单表 → 经过 ETL 清洗 → 汇总到日销售宽表 → 最后被报表系统读取。每一步都有记录，每个环节都清晰可见。

我在项目中遇到过最典型的场景：业务方说「这个月收入数据不对」，如果没有血缘关系，你得从报表一路查到源系统，挨个表翻、挨个脚本看，运气好半天能定位，运气不好一周都搞不定。但有了血缘，5 分钟就能锁定问题出在哪个环节。

很多新人会把数据血缘和数据地图搞混。我刚开始做数据治理时也犯过这个错。这里我给大家做个对比，你就明白了。

你想想看，数据地图就像一张城市地图，告诉你哪里有医院、哪里有学校。而数据血缘更像是导航轨迹，记录你从 A 点到 B 点具体走了哪条路、经过了哪些路口。两者互补，但用途完全不同。

我的建议：在数据治理项目中，先建数据地图做资产盘点，再建数据血缘做链路追踪。顺序别搞反了，否则你会发现自己连要追踪的数据在哪里都不知道。

数据血缘有三个核心要素，缺一不可。我习惯用「输入-处理-输出」这个经典模型来理解它。

来源就是数据的「出生地」。它可以是业务数据库、日志文件、外部接口、消息队列等等。在血缘分析中，我们不仅要记录来源是什么，还要记录来源的元数据信息——比如表结构、字段类型、数据量级。

我曾经踩过一个坑：某个数据源的字段类型从 varchar 改成了 int，但血缘系统没有及时更新，导致下游 ETL 脚本解析失败，整个数仓链路断了 3 个小时。嗯，从那以后我要求所有血缘系统必须实时同步源端元数据变更。

转换是血缘中最复杂的部分。它描述了数据从来源到去向之间经历了哪些加工逻辑。包括但不限于：

注意：转换逻辑是数据血缘中最容易丢失的部分。很多团队只记录了「表 A → 表 B」，但中间怎么转换的完全黑盒。这样的血缘只能叫「半成品血缘」，做影响分析时基本没用。

去向是数据的「终点站」。它可能是报表、数据产品、机器学习模型、下游系统，甚至是归档存储。在影响分析中，去向信息至关重要——当你修改某个数据源时，必须知道哪些下游会受到影响。

我记得有一次，业务方要求修改订单金额的计算逻辑。如果没有血缘的去向信息，你可能觉得「改就改了呗」。但实际一查，这个字段被 17 个报表、3 个数据产品和 2 个风控模型引用。改动一个字段，影响面覆盖了半个公司。这就是血缘的价值——让你在做决策前就知道代价。

下面这张图展示了数据血缘的完整结构。我建议你把它保存下来，后面讲影响分析时会反复用到这些概念。

在实际项目中，血缘的粒度决定了它能解决什么问题。我一般把血缘分为三个层级：

系统级血缘：记录数据在系统间的流转。比如「MySQL → Kafka → Hive → Tableau」。这个粒度适合做整体架构梳理。
表级血缘：记录表与表之间的依赖关系。比如「ods_order → dwd_order_detail → dws_daily_sales」。这个粒度是大多数数据治理项目的标配。
字段级血缘：记录字段与字段之间的映射关系。比如「ods_order.amount * 0.9 → dwd_order_detail.net_amount」。这个粒度最精细，做影响分析时最有用，但建设成本也最高。

我的经验：不要一上来就追求字段级血缘。先跑通表级血缘，让团队看到效果、建立信心，再逐步细化到字段级。否则很容易陷入「建了半年还没上线」的尴尬局面。

数据血缘不是什么高深莫测的概念，它就是数据的「来龙去脉」。记住三个核心要素：来源、转换、去向。再记住一个原则：血缘的价值不在于「记录」，而在于「分析」。后面几章我们会深入讲怎么用血缘做影响分析、怎么在数据修复中落地。