数据目录的构建基石：元数据采集、元数据分类、元数据血缘、元数据版本管理

数据目录不是凭空搭起来的。它背后有四个核心支柱——元数据采集、分类、血缘和版本管理。说白了，没有这四样东西，数据目录就是个空壳子。

我刚开始做数据治理那会儿，以为建个目录就是把表名和字段列出来。后来被业务部门追着问「这个字段到底从哪来的」「昨天的数据口径怎么跟今天不一样」……嗯，从那以后我才真正重视起这四块基石。

元数据采集：目录的「眼睛」

元数据采集是第一步。没有采集，目录里啥也没有。我个人习惯把采集分成三类：

我在项目中遇到过最头疼的事：采集器把字段类型全采回来了，但业务含义是空的。业务方看着「col_001」「col_002」一脸懵。所以我的建议是——技术元数据自动采，业务元数据必须有人认领。

元数据分类：让数据「找得到」

数据采回来了，堆在一起就是垃圾场。分类，就是给数据打标签、分门别类。

我常用的分类维度有四个：

• 主题域分类：按业务领域分，比如「用户域」「订单域」「支付域」
• 数据层级分类：ODS（贴源层）、DWD（明细层）、DWS（汇总层）、ADS（应用层）
• 敏感度分类：公开、内部、敏感、绝密
• 生命周期分类：热数据、温数据、冷数据

你想想看，一个分析师想找「最近 30 天的新增用户数」，如果目录里没有主题域和层级标签，他得翻几百张表。有了分类，直接定位到「用户域 → DWS 层 → 用户汇总表」，效率翻倍。

元数据血缘：数据「从哪来、到哪去」

血缘，是数据目录里最有技术含量的部分。它记录了数据从源头到目标的完整链路。

我曾经被业务方质问：「这个报表的 GMV 为什么跟财务对不上？」我花了三天手工追链路，最后发现是 ETL 脚本里有个字段映射错了。如果有血缘关系图，十分钟就能定位问题。

血缘采集通常分两种方式：

• 解析式采集：解析 SQL 脚本、存储过程，自动提取输入表和输出表的关系
• 运行时采集：在 ETL 执行时埋点，记录实际的数据流向

解析式采集快，但遇到动态 SQL 容易漏。运行时采集准，但性能有损耗。我建议两者结合——解析式做全量扫描，运行时做增量校验。

下面这张图展示了典型的血缘链路：

元数据版本管理：数据「变了什么」

数据是会变的。字段新增、类型修改、口径调整……如果没有版本管理，你根本不知道当前的数据定义是什么时候变的、谁变的。

版本管理要管三件事：

1. Schema 版本：表结构的变化历史，比如新增字段、删除字段、修改类型
2. 血缘版本：ETL 链路的变更记录，比如某个表的上游从 A 换成了 B
3. 业务口径版本：指标定义的变化，比如「活跃用户」从「7 天内登录」改成了「30 天内登录」

我建议用 Git 式的版本管理——每次变更生成一个快照，记录变更人、变更时间、变更原因。这样业务方问「这个指标为什么跟上个月不一样」，你可以直接翻出版本对比。

四块基石的关系

这四块基石不是孤立的。采集是基础，分类是组织，血缘是追溯，版本是管控。少了任何一个，数据目录都不完整。

我见过一些团队，采集做得很好，分类也做了，但血缘和版本管理没跟上。结果数据目录变成了「数据字典」——只能查，不能追。业务方用了几次就放弃了。

反过来，如果四块都做扎实了，数据目录才能真正帮团队实现自助取数。分析师自己查血缘、看版本、找分类，不用每次都来找 DBA 问「这个表能不能用」。

嗯，这就是数据目录的四个基石。下一块我们聊聊怎么把这些基石落地成工程实践。