元数据管理 | 第十二章 | shmaur

shmaur
2024-08-27
-
-

一、引言

        元数据的定义是:关于数据的数据。

        可以归类为元数据的信息范围很广, 不仅包括技术和业务流程、 数据规则和约束, 还包括逻辑数据结构与物理数据结构等。它描述了数据本身(如数据库、 数据元素、 数据模型) , 数据表示的概念(如业务流程、 应用系统、 软件代码、 技术基础设施) , 数据与概念之间的联系(关系) 。 元数据可以帮助组织理解其自身的数据、 系统和流程, 同时帮助用户评估数据质量。

        元数据管理不仅是知识管理面临的一个挑战, 还是风险管理的一个必要条件。 元数据可以确保组织识别私有的或敏感的数据, 能够管理数据的生命周期, 以实现自身利益, 满足合规要求, 并减少风险敞口。

        要实现数据驱动, 组织必须先实现元数据驱动。


 

图片来自作者

 

1.1 业务驱动因素

1.1.1数据管理需要元数据,元数据本身也需要管理

1) 通过提供上下文语境和执行数据质量检查提高数据的可信度。
2) 通过扩展用途增加战略信息(如主数据) 的价值。
3) 通过识别冗余数据和流程提高运营效率。
4) 防止使用过时或不正确的数据。
5) 减少数据的研究时间。
6) 改善数据使用者和IT专业人员之间的沟通。
7) 创建准确的影响分析, 从而降低项目失败的风险。
8) 通过缩短系统开发生命周期时间缩短产品上市时间。
9) 通过全面记录数据背景、 历史和来源降低培训成本和员工流动
的影响。
10) 满足监管合规。

 

1.1.2 元数据管理不善容易导致

冗余的数据和数据管理流程

重复和冗余的字典、存储库和其他元数据存储

不一致的数据元素定义和与数据滥用的相关风险

元数据的不同版本相互矛盾且有冲突,降低了数据使用者的信心

怀疑元数据和数据的可靠性

 

1.2 目标和原则

1.2.1 元数据管理的目标包括

  1. 记录和管理与数据相关的业务术语的知识体系,以确保人们理解和使用数据内容的一致性。
  2. 收集和整合来自不同来源的元数据,确保人们了解来自组织不同部门的数据之间的相似与差异。
  3. 确保元数据的质量、一致性、及时性和安全
  4. 提供标准途径,使元数据使用者可以访问元数据。
  5. 推广或强制使用技术元数据标准,以实现数据交换。

 

1.2.2 实施元数据解决方案应遵循以下指导原则

组织承诺:确保组织对元数据管理的承诺,将元数据管理作为企业整体战略的一部分,将数据作为企业资产管理。

战略:制定元数据战略,考虑如何创建、维护、集成和访问元数据。

企业视角:从企业视角确保未来的可扩展性,但是要通过迭代和增量交付方式来实现,以带来价值。

潜移默化:宣导i元数据的必要性 和每种元数据的用途。

访问:确保员工了解如何访问和使用元数据。

质量:认识到元数据通常师通过现有流程(数据建模、SDLC、业务流程定义)生成的,所以流程所有者应对元数据的质量负责。

审计:制定、实施和审核元数据标准,以简化元数据的集成和使用。

改进:创建反馈机制,以便数据使用者可以将错误的或过时元数据反馈给元数据管理团队。

1.3 基本概念

1.3.1 元数据与数据

元数据也是一种数据,应该用数据管理的方式进行管理。

如何在元数据和非元数据之间划分界限。 从概念上讲, 这条边界与数据所代表的抽象级别有关。 

一个人的元数据,可能是另一个人的数据。

数据可以作为输入,满足多个不同组织理解数据和分析数据的需求。

管理元数据,重点关注元数据用来做什么(创建新数据、了解现有数据、实现系统之间的流转、访问数据、共享数据)和满足这些需求的元数据。

1.3.2 元数据的类型

元数据通常分为三种类型: 业务元数据、 技术元数据和操作元数据。

在图书馆和信息科学院,元数据被描述为不同的类别

1) 描述元数据(Descriptive Metadata) 。 描述资源并支持识别和检索, 如标题、 作者和主题等。
2) 结构元数据(Structural Metadata) 。 描述资源及其组成组件之间的关系, 如页数、 章节等。3) 管理元数据( Administrative Metadata) 。 用于描述管理生命周期的元数据, 如版本号、 存档日期等。

1.3.2.1 业务元数据

业务元数据主要关注数据的内容和条件,另包括与数据治理相关的详细信息。业务元数据包括主题域、概念、实体、属性的非技术名称和定义、数据的数据类型和其他特征。

元数据的示例包括:

1) 数据集、 表和字段的定义和描述。
2) 业务规则、 转换规则、 计算公式和推导公式。
3) 数据模型。
4) 数据质量规则和检核结果。
5) 数据的更新计划。
6) 数据溯源和数据血缘。
7) 数据标准。
8) 特定的数据元素记录系统。
9) 有效值约束。
10) 利益相关方联系信息( 如数据所有者、 数据管理专员) 。
11) 数据的安全/隐私级别。
12) 已知的数据问题。
13) 数据使用说明。

1.3.2.2 技术元数据

技术元数据提供有关数据的技术细节、存储数据的系统以及在系统内和系统之间数据流转过程的信息。

技术元数据示例包括:

1) 物理数据库表名和字段名。
2) 字段属性。
3) 数据库对象的属性。4) 访问权限。
5) 数据CRUD( 增、 删、 改、 查) 规则。
6) 物理数据模型, 包括数据表名、 键和索引。
7) 记录数据模型与实物资产之间的关系。
8) ETL作业详细信息。
9) 文件格式模式定义。
10) 源到目标的映射文档。
11) 数据血缘文档, 包括上游和下游变更影响的信息。
12) 程序和应用的名称和描述。
13) 周期作业( 内容更新) 的调度计划和依赖。
14) 恢复和备份规则。
15) 数据访问的权限、 组、 角色。

 

1.3.2.3操作元数据

操作元数据描述了处理和访问数据的细节。

操作元数据示例包括:

1) 批处理程序的作业执行日志。
2) 抽取历史和结果。
3) 调度异常处理。
4) 审计、 平衡、 控制度量的结果。
5) 错误日志。
6) 报表和查询的访问模式、 频率和执行时间。
7) 补丁和版本的维护计划和执行情况, 以及当前的补丁级别。
8) 备份、 保留、 创建日期、 灾备恢复预案。
9) 服务水平协议( SLA) 要求和规定。
10) 容量和使用模式。
11) 数据归档、 保留规则和相关归档文件。
12) 清洗标准。
13) 数据共享规则和协议。
14) 技术人员的角色、 职责和联系信息。 

 

1.3.3 ISO/IEC 11179元数据注册标准

标准组成部分:

第一部分:数据元素生成和标准化框架

第二部分:数据元数据分类

第三部分:数据元素的基本属性。

第四部分:数据定义得到形成规则和指南

第五部分:数据元素的命名和识别原则

第六部分:数据元素的注册

1.3.4 非结构化数据的元数据

         所有数据都是由一定结构的。任何不在数据库或数据文件中的数据都被认为是非结构化数据。

         非结构化数据的元数据包括:描述元数据, 如目录信息和同义关键字; 结构元数据, 如标签、 字段结构、 特定格式; 管理元数据, 如来源、 更新计划、 访问权限和导航信息; 书目元数据, 如图书馆目录条目; 记录元数据, 如保留策略; 保存元数据, 如存储、 归档条件和保存规则。

         收集元数据作为数据采集流程的一部分, 需要收集关于在数据湖中采集的每个对象的最小元数据属性集(如名称、 格式、 来源、 版本、 接收日期等) , 这将生成数据湖内容的目录。

 

1.3.5 元数据来源

         操作元数据是在处理数据时生成的。 使用这类元数据的关键是以一种可用的形式进行收集, 并确保负责解释它的人拥有他们需要的工具。 要想理解错误日志中的信息, 需要理解描述日志文件中内容的元数据。

         最好是有意识地重新定义而不是简单地接受现有定义。 定义的确定需要时间和正确的技能(如写作和辅导技能) , 这就是业务元数据的开发需要专职岗位的原因。

         管理数据库所需的大部分技术元数据和使用数据所需的业务元数据, 可以作为项目工作的一部分进行收集和开发。 

         例如, 数据建模过程需要讨论数据元素的含义以及它们之间的关系。 应记录和整理讨论过程中共享的知识, 以便在数据字典、 业务术语表和其他存储库中使用。 数据模型本身包含数据物理特征的重要细节, 应在这些工作上分配足够的时间, 以确保项目产出物包含符合企业标准的高质量元数据。

         业务元数据可以在不同的项目中重复使用。并促进在不同数据集的业务概念得到一致理解。 组织还可以有意规划元数据的集成作为开发元数据的一部分, 以便元数据可以重复使用。 

         元数据与其他数据一样: 它应该作为有明确定义流程的产品而创建, 使用可以保障整体质量的工具, 管理员和其他数据管理专业人员应确保有适当的流程来维护与这些流程相关的元数据。

 

元数据的一系列来源有

       应用程序中元数据存储库:元数据存储库指存储元数据的物理表, 这些表通常内置在建模工具、 BI工具和其他应用程序中。

       业务术语表:业务术语表(Business Glossary) 的作用是记录和存储组织的业务概念、 术语、 定义以及这些术语之间的关系。

       业务词汇表应用程序的构建需满足三个核心用户的功能需求:

        1) 业务用户(Business users) 。 数据分析师、 研究分析师、 管理人员和使用业务术语表来理解术语和数据的其他人员。
        2) 数据管理专员(Data Stewards) 。 数据管理专员使用业务术语表管理和定义术语的生命周期, 并通过将数据资产与术语表相关联增强企业知识, 如将术语与业务指标、 报告、 数据质量分析或技术组件相关联。 数据管理员收集术语和使用中的问题, 以帮助解决整个组织的认识差异。
        3) 技术用户(Technical users) 。 技术用户使用业务术语表设计架构、 设计系统和开发决策, 并进行影响分析

       业务术语表应包含业务术语属性, 例如:
       1) 术语名称、 定义、 缩写或简称, 以及任何同义词。
       2) 负责管理与术语相关的数据的业务部门和/或应用程序。
       3) 维护术语的人员姓名和更新日期。
       4) 术语的分类或分类间的关联关系(业务功能关联) 。
       5) 需要解决的冲突定义、 问题的性质、 行动时间表。
       6) 常见的误解。
       7) 支持定义的算法。
       8) 血缘。
       9) 支持该术语的官方或权威数据来源。

        数据管理专员通常负责词汇表的开发、 使用、 操作和报告。 报告包括: 跟踪尚未审核的新术语和定义、 处于挂起状态的术语和缺少定义或其他属性的术语。

        商务智能工具:商务智能工具生成与商务智能设计相关的各类元数据, 包括概述信息、 类、 对象、 衍生信息和计算的项、 过滤器、 报表、 报表字段、 报表展现、 报表用户、 报表发布频率和报表发布渠道。

        配置管理工具:配置管理工具或数据库(CMDB) 提供了管理和维护与IT资产、 它们之间的关系以及资产的合同细节相关的元数据的功能。

        数据字典:

        数据字典定义数据集的结构和内容, 通常用于单个数据库、 应用程序或数据仓库。 数据字典可用于管理数据模型中每个元素的名称、 描述、 结构、 特征、 存储要求、 默认值、 关系、 唯一性和其他属性。 它还应包含表或文件定义。 数据字典嵌入在数据库工具中, 用于创建、 操作和处理其中包含的数据。 数据使用者如需使用这类元数据, 则必须从数据库或建模工具中进行提取。 数据字典还可以描述那些对社区有用的、在安全限制下可用的、 在业务流程中应用的数据元素。 通过直接利用逻辑数据模型中的内容, 在定义、 发布和维护用于报告和分析的语义层时可以节省时间。

        数据集成工具:许多数据集成工具用于可执行文件将数据从一个系统移动到另一个系统, 或在同一系统中的不同模块之间移动。 许多工具生成临时文件,其中可能包含数据的副本或派生副本。 这些工具能够从各种源加载数据, 通过分组、 修正、 重新格式化、 连接、 筛选或其他操作对加载的数据进行操作, 然后生成输出数据。 

        数据集成工具提供了应用程序接口(API) , 允许外部元数据存储库提取血缘关系信息和临时文件元数据。 一旦元数据存储库收集了信息, 元数据管理工具就可以为任何数据元素生成全局数据地图。 

        数据库管理和系统目录:数据库目录是元数据的重要来源, 它们描述了数据库的内容、 信息大小、 软件版本、 部署状态、 网络正常运行时间、 基础架构正常运行时间、 可用性, 以及许多其他操作元数据属性。 

        数据映射管理工具:映射管理工具用于项目的分析和设计阶段, 它将需求转换为映射规范, 然后由数据集成工具直接使用或由开发人员用来生成数据集成代码。 

        数据质量管理工具:数据质量工具通过验证规则来评估数据质量, 其中的大多数工具提供了与其他元数据存储库交换质量分数和质量概况的功能, 使元数据存储库能够将质量分数附加到相关的物理资产上。

       字典和目录:数据字典和术语表包含有关术语、 表和字段的详细信息, 但是字典或目录包含有关组织内数据的系统、 源和位置的信息。

       事件消息工具:事件消息工具在不同系统之间移动数据, 需要大量的元数据, 并生成描述此移动的元数据。

       建模工具和存储库:数据建模工具用于构建各种类型的数据模型: 概念模型、 逻辑模型和物理模型。

       参考数据库:参考数据记录各种类型的枚举数据(值域) 的业务价值和描述, 在系统中的上下文中使用。 用于管理参考数据的工具, 还能够管理相同或不同业务领域内不同编码值之间的关系。 

       服务注册:务注册是从面向服务的架构(SOA) 角度管理和存储有关服务和服务终端的技术信息, 如定义、 接口、 操作、 输入和输出参数、 制度、版本和示例使用场景。 一些与服务相关的最重要的元数据包括服务版本、 服务位置、 数据中心、 可用性、 部署日期、 服务端口、 IP地址、 统计端口、 连接超时和连接重试超时。 

其他元数据存储:其他元数据的种类繁多, 大多是指特定格式的清单, 如事件注册表、 源列表或接口、 代码集、 词典、 时空模式、 空间参考、 数字地理数据集的分发、 存储库的存储库和业务规则。

 

1.3.6 元数据架构的类型

       元数据管理解决方案都包含与元数据生命周期相对应的架构层次

  1. 元数据创建和采集
  2. 元数据在一个或多个存储库中存储
  3. 元数据集成
  4. 元数据交付
  5. 元数据使用
  6. 元数据控制和管理

      可以采用不同的架构方法获取、 存储、 集成和维护元数据, 供数据消费者访问元数据。

 

1.3.6.1 集中式元数据架构

      集中式元数据架构由单一的元数据存储库组成, 包含来自各种不同源的元数据副本。 

      集中式存储库的优点有:

      1) 高可用性, 因为它独立于源系统。
      2) 快速的元数据检索, 因为存储库和查询功能在一起。
      3) 解决了数据库结构问题, 使其不受第三方或商业系统特有属性的影响。
      4) 抽取元数据时可进行转换、 自定义或使用其他源系统中的元数据进行补充, 提高了元数据的质量。

      集中式存储库的缺点有:

      1) 必须使用复杂的流程确保元数据源头中的更改能够快速同步到存储库中。
      2) 维护集中式存储库的成本可能很高。
      3) 元数据的抽取可能需要自定义模块或中间件。
      4) 验证和维护自定义代码会增加对内部IT人员和软件供应商的要求。

 

1.3.6.2 分布式元数据架构

       一个完全分布式的架构中维护了一个单一的接入点。 元数据检索引擎通过实时从源系统检索数据来响应用户请求; 分布式元数据架构没有持久化的存储库。 在这种架构中, 元数据管理环境维护必要的源系统目录和查找信息, 以有效处理用户查询和搜索。

      1) 元数据总是尽可能保持最新且有效, 因为它是从其数据源中直接检索的。
      2) 查询是分布式的, 可能会提高响应和处理的效率。3) 来自专有系统的元数据请求仅限于查询处理, 而不需要详细了解专有数据结构, 因此最大限度地减少了实施和维护所需的工作量。
      4) 自动化元数据查询处理的开发可能更简单, 只需要很少的人工干预。
      5) 减少了批处理, 没有元数据复制或同步过程。

       分布式元数据架构的缺点包括
      1) 无法支持用户定义或手动插入的元数据项, 因为没有存储库可以放置这些添加项。
      2) 需要通过统一的、 标准化的展示方式呈现来自不同系统的元数据。
      3) 查询功能受源系统可用性的影响。
      4) 元数据的质量完全取决于源系统。

 

1.3.6.3 混合式元数据架构

       混合架构结合了集中式和分布式架构的特性, 元数据仍然直接从源系统移动到集中式存储库, 但存储库设计仅考虑用户添加的元数据、 重要的标准化元数据以及来通过自手工来源添加的元数据。

       从源头近乎实时地检索元数据和扩充元数据, 可在需要时最有效地满足用户需求。 混合方法降低了对专有系统进行手动干预和自定义编码访问功能的工作量。 基于用户的优先级和要求, 元数据在使用时尽可能是最新且有效的。 混合架构不会提高系统可用性。

 

1.3.6.4 双向元数据架构

       双向元数据架构, 它允许元数据在架构的任何部分(源、 数据集成、 用户界面) 中进行更改, 然后将变更从存储库(代理) 同步到其原始源以实现反馈。

       该设计强制元数据存储库包含最新版本的元数据源, 并强制对源的更改管理, 必须系统地捕获变更, 然后加以解决; 必须构建和维护附加的一系列处理接口, 以将存储库的内容回写至元数据源。

二、活动

2.1 定义元数据战略

       元数据战略描述组织应如何管理其自身元数据, 以及元数据从当前状态到未来状态的实施线路。 

       元数据战略包括定义组织元数据架构蓝图和与战略目标匹配的实施步骤

       1) 启动元数据战略计划。 启动和计划的目的是保证元数据战略团队可以定义出短期和长期目标。 

       2) 组织关键利益相关方的访谈。 通过对业务人员和技术人员的访谈, 可以得到元数据战略的基础知识。

       3) 评估现有的元数据资源和信息架构。 评估确定解决元数据和系统问题的难度, 在访谈和文档复查中识别这些问题。 

       4) 开发未来的元数据架构。 优化和确认未来愿景, 开发可以满足管理现阶段元数据环境长期目标的元数据架构。 这个阶段必须考虑战略组成部分, 如组织架构、 与数据治理所需的管理人员一致、 受控的元数据架构、 元数据交付架构、 技术架构和安全架构。

       5) 制订分阶段的实施计划。 从访谈和数据分析中验证、 整合、 确定结果的优先级, 发布元数据战略, 并定义分阶段的、 可以从当前状态迈向未来受控的元数据环境的实施方法。

 

2.2 理解元数据需求

       元数据需求的具体内容是: 需要哪些元数据和哪种详细级别。

       元数据综合解决方案由以下功能需求点组成:
           1) 更新频次。 元数据属性和属性集更新的频率。
           2) 同步情况。 数据源头变化后的更新时间。
           3) 历史信息。 是否需要保留元数据的历史版本。
           4) 访问权限。 通过特定的用户界面功能, 谁可以访问元数据, 如何访问。
           5) 存储结构。 元数据如何通过建模来存储。
           6) 集成要求。 元数据从不同数据源的整合程度, 整合的规则。
           7) 运维要求。 更新元数据的处理过程和规则(记录日志和提交申请) 。
           8) 管理要求。 管理元数据的角色和职责。
           9) 质量要求。 元数据质量需求。
         10) 安全要求。 一些元数据不应公开, 因为会泄露某些高度保密数据的信息。

 

2.3 定义元数据架构

       元数据管理系统必须具有从不同数据源采集元数据的能力, 设计架构时应确保可以扫描不同元数据源和定期地更新元数据存储库, 系统必须支持手工更新元数据、 请求元数据、 查询元数据和被不同用户组查询。

        受控的元数据环境应为最终用户屏蔽元数据的多样性和差异性。 元数据架构应为用户访问元数据存储库提供统一的入口, 该入口必须向用户透明地提供所有相关元数据资源, 这意味着用户可以在不关注数据源的差异的情况下访问元数据。 

       建立公共元数据存储库通常有三种技术架构方法: 集中式、 分布式和混合式。

 

2.3.1 创建元模型

       创建一个元数据存储库的数据模型, 也叫元模型, 是定义元数据战略和理解业务需求后的第一个设计步骤。 可以根据需求开发不同级别的元模型; 高级别的概念模型描述了系统之间的关系, 低级别的元模型细化了各个属性, 描述了模型组成元素和处理过程。 作为一种规划工具和表达需求的方案, 元模型本身也是一个有价值的元数据源。

 

2.3.2 应用元数据标准

       元数据解决方案应遵循在元数据战略中已定义的对内和对外的标准, 数据治理活动应监督元数据的标准遵从情况。 组织对内元数据标准包括命名规范、 自定义属性、 安全、 可见性和处理过程文档, 组织对外元数据标准包括数据交换格式和应程序接口设计。

 

2.3.3 管理元数据存储

       实施控制活动以管理元数据环境。 存储库的控制活动是由元数据专家执行的元数据迁移和存储库更新的控制。 这些活动本质是可管理的、可监控的、 可报告的、 可预警的、 有作业日志的, 同时可以解决各种已实施的元数据存储库环境的各种问题。

控制活动包括:

1) 作业调度和监控。
2) 加载统计分析。
3) 备份、 恢复、 归档、 消除。
4) 配置修改。
5) 性能调优。
6) 查询统计分析。
7) 查询和报表生成。
8) 安全管理。

质量控制活动包括:

1) 质量保证, 质量控制。
2) 数据更新频率——与时间表匹配。
3) 缺失元数据报告。
4) 未更新的元数据报告。

元数据管理活动包括:

1) 加载、 探测、 导入和标记数据资产。
2) 记录与源的映射和迁移关系。
3) 记录版本。4) 用户界面管理。
5) 连接数据集的元数据维护——为NOSQL提供支持。
6) 数据与对内数据采集建立连接——自定义连接和作业元数据。
7) 外部数据源和订阅源的许可。
8) 数据增强元数据, 如关联GIS。

培训活动包括:

1) 教育和培训用户和数据专员。
2) 生成和分析管理指标。
3) 对控制活动、 查询、 报告进行培训。

 

2.4 创建和维护元数据

管理元数据质量方法:

1) 责任( Accountability) 。 认识到元数据通常通过现有流程产生( 数据建模, SDLC, 业务流程定义) , 因此流程的执行者对元数据的质量负责。
2) 标准( Standards) 。 制定、 执行和审计元数据标准, 简化集成过程, 并且适用。
3) 改进( Improvement) 。 建立反馈机制保障用户可以将不准确或已过时的元数据通知元数据管理团队

整合元数据

集成过程中从整个企业范围内收集和整合元数据, 包括从企业外部获取的数据中的元数据。 元数据存储库应将提取的技术元数据与相关的业务、 流程和管理元数据集成在一起, 可以使用适配器、 扫描仪、 网桥应用程序或直接访问源数据存储中的方式来提取元数据。 

元数据存储库的扫描有两种不同的方式

1) 专用接口。 采用单步方式, 扫描程序从来源系统中采集元数据, 直接调用特定格式的装载程序, 将元数据加载到元数据存储中。 
2) 半专用接口。 采用两步方式, 扫描程序从来源系统中采集元数据, 并输出到特定格式的数据文件中。 扫描程序只产生目标存储库能够正确读取和加载的数据文件。 数据文件可以被多种方式读取, 所以这种接口的架构更加开放

在此过程中, 扫描程序产生和使用多种类型文件
1) 控制文件。 包含数据模型的数据源结构信息。
2) 重用文件。 包含管理装载流程的重用规则信息。
3) 日志文件。 在流程的每一阶段、 每次扫描或抽取操作生成的日志。
4) 临时和备份文件。 在流程中使用或做追溯流程所使用的文件。

可以使用一个非持久的元数据暂存区进行临时和备份文件的存储,暂存区应支持回滚和恢复处理, 并提供临时审计跟踪信息, 这样有助于存储库管理员追踪元数据来源或质量问题。 暂存区可以采用文件目录或数据库的形式。

分发和传递元数据

元数据可传递给数据消费者和需要处理元数据的应用或工具。 传递机制包括:
1) 元数据内部网站, 提供浏览、 搜索、 查询、 报告和分析功能。
2) 报告、 术语表和其他文档。
3) 数据仓库、 数据集市和BI(商务智能) 工具。
4) 建模和软件开发工具。
5) 消息传送和事务。
6) Web服务和应用程序接口(API) 。
7) 外部组织接口方案(如供应链解决方案) 。

元数据方案通常与商务智能方案有联系, 所以元数据方案的范围和流转与商务智能内容同步。 

 

2.5 查询、 报告和分析元数据

       元数据指导如何使用数据资产: 在商务智能(报表和分析) 、 商业决策(操作型、 运营型和战略型) 以及业务语义(业务所述内容及其含义) 方面使用元数据。 

 

三、工具

        管理元数据的主要工具是元数据存储库。 元数据存储库包括整合层和手工更新的接口。 处理和使用元数据的工具集成到元数据存储库中作为元数据来源。

        元数据管理工具提供了在集中位置(存储库) 管理元数据的功能。

 

四、方法

4.1 数据血缘和影响分析

       许多元数据工具中存储着某个环境中数据现况的信息, 并提供查看跨系统或应用程序接口的血缘功能。 基于程序编码的当前版本的血缘称为“实现态血缘(As Implemented Lineage) ”。 相反,映射规范文档中描述的血缘称为“设计态血缘(As Designed Lineage)。

       元数据管理系统通过可以提供数据血缘详情的工具导入“实现态血缘”, 并从无法自动抽取的“设计态血缘”文件中获取实施细节加以补充。 将数据血缘的各个部分连接起来的过程称为“拼接”, “拼接”结果是一个表示数据从原始位置(数据源或记录系统) 转移到最终位置的全景视图 

       为了成功实现业务目标, 需要计划和设计一个策略来发现和采集元数据到元数据存储库。 要想成功发现数据血缘关系, 需要兼顾业务焦点技术焦点

       1) 业务焦点。 根据业务优先级寻找数据元的血缘关系。 从目标位置回溯到具体数据起源的源系统。 通过扫描那些发生迁移、 传送或更新的数据元, 确保业务数据使用者理解特定数据元在系统间迁移时发生了什么。

       2) 技术焦点。 从源系统开始识别直接相关的数据使用者, 依次识别间接的数据使用者, 直到识别出所有系统为止。 

 

4.2 应用于大数据采集的元数据

       大部分数据管理专业人员更熟悉和适应结构化数据存储, 结构化数据的每个数据项都有清晰的定义和标记。 

       元数据标签应在采集时应用于数据, 然后元数据可以用来识别可访问的数据湖中的数据内容。 大部分采集引擎采集数据后进行数据剖析,数据剖析可以识别出数据域、 数据关系和数据质量问题, 并打上标签。采集数据时, 识别到敏感或隐私(如个人身份信息, PPI) 数据时应添加元数据标签。

 

五、实施指南

       第一个实施的是验证概念并学习管理元数据环境的试点项目。 把元数据相关项目与IT开发方法论进行整合是必要的, 因为IT的架构和存储类型不同, 这些项目也将随之变化。

5.1 就绪评估/风险评估

       评估缺失高质量元数据可能带来的影响如下:
       1) 因不正确、 不完整和不合理的假设或缺乏数据内容的知识导致错误判断。
       2) 暴露敏感数据, 使客户或员工面临风险, 影响商业信誉和导致法律纠纷。
       3) 如果了解数据的那些领域专家们离开了, 那么他们了解的知识也随之被带走了。

       组织准备情况的评估解决方法为: 

       对元数据相关活动现状进行正式的成熟度评估, 评估内容应包括重要的业务数据元、 可用的元数据术语表、 数据血缘、 数据剖析和数据质量管理过程、 主数据管理成熟度和其他方面。 评估的结果与业务优先级一致, 将为改进元数据管理实践的战略方法提供基础。 

 

5.2 组织和文化变革

       元数据管理在许多组织中是一项低优先级的工作。 一组基本的元数据需要组织中各团队的协调和承诺, 它们可能是员工身份数据、 保险单编号、 车辆识别号或产品规格的结构。

       企业数据治理战略的实现需要高级管理层的支持和参与, 要求业务人员和技术人员能够以跨职能的方式紧密合作。

 

六、元数据治理

       开展元数据治理工作以满足这些需求。 建立正式的角色和职责并分配专用资源, 特别是在大型或业务关键领域中。 

6.1 过程控制

       数据管理团队应负责定义标准和管理元数据的状态变化(通常使用工作流或协作软件) , 同时可以负责组织内的质量提升活动、 培训计划或实际培训活动

       需要将元数据战略集成到软件开发的生命周期中, 确保变更过的元数据及时得到收集, 以确保元数据保持最新。

 

6.2 元数据解决方案的文档

       元数据的主目录包括当前作用域中的源和目标。 元数据资源面向技术及业务用户, 可发布到用户社区, 并可作为“元数据在哪里”的指引,告知用户能够满足他们的以下需求:

1) 元数据管理实施状态。
2) 源和目标元数据存储。
3) 元数据更新的调度计划信息。
4) 留存和保持的版本。
5) 内容。
6) 质量声明或警告(如缺失的值) 。
7) 记录系统和其他数据源状态( 如数据内容历史加载、 删除或更新标志) 。
8) 相关的工具、 架构和人员。
8) 敏感信息和数据源的移除或脱敏策略。

 

6.3 元数据标准和指南

       在计划周期的早期采用基于行业的、 行业特有的元数据标准, 并使用这些标准评估元数据管理技术。 

       指导方针包括模板、 相关示例、 有关预期输入和更新的培训, 以及“不使用术语定义术语”等规则和完整性声明。 针对不同类型的元数据开发不同的模板, 部分由所选的元数据解决方案驱动。 持续监测指导方针的有效性和必要更新是治理责任。

 

6.4 度量指标

       元数据管理实施的有效性可以根据元数据本身的完整性、 与其关联的日常管理操作以及元数据的使用情况来度量。 

       元数据管理环境的建议指标包括:

1) 元数据存储库完整性。 将企业元数据(范围内的所有产品和实例) 的理想覆盖率与实际覆盖率进行比较。 参照元数据管理范围定义的策略。
2) 元数据管理成熟度。 根据能力成熟度模型(CMM-DMM) 的成熟度评估方法, 开发用于判断企业元数据成熟度的指标(参见第15章) 。
3) 专职人员配备。 通过专职人员的任命情况、 整个企业的专职人员覆盖范围, 以及职位描述中的角色定义说明, 来评估的组织对元数据的承诺。
4) 元数据使用情况。 可以通过存储库的访问次数衡量用户对元数据存储库的使用情况和接受程度。 在业务实践中, 用户引用元数据是一个很难跟踪的指标, 可能需要定性的调研措施获取评估结果。
5) 业务术语活动。 使用、 更新、 定义解析、 覆盖范围。
6) 主数据服务数据遵从性。 显示 SOA 解决方案中数据的重用情况。 主数据服务上的元数据帮助开发人员决定新的开发任务可以使用哪些现有服务。
7) 元数据文档质量。 一个质量指标是通过自动和手动两种方式评估元数据文档的质量。 自动评估方式包括对两个源执行冲突逻辑的比对、 测量二者匹配的程度以及随时间推移的变化趋势。 另一个度量指标是度量具有定义的属性的百分比, 以及随着时间的推移而发生变化的趋势。 手动评估方式包括基于企业质量定义进行随机或完整的调查。 质量度量表明存储库中元数据的完整性、 可靠性、 通用性等。
8) 元数据存储库可用性。 正常运行时间、 处理时间(批处理和查询) 。

“您的支持是我持续分享的动力”

微信收款码
微信
支付宝收款码
支付宝

目录关闭