📚 课程目录第4章元数据管理

4. 元数据管理：元数据定义、元数据采集、元数据血缘分析

聊到数据质量，很多人第一反应是写规则、跑校验、出报告。但做了几年数据治理后，我越来越觉得——元数据才是数据质量的“地基”。没有清晰的元数据，你连数据从哪来、到哪去、长什么样都说不清楚，质量监控就是空中楼阁。

这一章，咱们就扎进元数据管理的三个核心动作：定义、采集、血缘分析。我会结合自己踩过的坑，把每个环节的关键点掰开揉碎讲清楚。

4.1 元数据定义：先统一语言，再谈治理

元数据定义，说白了就是给数据“上户口”。你想想看，如果业务部门管“客户ID”叫cust_id，技术部门叫customer_identifier，数据仓库里又存成c_id——那质量规则到底该对哪个字段生效？

我个人习惯把元数据定义分成三层：

层级	定义	典型内容
业务元数据	业务视角的数据含义	字段中文名、业务定义、计算口径、负责人
技术元数据	技术视角的数据结构	字段类型、长度、主键、索引、存储位置
管理元数据	数据生命周期管理信息	创建时间、更新时间、数据来源、访问权限

我的经验： 定义阶段最容易犯的错是“过度设计”。我曾经在一个项目里，花了两周把每个字段的枚举值都列进元数据——结果业务一变，维护成本直接爆炸。建议先定义核心字段（主键、业务关键字段、常用维度），其他字段随用随补。

定义完成后，一定要落地成元数据模型。我常用的是这样的结构：

-- 元数据核心表设计（简化版）
CREATE TABLE metadata_field_def (
    field_id        VARCHAR(64) PRIMARY KEY,      -- 字段唯一标识
    field_name      VARCHAR(128) NOT NULL,        -- 字段英文名
    field_alias     VARCHAR(256),                 -- 字段中文名
    data_type       VARCHAR(32),                  -- 数据类型
    biz_definition  TEXT,                         -- 业务定义
    source_system   VARCHAR(64),                  -- 来源系统
    owner           VARCHAR(64),                  -- 负责人
    created_at      TIMESTAMP DEFAULT NOW(),
    updated_at      TIMESTAMP DEFAULT NOW()
);

嗯，这里要注意：field_id 一定要全局唯一，别用自增ID。我见过太多因为系统合并导致ID冲突的惨案。

4.2 元数据采集：自动化是底线，手动是灾难

定义好了元数据，接下来就是采集。说白了，就是把各个数据源里的元数据“捞”上来，存到统一的元数据中心。

采集方式我归纳为三种：

主动采集（Pull）：通过JDBC/ODBC直连数据库，读取系统表或INFORMATION_SCHEMA。适合关系型数据库。
被动采集（Push）：数据源主动上报元数据变更事件。适合流式或消息队列场景。
接口采集（API）：通过数据源提供的API获取元数据。适合SaaS或云服务。

我个人最推荐主动采集 + 增量同步的组合。为什么？

我曾经在一个金融项目里，每天全量采集2000多张表的元数据——跑了三个月，采集任务比业务ETL还慢。后来改成增量采集，只抓取上次采集后有变更的表，性能提升了80%以上。

避坑指南： 我曾经遇到过采集任务把源库系统表锁死的情况。原因是并发采集时，多个线程同时查询 information_schema.tables，导致源库元数据锁竞争。解决方案：加一个采集调度层，控制并发数不超过3，并且错峰执行。

下面是一个简单的采集调度伪代码：

# 元数据采集调度（Python 伪代码）
def collect_metadata(source_config):
    # 1. 获取上次采集时间戳
    last_collect = get_last_collect_time(source_config['source_id'])
    
    # 2. 只采集变更的表
    changed_tables = get_changed_tables(
        source_config, 
        since=last_collect
    )
    
    # 3. 逐表采集字段级元数据
    for table in changed_tables:
        fields = extract_fields(source_config, table)
        save_to_metastore(source_config['source_id'], table, fields)
    
    # 4. 更新采集时间戳
    update_collect_time(source_config['source_id'])

4.3 元数据血缘分析：数据质量问题的“导航仪”

元数据血缘，就是搞清楚数据从产生、加工到消费的完整链路。为什么它对数据质量这么重要？

你想想看，一个报表数据对不上，你从报表一路往回查，可能要经过5个ETL任务、3个中间表、2个数据源——如果没有血缘关系，你只能靠人工翻代码，效率极低。

血缘分析的核心是字段级依赖。我把它分成三个粒度：

表级血缘：表A → 表B → 表C，知道数据流向。
字段级血缘：表A.col1 → 表B.col2，精确到字段映射。
任务级血缘：ETL任务JOB_001 产出表B，关联调度依赖。

在实际项目中，我一般从SQL解析入手。比如，从ETL脚本里提取INSERT ... SELECT语句，解析出源字段和目标字段的映射关系。

-- 示例：从ETL脚本中解析血缘
-- 源表：ods.user_login
-- 目标表：dw.dws_user_daily
INSERT INTO dw.dws_user_daily
SELECT 
    user_id,           -- ods.user_login.user_id
    login_date,        -- ods.user_login.login_date
    COUNT(*) AS login_cnt
FROM ods.user_login
WHERE login_date = '${yesterday}'
GROUP BY user_id, login_date;

解析后，我们可以得到这样的血缘关系：

目标字段	源字段	转换逻辑
dw.dws_user_daily.user_id	ods.user_login.user_id	直接映射
dw.dws_user_daily.login_date	ods.user_login.login_date	直接映射
dw.dws_user_daily.login_cnt	ods.user_login.user_id	COUNT(*) 聚合

    核心观点： 血缘分析不是一次性工程。数据链路每天都在变，必须建立增量血缘采集机制。我习惯在ETL调度框架里埋点，每次任务执行完，自动上报输入输出关系。

下面这张图，是我在一个项目中设计的元数据血缘架构，你可以参考：

4.4 血缘分析在质量监控中的实战用法

光有血缘图还不够，得让它真正为质量监控服务。我总结了几种常见场景：

质量告警溯源：某个字段质量规则告警，通过血缘反向追溯，找到最上游的数据源或ETL任务。
变更影响分析：上游表结构变更（如新增字段、修改类型），自动评估下游哪些表、哪些质量规则会受影响。
质量评分传导：上游数据质量评分低，自动降低下游依赖表的信用分，触发更严格的监控。

一个小技巧： 我习惯在血缘关系里加一个“质量传播系数”。比如，上游字段质量分0.8，经过一个简单的直接映射，下游继承0.8；但如果经过聚合计算（如SUM、COUNT），质量传播系数会降低，因为聚合可能掩盖部分数据问题。

嗯，最后说一句。元数据管理不是一蹴而就的，它需要持续迭代。我见过很多团队一开始雄心勃勃，建了完整的元数据平台，结果半年后没人维护，变成了一堆死数据。我的建议是：先跑通核心链路，再逐步扩展。从最关键的10张表开始，把血缘跑起来，让业务看到效果，后面的事情就好办了。