文章
三类元数据的存储方式和关联关系
一、三类元数据的本质区别
| 元数据类型 | 核心描述对象 | 典型字段 | 核心用途 |
|---|---|---|---|
| 技术元数据 | 数据物理结构 | 库名、表名、字段名、字段类型、约束、索引 | 指导系统开发和运维 |
| 业务元数据 | 数据业务含义 | 业务定义、指标公式、敏感等级、关联业务流程 | 支撑业务分析和决策 |
| 管理元数据 | 数据治理过程信息 | 创建人、创建时间、责任人、访问权限、变更历史 | 保障数据安全与合规 |
二、存储模型的工业实践
1. 基础方案（单表混合存储）
CREATE TABLE metadata_basic (
-- 技术元数据
db_name VARCHAR(100) COMMENT '库名',
table_name VARCHAR(100) COMMENT '表名',
column_name VARCHAR(100) COMMENT '字段名',
data_type VARCHAR(50) COMMENT '字段类型',
is_pk BOOLEAN COMMENT '是否主键',
-- 业务元数据
business_definition TEXT COMMENT '业务定义',
data_owner VARCHAR(50) COMMENT '业务负责人',
sensitivity_level ENUM('公开','内部','秘密') COMMENT '敏感等级',
-- 管理元数据
creator VARCHAR(50) COMMENT '创建人',
create_time DATETIME COMMENT '创建时间',
last_modified TIMESTAMP COMMENT '最后修改时间',
PRIMARY KEY (db_name, table_name, column_name)
);- 优点：简单易实现，适合小型团队
- 缺点：业务属性扩展困难（如新增"财务指标标记"需改表结构）
2. 进阶方案（多表关联存储）
- 优势：
- 业务属性可灵活扩展（如新增"GDPR合规标记"只需在业务表加字段）
- 管理元数据可保留完整变更历史
- 典型查询：
-- 获取字段完整信息（三表关联）
SELECT
t.*, b.definition, g.operator
FROM
technical_metadata t
LEFT JOIN business_metadata b ON t.db_name=b.db_name AND t.table_name=b.table_name
LEFT JOIN governance_metadata g ON t.db_name=g.db_name AND t.table_name=g.table_name
WHERE
t.table_name = 'order_main';三、不同规模企业的选择建议
1. 初创企业（<10人数据团队）
- 方案：单表混合存储
- 工具：Excel/简单MySQL表
- 示例字段：
| 字段名 | 类型 | 业务定义 | 敏感等级 | 创建人 |
|------------|--------|-----------------|--------|-------|
| user_phone | string | 用户注册手机号 | 秘密 | 张三 |2. 中大型企业（专业数据治理）
- 方案：多表关联+专业工具
- 工具栈：
- 技术元数据：Apache Atlas（自动采集）
- 业务元数据：Collibra（业务术语表）
- 管理元数据：Alation（变更审计）
- 集成架构：
四、元数据关联的黄金法则
- 必选关联：
- 每个业务字段必须绑定到技术字段（1:1）
- 每个技术变更必须记录管理信息（1:N）
- 可选扩展：
五、典型案例分析
案例：银行客户手机号管理
| 元数据类型 | 存储内容 |
|---|---|
| 技术元数据 | cust_info.mobile_no VARCHAR(11) NOT NULL |
| 业务元数据 | "客户实名认证手机号，用于接收交易验证码。需符合工信部号码规则" |
| 管理元数据 | 创建人：李四（2023-01-01）；最后修改：王五（2023-05-20 GDPR合规性更新） |
关联查询：
-- 查找所有PII字段及其合规要求
SELECT
t.table_name, t.column_name,
b.definition, g.change_time
FROM
technical_metadata t
JOIN business_metadata b ON t.column_id = b.column_id
JOIN governance_metadata g ON t.column_id = g.column_id
WHERE
b.sensitivity_level = '秘密';总结
- 您理解正确：单表可以包含三类元数据，这是合理的最小可行方案
- 工业级实践：建议将业务/管理元数据分离存储，便于扩展和版本管理
- 关键原则：
- 技术元数据是锚点（必须存在）
- 业务元数据是标签（可动态添加）
- 管理元数据是日志（按时间累积）
是否需要分表，取决于：
- 业务属性的复杂度（是否频繁新增字段）
- 变更历史的完整性要求
- 查询性能需求（联合查询 vs 单表扫描）
对于大多数企业，建议从单表开始，当出现以下信号时考虑分表：
- 业务字段频繁增减（每月>2次）
- 需要保留完整的字段变更历史
- 元数据查询成为性能瓶颈