1. 元数据管理
1. 业务驱动因素
- 通过提供上下文语境和执行数据质量检查提高数据的可信度
- 通过扩展用途增加战略信息（如主数据）的价值
- 通过识别冗余数据和流程提高运营效率
- 防止使用过时或不正确的数据
- 减少数据的研究时间
- 改善数据使用者和IT专业人员之间的沟通
- 创建准确的影响分析，从而降低项目失败的风险
- 通过缩短系统开发生命周期时间缩短产品上市时间
- 通过全面记录数据背景、历史和来源降低培训成本和员工流动的影响
- 满足监管合规
2. 原则
- 组织承诺：将数据作为企业资产进行管理
- 战略：战略能推动需求， 要与业务优先级保持一致
- 企业视角：确保未来的可扩展性
- 潜移默化：宣导元数据的必要性和每种元数据的用途，潜移默化其价值将鼓励业务使用元数据，同时也为业务提供知识辅助
- 访问：确保员工了解如何访问和使用元数据
- 质量：流程所有者应对元数据的质量负责
- 审计：制定、实施和审核元数据标准，以简化元数据的集成和使用
- 改进：创建反馈机制
3. 元数据的类型
1. 业务元数据
主要关注数据的内容和条件，另包括与数据治理相关的详细信息。业务元数据包括主题域、概念、实体、属性的非技术名称和定义、属性的数据类型和其他特征，如范围描述、计算公式、算法和业务规则、有效的域值及其定义
- 数据集、表和字段的定义和描述
- 业务规则、转换规则、计算公式和推导公式
- 数据模型
- 数据质量规则和检核结果
- 数据的更新计划
- 数据溯源和数据血缘
- 数据标准
- 特定的数据元素记录系统
- 有效值约束
- 利益相关方联系信息（如数据所有者、数据管理专员）
- 数据的安全/隐私级别
- 已知的数据问题
- 数据使用说明
2. 技术元数据
提供有关数据的技术细节、 存储数据的系统以及在系统内和系统之间数据流转过程的信息
- 物理数据库表名和字段名
- 字段属性
- 数据库对象的属性
- 访问权限
- 数据 CRUD（增、删、改、查）规则
- 物理数据模型，包括数据表名、键和索引
- 记录数据模型与实物资产之间的关系
- ETL作业详细信息
- 文件格式模式定义
- 源到目标的映射文档
- 数据血缘文档，包括上游和下游变更影响的信息
- 程序和应用的名称和描述
- 周期作业（内容更新）的调度计划和依赖
- 恢复和备份规则
- 数据访问的权限、组、角色
3. 操作元数据
描述了处理和访问数据的细节
- 批处理程序的作业执行日志
- 抽取历史和结果
- 调度异常处理
- 审计、平衡、控制度量的结果
- 错误日志
- 报表和查询的访问模式、频率和执行时间
- 补丁和版本的维护计划和执行情况，以及当前的补丁级别
- 备份、保留、创建日期、灾备恢复预案
- 服务水平协议（SLA）要求和规定
- 容量和使用模式
- 数据归档、保留规则和相关归档文件
- 清洗标准。
- 数据共享规则和协议。
- 技术人员的角色、职责和联系信息
4. 非结构化数据的元数据
元数据对非结构化数据的管理可能更重要，包括：
- 描述元数据：如目录信息和同义关键字
- 结构元数据：如标签、字段结构、特定格式
- 管理元数据：如来源、更新计划、访问权限和导航信息
- 书目元数据：如图书馆目录条目
- 记录元数据：如保留策略
- 保存元数据：如存储、归档条件和保存规则
5. 元数据来源
元数据通常是作为应用程序处理的副产品而不是最终产品创建的，其来源主要有：
- 应用程序中元数据存储库：指存储元数据的物理表，常内置于建模工具、BI 工具和其他应用程序中
- 业务术语表：记录和存储组织的业务概念、术语、定义及关系，要满足以下三类人，业务用户、数据管理专员、技术用户
- 商务智能工具
- 配置管理工具
- 数据字典
- 数据集成工具：数据集成工具提供了应用程序接口（API），允许外部元数据存储库提取血缘关系信
- 数据库管理和系统目录：数据库目录是元数据的重要来源， 它们描述了数据库的内容、信息大小、软件版本、部署状态、网络正常运行时间、基础架构正常运行时间、可用性，以及许多其他操作元数据属性
- 数据映射管理工具：通常也存储在整个企业的 Excel 文档中
- 数据质量工具
- 字典和目录：包含有关组织内数据的系统 源和位置的信息
- 事件消息工具
- 建模工具和存储库
- 参考数据库：记录各种类型的枚举数据（值域）的业务价值和描述
- 服务注册：SOA 角度管理和存储有关服务和服务终端的技术信息
- 其他元数据存储：特定格式的清单
6. 元数据的生命周期
创建和采集、存储、集成、交付、使用、控制和管理。
7. 元数据架构的类型
1. 集中式元数据架构
集中式元数据架构由单一的元数据存储库组成，包含来自各种不同源的元数据副本。
优点：
- 高可用性，因为它独立于源系统
- 快速的元数据检索，因为存储库和查询功能在一起
- 解决了数据库结构问题，使其不受第三方或商业系统特有属性的影响
- 抽取元数据时可进行转换、自定义或使用其他源系统中的元数据进行补充，提高了元数据的质量
缺点：
- 必须使用复杂的流程确保元数据源头中的更改能够快速同步到存储库中
- 维护集中式存储库的成本可能很高
- 元数据的抽取可能需要自定义模块或中间件
- 验证和维护自定义代码会增加对内部 IT 人员和软件供应商的要求
2. 分布式元数据架构
维护了单一的接入点， 没有持久化的存储库， 元数据检索引擎负责从源系统检索数据来响应用户请求。
优点：
- 元数据总是尽可能保持最新且有效，因为它是从其数据源中直接检索的
- 查询是分布式的，可能会提高响应和处理的效率
- 来自专有系统的元数据请求仅限于查询处理，而不需要详细了解专有数据结构，因此最大限度地减少了实施和维护所需的工作量
- 自动化元数据查询处理的开发可能更简单，只需要很少的人工干预
- 减少了批处理，没有元数据复制或同步过程
缺点：
- 无法支持用户自定义或手动插入的元数据项，因为没有存储库可以放置这些添加项
- 需要通过统一的、标准化的展示方式呈现来自不同系统的元数据
- 查询功能受源系统可用性的影响
- 元数据的质量完全取决于源系统
3. 混合元数据架构
结合集中式和分布式的特性
4. 双向元数据架构
允许元数据在架构的任何部分（源、 数据集成、 用户界面）中进行更改，然后将变更从存储库（代理） 同步到其原始源以实现反馈，强制对源的更新
8. 定义元数据架构基本步骤
创建元模型、应用元数据标准、管理元数据存储
