大数据治理系列：实施元数据管理

元模型（Metamodel）

模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型（Metamodel）也就是模型的模型（或者元-元数据），是用来描述元数据的模型。

实施元数据管理

在明确了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。比如可以使用 IBM InfoSphere Business Glossary 进行业务元数据的管理，使用 IBM InfoSphere Metadata Workbench 作为元数据管理统一工具并进行图形化的元数据分析。

大数据扩大了数据的容量、速度和多样性，给元数据管理带来了新的挑战。在构建关系型数据仓库、动态数据仓库和关系型数据中心时进行元数据管理，有助于保证数据被正确地使用、重用并满足各种规定。同样，对大数据来说，元数据管理过程中出现的任何错误，都会导致数据重复、数据质量差和无法访问关键信息等问题 。随着大数据技术在企业中的应用越来越广泛，企业需要在原有的元数据管理策略中增加大数据相关的内容。通常，大数据分析是受用例驱动的，企业可以通过梳理大数据用例的方式逐步完善大数据的元数据管理。

针对大数据的业务元数据，依旧可以通过构建基础本体、领域本体、任务本体和应用本体等 的方式来实现。通过构建基础本体，实现对级别且通用的概念以及概念之间关系的描述；通过构建领域本体，实现对于领域的定义，并确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解；通过构建任务本体，实现任务元素及其之间关系的规范说明或详细说明；通过构建应用本体，实现对特定应用的概念描述，其是依赖于特定领域和任务的。这样就通过构建各种本体，在整个企业范围提供一个完整的共享词汇表，保证每个元数据元素在信 息供应链中每个组件的语义上保持一致，实现是语义等效。

为了实现信息供应链中各个组件元数据的交互和集成，大数据平台的元数据集成体系结构 依然可以采用基于模型驱动的中央辐射式元数据体系结构。对大数据平台中的结构化数据的元数据管理可以遵循公共仓库元模型（CWM）构建元数据体系结构，以便方便的实现各个组件间元数据的交互；对大数据平台中的半结构化和非结构化数据的元数据管理，因为业内还没有通用的公共元模型，企业可以尝试采用基于自定义模型驱动的方式构建中央辐射式元数据体系结构。

简单来说，企业可以尝试以下步骤进行大数据的元数据管理：

考虑到企业可以获取数据的容量和多样性，应该创建一个体现关键大数据业务术语的业务定义词库（本体），该业务定义词库不仅仅包含结构化数据，还可以将半结构化和非结构化数据纳入其中。

及时跟进和理解各种大数据技术中的元数据，提供对其连续、及时地支持，比如 MPP 数据库、流计算引擎、Apache hadoop/企业级 Hadoop、NoSQL 数据库以及各种数据治理工具如审计/安全工具、信息生命周期管理工具等。

对业务术语中的敏感大数据进行标记和分类，并执行相应的大数据隐私政策。

将业务元数据和技术元数据进行链接，可以通过操作元数据（如流计算或 ETL 工具所生成的数据）监测大数据的流动；可以通过数据世系分析（血缘分析）在整个信息供应链中实现数据的正向追溯或逆向追溯，了解数据都经历了哪些变化，查 看字段在信息供应链各组件间转换是否正确等；可以通过影响分析可以了解具体某个字段的变更会对信息供应链中其他组件中的字段造成哪些影响等。

扩展企业现有的元数据管理角色，以适应大数据治理的需要，比如可以扩充数据治理管理者、元数据管理者、数据主管、数据架构师以及数据科学家的职责，加入大数据治理的相关内容。

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

图 1. 元数据管理成熟度模型

根据元数据管理的成熟度，大体可以分成 6 个级别，具体如图 1 所示：

L0: 初始状态

元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用，其他人如果想获得该元数据需要找到相应的人进行沟通获取。

L1: 从属于业务系统

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

L2：元数据统一存储

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

L3: 元数据集中管理

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

L4：元模型驱动管理

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

L5: 元数据管理自动化

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