没有元数据，就没有数据管理
元数据最常见的定义是「关于数据的数据」。图书馆没有目录卡片，读者就不知道该馆有什么、书放在哪里；组织没有元数据，就不知道拥有什么数据、数据表示什么、来自哪里、如何在系统中流转、谁有权访问、质量如何。
- 元数据帮助理解数据、系统与流程，评估质量，并支撑集成、保护与治理
- 要实现数据驱动，组织必须先实现元数据驱动
- 元数据管理不善会导致重复的字典与存储库、定义冲突、版本矛盾和使用者失去信心
- 元数据本身也是数据，必须像数据一样管理质量、安全与生命周期
三类元数据
元数据通常分为业务、技术和操作三类。分类最好依据来源而不是使用方式，因为同一份元数据可能同时被业务和技术人员使用。
- ISO/IEC 11179 提供元数据注册框架，从数据元素出发支持元数据驱动的交换
- 业务元数据常需重新定义，而不是直接接受现有含糊定义；这需要专职岗位与写作/辅导能力
- 技术元数据可从数据库对象与工具中采集；操作元数据在处理过程中生成
- 数据湖要为每个对象采集最小元数据集（名称、格式、来源、版本、接收日期）
| 类型 | 关注点 | 典型内容 |
|---|---|---|
| 业务元数据 | 数据的内容、含义与治理信息 | 业务名称与定义、业务规则、计算公式、数据模型、质量规则、血缘、标准、所有者、密级、已知问题 |
| 技术元数据 | 技术细节、存储系统与流转过程 | 物理表名/字段名、数据类型、键与索引、访问权限、ETL 作业、源到目标映射、调度依赖、备份规则 |
| 操作元数据 | 处理与访问数据的细节 | 作业日志、抽取历史、异常、审计结果、错误日志、查询模式与频率、补丁级别、容量与保留规则 |
图书馆视角还可分描述、结构、管理元数据；非结构化数据更依赖描述与结构元数据才能被检索和保存。
元数据架构与元模型
元数据架构要能扫描不同来源、定期更新存储库，并支持手工维护、查询与多用户访问。对最终用户而言，应提供统一入口，屏蔽底层来源差异。常见存储架构有集中式、分布式和混合式。
- 创建元模型：定义存储库的数据模型，先概念级描述实体关系，再细化属性与处理过程
- 应用标准：对内统一命名、属性、安全、可见性与流程；对外采用交换格式与接口标准
- 选择架构：根据来源数量、实时性、治理成熟度选择集中、分布或混合
- 采集与集成：从数据库、ETL、BI、建模工具、业务术语表等来源抽取，处理冲突与重复
- 管理存储：调度监控、加载统计、备份恢复归档、配置、性能、查询统计与报表
- 发布与使用：提供搜索、浏览、血缘、影响分析与自助查询
元数据管理活动
元数据管理需要战略、需求、架构、实施与持续运营。战略要与业务优先级一致，从短期可见价值切入，再逐步扩展。
- 需求要明确：更新频率、同步时延、是否保留历史、访问权限、存储结构、集成规则、运维与管理职责、质量与安全要求
- 业务术语表需要工作流：候选、审批、发布、更新、删除，并管理术语关系与分类
- 元数据战略要嵌入 SDLC，确保变更及时被采集，避免存储库过期
- 治理团队负责定义标准、管理状态变化、组织培训与质量提升
- 敏感元数据也可能泄露机密信息，访问控制同样适用
治理与度量
元数据治理要验证：没有元数据会造成什么影响。可以把「使用者查找信息所花的时间」作为基线，在实施后对比改进。
- 元数据质量应由产生元数据的流程所有者负责，而不是全压给元数据团队
- 建立反馈机制，让使用者报告错误或过时的元数据
- 元数据标准要定期审计，确保跨工具、跨组织可集成
| 指标 | 说明 |
|---|---|
| 存储库完整性 | 理想覆盖率与实际覆盖率之比 |
| 管理成熟度 | 参考 CMM-DMM 等模型评估 |
| 专职人员配备 | 任命情况、覆盖范围、角色定义 |
| 使用情况 | 访问次数、查询量、定性调研 |
| 业务术语活动 | 使用、更新、定义解析、覆盖范围 |
| 文档质量 | 有定义的属性百分比、自动/手动质量评估 |
| 存储库可用性 | 正常运行时间、批处理与查询处理时间 |
元数据质量同样要看完整性、可靠性、一致性与时效性，不能只统计「收录了多少条」。