元数据管理基础:元数据的定义、技术元数据、业务元数据、操作元数据
聊数据目录之前,咱们得先把「元数据」这事儿掰扯清楚。我见过不少团队,一上来就搭平台、建索引,结果连元数据是什么都没对齐。说白了,元数据就是「关于数据的数据」。你想想看,你拿到一张 Excel 表,光看文件名你能知道它是什么时候生成的、谁创建的、字段含义是什么吗?不能。这些信息,就是元数据要回答的。
核心一句话:元数据是数据的「身份证」+「户口本」。没有它,数据就是一盘散沙。
元数据的三种分类
业内一般把元数据分成三类:技术元数据、业务元数据、操作元数据。我习惯用一个比喻来理解——技术元数据是「骨架」,描述数据怎么存、怎么取;业务元数据是「血肉」,告诉业务人员这数据啥意思;操作元数据是「脉搏」,记录数据怎么跑、谁碰过。
下面这张图,把三者的关系画清楚了:
技术元数据:数据的「骨架」
技术元数据,说白了就是给工程师看的。它回答的是「数据长什么样、存在哪、怎么来的」。
我举个例子。你在 Hive 里建了一张表:
CREATE TABLE user_order (
user_id STRING COMMENT '用户ID',
order_id STRING COMMENT '订单ID',
amount DECIMAL(10,2) COMMENT '订单金额',
create_ts TIMESTAMP COMMENT '创建时间'
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET;
这里面每一行都是技术元数据:字段名、类型、注释、分区字段、存储格式。我当年接手一个数据平台,光找这些信息就花了两周——没人维护元数据,全靠翻代码。后来我养成了一个习惯:建表必写 COMMENT,跑 ETL 必记录映射关系。
技术元数据通常包括:
- 数据源信息:数据库连接、表名、视图、文件路径
- 数据结构:字段名、数据类型、长度、精度、默认值
- 数据约束:主键、外键、唯一索引、非空约束
- 数据血缘:ETL 作业的输入输出、字段级转换逻辑
- 存储信息:文件格式、压缩方式、分区策略、数据量
我的经验:技术元数据是数据目录的「地基」。地基没打好,后面业务元数据再漂亮也是空中楼阁。我建议团队在搭建数据目录时,先花 70% 的精力把技术元数据采集全,再去做业务层面的加工。
业务元数据:数据的「血肉」
业务元数据是给数据分析师、产品经理、业务运营看的。他们不关心表怎么存的,只关心「这个字段到底啥意思」「这个指标怎么算的」。
举个例子。一张订单表里有个字段叫 status,技术元数据告诉你它是 INT 类型。但业务元数据会告诉你:0=待支付,1=已支付,2=已发货,3=已完成,-1=已取消。你看,没有业务元数据,业务人员拿到数据根本没法用。
业务元数据的核心内容:
- 数据字典:字段的业务含义、枚举值说明、示例数据
- 指标定义:比如「活跃用户」怎么定义——是登录算活跃,还是有点击行为算活跃?口径必须写清楚
- 数据质量规则:非空率、唯一性、取值范围、业务逻辑校验
- 数据所有权:谁负责维护、谁可以访问、数据安全等级
- 数据使用说明:常见查询场景、注意事项、关联表推荐
我曾经遇到过一个经典场景:业务方要拉「近 30 天复购率」,结果三个部门给了三个不同的数字。一查才发现,A 部门把「复购」定义为「30 天内下过 2 单」,B 部门定义为「30 天内下过 1 单且金额 > 0」,C 部门更离谱,把退款订单也算进去了。这就是业务元数据没对齐的后果。
注意:业务元数据最容易被忽视,也最容易「烂尾」。很多团队把技术元数据采集完就觉得完事了,结果业务方用不起来。我建议让业务人员参与元数据的维护,至少每个核心指标要有一个「业务负责人」签字确认。
操作元数据:数据的「脉搏」
操作元数据记录的是数据「怎么跑、谁碰过、跑得怎么样」。它不像前两种那么「显眼」,但出了问题全靠它排查。
我印象很深的一次事故:某天凌晨数据管道突然挂了,生产报表全没更新。我登录调度系统一看,操作元数据清清楚楚地记录了——某个上游表因为数据量暴增,ETL 跑了 3 小时还没跑完,超时被 kill 了。没有操作元数据,你连问题出在哪都不知道。
操作元数据包括:
| 类别 | 具体内容 | 典型用途 |
|---|---|---|
| 作业调度 | 作业名称、调度频率、依赖关系、运行状态、开始/结束时间 | 排查数据延迟、定位失败作业 |
| 数据访问 | 谁在什么时间查询了哪些表、查询耗时、扫描数据量 | 审计、成本分析、热点表识别 |
| 数据变更 | 表结构变更记录、数据更新历史、版本号 | 回滚、影响分析、合规审计 |
| 数据质量 | 校验规则执行结果、异常记录、告警信息 | 数据质量监控、问题追溯 |
| 数据量统计 | 每日数据增量、总数据量、分区大小 | 存储规划、成本控制 |
一个小建议:操作元数据最好做到「自动采集」。手动记录?不现实。我见过最靠谱的做法是:在调度系统、查询引擎、数据质量平台里埋点,统一汇入元数据中心。这样出了问题,你只需要查一个地方。
三种元数据如何协同工作
你可能会问:这三种元数据分开讲我能理解,但实际工作中它们怎么配合?
我拿一个真实场景来说。假设业务方问:「上个月的新客首单转化率是多少?」
- 技术元数据告诉你:数据在 Hive 的
dw.dws_user_first_order表里,字段有user_id、first_order_amt、first_order_dt,分区字段是dt。 - 业务元数据告诉你:「新客」定义为「注册时间在 30 天内的用户」,「首单转化率」=「完成首单的用户数 / 新客总数」。
- 操作元数据告诉你:这张表每天凌晨 3 点更新,昨天跑了 20 分钟,数据量 500 万行,没有报错。
你看,三个维度缺一不可。没有技术元数据,你找不到表;没有业务元数据,你算不对指标;没有操作元数据,你不敢信数据。
总结一下:元数据管理不是「一次性工程」,而是需要持续维护的「数据基础设施」。技术元数据是底座,业务元数据是桥梁,操作元数据是保障。三者配合好了,数据目录才能真正用起来。