数据治理系列2：元数据管理—企业数据治理的基础

Posted 2021-12-13 浊酒南街

目录

• • 导读：
  • 认识元数据
  • 元数据的分类
  • 元数据管理成熟度
  • 元数据管理价值

导读：

元数据管理是对企业涉及的业务元数据、技术元数据、管理元数据进行盘点、集成和管理，按照科学、有效的机制对元数据进行管理，并面向开发人员、最终用户提供元数据服务，以满足用户的业务需求，对企业业务系统和数据分析平台的开发、维护过程提供支持。元数据管理是企业数据治理的基础。

认识元数据

元数据(Metadata)，元数据是关于数据的组织、数据域及其关系的信息，简言之，元数据就是描述数据的数据。这么说对于没有技术背景的人来说还是比较抽象的，我给大家举几个例子。

在我之前写的一篇文章《关于“数据”的一些概念的整理和总结》中，有一个关于元数据的例子，歌曲《小芳》中有一段台词：“村里有个姑娘叫小芳，长得好看又善良” 这首耳熟能详的歌，我们分析一下，姓名：小芳、性别：姑娘（女）、长相：好看、性格：善良，住址：村里。这里面，小芳是被描述的对象也就是我们所谓的实体数据，而姓名、性别、长相、性格、住址就是描述“小芳”的元数据。

再举个栗子：元数据就像“户口本”，户口本中除了有姓名、出生日期、住址、民族等信息外，还有家庭的血缘关系，父子关系、兄弟关系等。这些信息就构成了对这个人的详细描述，那这些信息就是描述这个人的元数据。

再举个栗子：元数据好比“字典”，针对每个字都注音、含义、组词、举例等信息，同时也有关于字体结构、相关引用、出处等。另外，我们可以通过拼音、偏旁部首都能查到这个字。所有的这些信息都是对这个字的详细描述，那这些信息就是描述这个字的元数据。

再举个栗子：元数据就如“地图”，通过这张“地图”能够找到你所处的地点，以及你从哪来来，到哪里去，途中都需要路过哪些地方……

这下大家理解了吧，元数据是对数据的结构化描述，使得数据更容易理解、查找、管理和使用。

元数据的分类

根据数据的性质特点，业内一般将元数据划分为三类：业务元数据、技术元数据和管理元数据。

业务元数据是描述数据的业务含义、业务规则等。通过明确业务元数据让人们更容易理解和使用业务元数据，元数据消除了数据二义性，让人们对数据有一致的认证，避免“各说自话”，进而为数据分析和应用提供支撑。常见的业务元数据包括：业务定义、业务术语、业务规则、业务指标等。

技术元数据是对数据的结构化，方便计算机或数据库之间对数据进行识别、存储、传输和交换。技术元数据可以服务于开发人员，让开发人员对数据的存储、结构更明确，从而为应用的开发和系统的集成奠定基础。技术元数据也可服务于业务人员，通过元数据理清数据关系，让业务人员能够更快速的找到想要的数据，进而对数据的来源去向进行分析，支持数据血缘追溯和影响分析。常见的技术元数据包括：存储位置、数据模型、数据库表、字段长度、字段类型、ETL脚本、SQL脚本、接口程序、数据关系等。

管理元数据描述了数据的管理属性，包括管理部门、管理责任人等，通过明确管理属性，有利于数据管理责任到部门和个人，是数据安全管理的基础。常见的管理元数据包括：数据所有者、数据质量定责、数据安全等级等。

表：元数据分类实例

元数据类型	元数据描述	元数据实例
业务定义	数据的含义	客户的完整名称，并具有法律效力
业务规则	数据录入规则	企业的营业执照、组织机构代码证书，统一社会信用代码证书等具有法律效力的证明文件中的中文名称全称
	识别规则	企业的组织机构代码或者统一社会信用代码或者统一纳税号必须完全匹配，则认为是同一客户。
	质量规则	客户名称为非空，并且与营业执照的中文名称一致
存储位置	数据的存储什么地方	ERP系统
数据库表	存储数据的库表名称和路径	ERP/Customers
字段类型	数据的技术类型	字符型
字段长度	数据存储的最大长度	[200]
更新频率	数据的更新频率	每年更新一次
管理部门	数据责任部门	客户管理部
管理责任人	数据责任部门	客户管理部业务员

元数据管理成熟度

在实施元数据管理的过程中，可以参照元数据管理的成熟度模型确定企业当前元数据管理所在层次，并根据业务需要制定路线图实现元数据管理水平的提升。下图是元数据管理成熟度模型：

元数据管理成熟度评估模型

L0: 初始状态

元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用。在局部环境工作数月或数年后，人们使这些元数据以及对它的理解内在化，使对这种信息有习惯性的理解。这些元数据会永远保存在某个人那儿，一旦这个人调离，这些元数据将永远消失。

L1: 从属于业务系统

在这个阶段，随着各个业务系统自动化构建完成，相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中，技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中，元数据之间互通互联困难，如果需要获取其他系统的元数据，除了调阅各种文档外，对分散在各种中间件和业务系统中的技术元数据需要一定的集成方式实现互通互联。

L2：元数据统一存储

元数据依然在局部产生和获取，但会集中到中央存储库进行存储，业务元数据会手工录入到中央存储库中，技术元数据分散在文档中的部分也通过手工录入到中央存储库中，而散落在各个中间件和业务系统中的技术元数据则通过数据集成的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建，使得元数据在整个企业层面可被感知和搜索，极大地方便了企业获取和查找元数据。缺点是，元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的事情，而同一件事情则使用了多个不同的名字，有些没有纳入业务系统管理的元数据则容易缺失。元数据没有有效的权限管理，局部元数据更改后也不自动通知其他人。

L3: 元数据集中管理

在 L2 的基础上做了改进，增强了元数据的集中控制，局部业务单元或开发小组如不事先通知其他人，将无法对元数据进行修改。局部元数据的修改完成后将被广播给其他人。和其他中间件和应用系统的交互，仍然通过桥集成的方式进行，中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。

L4：元模型驱动管理

在 L3 的基础上，通过构建元模型以及元元模型，优化各业务单元之间的各种冲突和各种副本，创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构，用以对业务术语归类。和其他中间件和应用系统的交换，通过基于 CWM 的适配器方式进行连接。

L5: 元数据管理自动化

在 L5 元数据管理是高度自动化的，当逻辑层次元数据变更时，会被传播到物理层次，同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流，以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统（元模型），他们之间的关系可以通过知识本体进行推断，因此各个应用系统之间的数据格式的映射自动产生。

元数据管理平台架构

元数据管理平台从应用层面，可以分类：元数据采集服务，应用开发支持服务，元数据访问服务、元数据管理服务和元数据分析服务。

元数据采集服务

在数据治理项目中，通常涉及到的元数据还包括：数据源的元数据，数据加工处理过程的元数据，数据仓库或数据主题库的元数据，数据应用层的元数据，数据接口服务的元数据等等。元数据采集服务提供各类适配器满足以上各类元数据的采集，并将元数据整合处理后统一存储于中央元数据仓库，实现元数据的统一管理。这个过程中，数据采集适配器十分重要，元数据采集要能够适配各种DB、各类ETL、各类DW和Report产品，同时还需要适配各类结构化或半结构化数据源。目前市场上的主流元数据产品还没有哪一家能做到“万能适配”，都需要在实际应用过程中做或多或少的定制化开发。

元模型驱动的设计与开发

通过元数据管理平台实现对应用的逻辑模型、物理模型、UI模型等各类元模型管理，支撑应用的设计和开发。应用开发的元模型有三个状态，分别是：设计态的元数据模型，通常由ERWin、PowerDesigner的等设计工具产生。测试态的元数据模型，通常是关系型数据：Oracle、DB2、mysql、Teradata等，或非关系型数据库：MongDB、HBase、Hive、Hadoop等。生产态的元模型，本质上与测试态元数据差异不大。通过元数据平台对应用开发三种状态的统一管理和对比分析，能够有效降低元数据变更带来的风险，为下游ODS、DW的数据应用提供支撑。另外，基于元数据的MDD（代码生成服务），可以通过模型（元数据）完成业务对象元数据到UI元数据的关联和转换，自动生成相关代码，表单界面，减少了开发人员的设计和编码量，提升应用和服务的开发效率。

元数据管理服务

市场上主流的元数据管理产品，基本都包括：元数据查询、元模型管理、元数据维护、元数据版本管理、元数据对比分析、元数据适配器、元数据同步管理、元数据生命周期管理等功能。此类功能，各家产品大同小异，此处不再赘述。

元数据访问服务

元数据访问服务是元数据管理软件提供的元数据访问的接口服务，一般支持REST或Webservice等接口协议。通过元数据访问服务支持企业元数据的共享，是企业数据治理的基础。

元数据分析服务

血缘分析：是告诉你数据来自哪里，都经过了哪些加工。其价值在于当发现数据问题时可以通过数据的血缘关系，追根溯源，快速地定位到问题数据的来源和加工过程，减少数据问题排查分析的时间和难度。这个功能常用于数据分析发现数据问题时，快速定位和找到数据问题的原因。

影响分析：是告诉你数据都去了哪里，经过了哪些加工。其价值在于当发现数据问题时可以通过数据的关联关系，向下追踪，快速找到都哪些应用或数据库使用了这个数据，从而避免或降低数据问题带来的更大的影响。这个功能常用于数据源的元数据变更对下游ETL、ODS、DW等应用应用的影响分析。

冷热度分析：是告诉你哪些数据是企业常用数据，哪些数据属于“僵死数据”。其价值在于让数据活跃程度可视化，让企业中的业务人员、管理人员都能够清晰的看到数据的活跃程度，以便更好的驾驭数据，激活或处置“僵死数据”，从而为实现数据的自助式分析提供支撑。

关联度分析：是告诉你数据和其他数据的关系以及它们的关系是怎样建立的。关联度分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，从而进一步了解该实体的重要程度，如：表与ETL 程序、表与分析应用、表与其他表的关联情况等。本功能可以用来支撑需求变更的影响评估。

数据资产地图：是告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。通过元数据可以对企业数据进行完整的梳理、采集和整合，从而形成企业完整的数据资产地图。数据资产地图支持以拓扑图的形式进行可视化展示各类元数据和数据处理过程，通过不同层次的图形展现粒度控制，满足业务上不同应用场景的数据查询和辅助分析需要。

元数据管理价值

一图在手，天下我有

通过元数据以企业全局视角对企业各业务域的数据资产进行盘点，实现企业数据资源的统一梳理和盘查，有助于发现分布在不同系统、位置或个人电脑的数据，让隐匿的数据显性化。数据地图包括了数据资源的基本信息，存储位置信息、数据结构信息、各数据之间关系信息，数据和人之间的关系信息，数据使用情况信息等，使数据资源信息详细、统一、透明，降低“找数据”的沟通成本，为数据的使用和大数据挖掘提供支撑。

追根溯源，发现数据问题本质

企业在做数据分析的时候，数据分析结果不正确，原因可能是数据分析过程出现数据问题，也可能是数据源本身就有问题，还可能是数据在加工处理过程中出现了数据问题……。通过元数据血缘分析，能够快速定位数据来源和加工处理过程，能够帮助数据分析人员快速定位数据问题。另外，通过元数据血缘关系分析，可以理解不同数据指标间的关系，分析产生指标的数据源头波动情况带来的影响。

模型驱动，敏捷开发

基于元数据模型的数据应用规划、设计和开发是企业数据应用的一个高级阶段。当企业元数据管理达到一定水平（实现自动化管理的时候），企业中各类数据实体模型、数据关系模型、数据服务模型、数据应用模型的元数据统一在元数据平台进行管理，并自动更新数据间的关联关系。基于元数据、可扩展的MDA，才是快速满足企业数据应用个性化定制需求的最好解决方案。通过将大量的业务进行模型抽象，使用元数据进行业务描述，并通过相应的模型驱动引擎在运行时驱动，使用高度抽象的领域业务模型作为构件，完成代码转换，动态生成相关代码，降低开发成本，应对复杂需求变更。

总结：

元数据是企业数据资源的应用字典和操作指南，元数据管理有利于统一数据口径、标明数据方位、分析数据关系、管理数据变更，为企业级的数据战略规划、数据模型设计、数据标准管理、主数据管理、数据质量管理、数据安全管理以及数据的全生命周期管理提供支持，是企业实现数据自服务、推动企业数据化运营的可行路线。企业以元数据为抓手进行数据治理，帮助企业更好地对数据资产进行管理，理清数据之间的关系，实现精准高效的分析和决策。
————————————————
原文链接：https://blog.csdn.net/kuangfeng88588/article/details/90180285