3. 元数据管理：元数据分类、仓库建设与采集策略

元数据管理，说白了就是给数据做「档案」。没有档案，你根本不知道数据从哪来、长什么样、谁在用。影响分析也就无从谈起。

我见过太多团队，一上来就搞数据血缘、搞影响分析，结果连字段含义都说不清楚。为什么？元数据没管好。今天咱们就把这块掰开揉碎讲清楚。

3.1 元数据分类：技术、业务与管理

元数据不是铁板一块。我个人习惯把它分成三类：技术元数据、业务元数据和管理元数据。这三者各有侧重，缺一不可。

分类	核心内容	典型示例	谁在用
技术元数据	数据结构、存储、ETL 规则	表结构、字段类型、主外键、分区键、数据源连接信息	数据工程师、DBA
业务元数据	业务含义、指标定义、数据质量规则	「客户活跃度」的计算口径、字段的业务描述、枚举值含义	数据分析师、业务方
管理元数据	数据生命周期、权限、审计	数据责任人、创建时间、访问记录、数据分级	数据治理团队、安全审计

我在项目中遇到过一种情况：技术元数据采集得特别全，但业务元数据几乎空白。结果影响分析跑出来一堆「受影响对象」，业务方却说「这个字段我们早就不用了」。你想想看，这分析还有什么意义？

3.2 元数据仓库建设：从分散到集中

元数据仓库，就是把散落在各个系统里的元数据统一收拢、存储、管理的地方。它不是简单的数据拷贝，而是要做整合、去重、版本化。

我建议按这个步骤来建：

1. 确定元数据模型：定义核心实体（表、字段、ETL 任务、报表）及其关系。这是地基。
2. 选择存储引擎：关系型数据库（如 MySQL）适合结构化元数据；图数据库（如 Neo4j）适合血缘关系查询；混合架构更常见。
3. 建立版本机制：每次元数据变更都要保留快照。影响分析需要回溯历史版本。
4. 开放查询接口：提供 REST API 或 GraphQL，让下游系统（影响分析引擎、数据目录）能实时拉取。

下面这张图展示了元数据仓库的核心架构：

3.3 元数据采集策略：增量、全量与事件驱动

元数据采集不是一次性工作。数据在变，元数据也得跟着变。我总结下来，有三种主流策略：

3.3.1 全量采集

定期把目标系统的元数据全部拉一遍。简单粗暴，但成本高。适合数据量小、变更不频繁的场景（比如每月一次的元数据基线快照）。

3.3.2 增量采集

只采集上次采集之后发生变化的部分。需要目标系统提供变更时间戳或版本号。效率高，但实现复杂。我建议优先用这种方式。

3.3.3 事件驱动采集

当元数据发生变更时（比如表结构修改、ETL 任务更新），由源系统主动推送变更事件。实时性最好，但对源系统有侵入性。

下面这张表帮你快速对比三种策略：

策略	实时性	实现成本	适用场景
全量采集	低（T+1）	低	元数据稳定、数据量小
增量采集	中（分钟级）	中	大多数生产环境
事件驱动	高（秒级）	高	高频变更、实时影响分析

3.4 元数据质量：采回来只是第一步

元数据采回来，不代表就能直接用。我见过太多「脏元数据」——字段名对不上、血缘关系断链、业务描述为空。这些问题不解决，影响分析就是空中楼阁。

我建议建立元数据质量检核规则：

• 完整性检查：关键字段（表名、字段名、数据类型）不能为空。
• 一致性检查：同一字段在不同系统中的名称、类型必须一致。
• 时效性检查：元数据更新时间不能超过设定的阈值（比如 24 小时）。
• 血缘连通性检查：每条血缘链路必须从源端到目标端完整可达。