元数据管理
概述
数据量一大，"这张表谁在用、这个字段什么意思、这个指标怎么算的"就会变成黑洞。元数据管理就是给数据建立"说明书"：记录表结构、血缘关系、指标口径与资产归属。本文覆盖元数据分类、血缘、数据地图/字典、指标口径管理与资产盘点。
一、元数据分类
| 分类 | 内容 | 示例 |
|---|---|---|
| 技术元数据 | 表结构、分区、依赖关系 | ods_order 的字段、分区 |
| 业务元数据 | 字段业务含义、指标定义 | "GMV = 已支付订单金额" |
| 管理元数据 | 责任人、权限、生命周期 | 表负责人、T+1 更新 |
三层元数据结合，才能回答"这个表是什么、谁负责、被谁消费"。
二、数据血缘
2.1 血缘的作用
| 用途 | 说明 |
|---|---|
| 影响分析 | 改 ODS 字段，知道会波及哪些 DWD/ADS |
| 问题定位 | 报表数据不对，沿血缘找到源头 |
| 合规审计 | 数据从哪来、去了哪，满足审计要求 |
| 数据地图 | 为下游用户展示数据的来龙去脉 |
2.2 血缘类型
| 类型 | 粒度 | 说明 |
|---|---|---|
| 表级血缘 | 表 → 表 | 哪张表由哪张表产出 |
| 字段级血缘 | 字段 → 字段 | 具体列之间的映射 |
| 任务级血缘 | 任务 → 任务 | 调度任务间的依赖 |
2.3 血缘采集方式
| 方式 | 原理 | 特点 |
|---|---|---|
| SQL Parser | 解析 Hive/Spark SQL 的 SELECT/JOIN/INSERT | 自动、实时，覆盖大部分场景 |
| 日志解析 | 解析执行计划/运行时日志 | 准确但成本高 |
| 人工登记 | 平台手工录入依赖 | 兜底，易漏 |
字段级血缘是重点：通过解析 SQL 的列投影与 Join 条件，得到"dws_user_daily.order_amount 来自 dwd_order.amount"这样的精确映射。
2.4 血缘采集示例（SQL）
sql
INSERT OVERWRITE TABLE dws_user_daily
SELECT user_id, COUNT(*), SUM(amount) -- dws.order_count ← dwd 行数
FROM dwd_order_detail -- dws.order_amount ← dwd.amount
WHERE dt = '20260816'
GROUP BY user_id;Parser 解析出：dws_user_daily ← dwd_order_detail，字段 order_amount ← amount。
三、数据地图与数据字典
3.1 数据地图
以可视化的方式呈现数据资产分布：按业务域（交易/营销/风控）组织，展示表清单、责任人、表间血缘图。用户像逛"地图"一样找数据。
3.2 数据字典
每个字段的权威说明，是数据使用者的第一入口：
| 字段 | 类型 | 含义 | 口径 | 责任人 |
|---|---|---|---|---|
order_id | BIGINT | 订单号 | 业务订单主键 | 交易组 |
amount | DECIMAL(10,2) | 订单金额 | 含税、未扣除优惠前 | 交易组 |
status | STRING | 订单状态 | 枚举：待支付/已支付/已取消 | 交易组 |
数据字典解决"这个字段能不能这么用"的口径问题，是口径管理的底座。
四、指标口径管理
4.1 问题来源
同一个"GMV"在不同报表里可能是：下单金额、支付金额、含退款、不含退款……口径不统一是数仓最大的信任危机。
4.2 指标分层定义
| 指标层次 | 定义 |
|---|---|
| 原子指标 | 不可再分的度量（订单金额） |
| 派生指标 | 原子指标 + 限定条件（已支付订单金额） |
| 复合指标 | 多个指标运算（支付转化率） |
4.3 指标字典示例
| 指标名 | 口径 | 统计维度 | 更新时间 |
|---|---|---|---|
| 支付 GMV | 状态=已支付且未退款的订单金额 SUM | 天 | T+1 |
| 下单 UV | 去重 user_id 数 | 天 | T+1 |
| 支付转化率 | 支付 UV / 下单 UV | 天 | T+1 |
指标必须在 DWS 层只算一次，下游引用指标 ID 而不是重写 SQL，这是口径一致的关键机制。
五、资产管理
5.1 资产盘点维度
| 维度 | 内容 |
|---|---|
| 资产登记 | 表/任务/指标的全量台账 |
| 资产分级 | 按重要性与敏感度分级（核心/重要/普通） |
| 生命周期 | 活跃、废弃、下线状态管理 |
| 归属管理 | 明确表与任务的责任人 |
| 成本管理 | 存储/计算成本归属到业务域 |
5.2 资产盘点流程
1. 采集：自动扫描元数据（Hive MetaStore、调度平台）
2. 治理：补业务元数据、定责任人、分级
3. 展示：资产目录 + 数据地图
4. 运营：定期清理僵尸表、无效任务
5. 持续：变更登记、质量绑定5.3 僵尸表治理
| 规则 | 说明 |
|---|---|
| 30 天无访问 | 标记为疑似废弃 |
| 90 天无访问 | 通知责任人确认 |
| 确认废弃 | 归档下线，释放存储 |
六、工具选型
| 工具 | 特点 | 适用 |
|---|---|---|
| Apache Atlas | Hive/Spark 血缘、分类、标签 | CDP 体系原生 |
| DataHub / Amundsen | 现代元数据平台，搜索/血缘/文档 | 独立部署、体验好 |
| 自研平台 | 深度贴合公司流程 | 大厂成熟后自建 |
| 云上 | EMR/Databricks 自带元数据 | 云厂商环境 |
选型建议：中小团队直接上 Atlas 或 DataHub，成熟后沉淀自研；选型关键是字段级血缘能力与公司现有引擎的适配。
七、常见问题
| 问题 | 处理 |
|---|---|
| 血缘采不全 | 规范 SQL 写法（不用 insert select * 乱拼），Parser 白名单补充 |
| 口径打架 | 指标 ID 统一注册，DWS 唯一计算 |
| 资产无人认领 | 上线即登记责任人，纳入准入流程 |
| 元数据过期 | 变更通知自动触发元数据刷新 |