大数据杂谈微课堂|大数据治理技术核心，可扩展的元数据架构设计

本文是 7 月 7 日大数据杂谈群分享的内容，讨论了什么是元数据，元数据管理的架构和应用价值，希望对大数据从业者有些许启发。

各位晚上好，很高兴能与大家分享对元数据架构与应用的一些思考。

首先简单介绍下我自己，我 2010 年加入普元，目前负责普元大数据产品部，我和我的团队主要在做大数据治理相关的产品和解决方案。在来到普元之前在人民银行软件开发中心担任核心架构师，参与了人民银行的一些大型项目的建设。

整个分享分为三个部分:

第一部分，说说我和我的团队眼中的元数据。

第二部分简单介绍如何实现元数据管理的架构。

第三部分，我将通过举例的方式，说明元数据的应用价值。

元数据是什么

元数据是信息的维度，可以说，掌握了元数据就掌握了信息的维度。

只有充分利用好元数据（也就是信息的维度），通过合理的元数据建模（维度整合），对元数据进行科学管理（维度完善），才能更好地认知信息。

那么，就可以将元数据管理看成是这些信息概念和信息本身之间的一种连接。其中信息概念表示某个业务所有维度的集合，连接则是描述元数据与元数据之间关系的方式。

元数据管理是随着数据仓库的建设逐渐完善起来的，这也决定了元数据管理主要集中在数据领域。例如数据结构、数据加工转换关系等。

而随着我们对元数据理解的不断深入，其实元数据广泛存在于企业架构的方方面面，而不仅仅局限于数据领域里。

因此，元数据管理的范围也在不断扩大，从简单的库表，到整个数据平台，再到服务管理，不断地突破传统管理的范畴，形成了广义元数据管理。

在这个过程中，对元数据的技术架构也有了新的要求，稳定可扩展的架构才是实现广义元数据管理的基础。

元数据管理的架构

要实现元数据管理有三个方面，

1. 采集：指从各种工具中，把各种类型的元数据采集进来，采集是元数据管理第一步。
2. 存储：采集之后需要相应的存储策略来对元数据进行存储，这需要在不改变存储架构的情况下扩展元数据存储的类型；
3. 管理和应用：在采集和存储完成后，对已经存储的元数据进行管理和应用。

随着元数据管理范畴的不断扩大，如何保证元数据从采集、存储到应用等关键环节的稳定和扩展，成为元数据管理架构设计的关键问题。

OMG 的模型体系规范为元数据管理提供了基础，所以整个元数据管理设计的关键应该以模型体系规范为指导。

OMG 提出的 CWM（Common Warehouse Metamodel）规范对数据仓库相关的所有模型进行了描述，在初期我们也遵照此规范设计元数据管理的架构，但是规范里也有坑，我们很快就发现了问题。

我们发现 CWM 规范本质上是针对数据仓库领域的规范，按照 OMG 的模型体系来看，模型的抽象层次还是太低

如果继续提高抽象层级，MOF 规范位于模型体系最底层，所有模型体系规范的基础都应该是 MOF（Meta Object Facility）规范，UML，CWM 都是由 MOF 扩展而来。

基于 MOF 的还有模型交换的规范 XMI，为不同元数据交换提供了很好的模型基础。

那么若整个元数据围绕 MOF 设计和扩展，不用修改元数据管理核心部分，就可以适应元数据种类的不断扩展。

下面我们来看看如何设计元数据的存储。

元模型对元数据属性及关系进行了定义，一般来讲，元模型存储有两种方式。

1. 第一种方式是将元模型转换成系统数据库表和属性，实现一对一管理存储。例如可以将主键元模型存储在主键记录表中、将存储过程元模型存储在存储过程记录表中等。
2. 另一种方式是基于 MOF 元元模型把所有属性和关系打散，以此来实现元模型的通用存储结构。

如图所示，以 CWM 模型中关系型包为例进行说明，方式一是直接将元模型转化为库表，方式二按照元元模型的方式存储元模型；

尽管第二种实现方式上复杂度会更高一些，但是在扩展性有绝对优势，是元数据管理实现的优先选择方式。

再来看看模型体系的层次结构。

和元数据有关的体系分三层，M1（元数据）、M2（元模型）、M3（元元模型），其中 MOF 元元模型中描述了包、元素、属性、命名空间和约束等对象及其关系，位于层次结构的最上层，也是最抽象的一层。

以 MOF 作为底层元元模型来支持元数据管理，在 M2 层中就可以对元模型进行定义和扩展（例如 CWM 模型），将来还可以扩展到微服务模型、业务模型等。

选定了实现方式后，一般可以通过三步来实现元数据的管理，

第一步，以 MOF 规范设计元模型存储结构，从而支持元模型的扩展。

第二步，基于 MOF 设计元模型，例如将 CWM(公共仓库元模型) 规范中定义的元模型，存储在元模型中。

第三步，按照扩展后的元模型，采集元数据，存储到元数据系统中。

在元数据管理三层管理架构的支持下，通常只需要做元模型定义和元数据采集，就对不同元数据进行管理。

例如，要将表与字段元数据采集到元数据管理系统，只需要如下两步：
首先，对元模型定义并描述元数据特征，包括类属性描述、关系的描述等；
然后，将元数据采集进来，存储到系统中；

元数据的应用价值

良好的元数据架构，能够给元数据带来更多的应用价值。我们再看看元数据的应用价值。

通过元数据管理我们能够做到：

1. 实现多样、繁杂的元数据信息集中管理，为企业数据（服务）管理提供统一的视图，实现企业级数据（服务）资产管理，方便数据（服务）交互共享，同时为后续规划提供依据；
2. 通过管理维护数据（服务）之间关系，实现数据（服务）自动关联分析，为问题定位、影响分析、上线加速等提供支撑。
3. 建立数据（服务）标准，统一交换、存储、应用口径，减少共享壁垒，降低应用出错几率，提升质量。

通过这些基本能力，元数据在数据管理、微服务管理、业务管理等方面都能发挥很大的作用。

通过元数据管理，在数据方面能做到：

1. 数据标准化；
2. 数据开放；
3. 数据质量提升等

在微服务方面，能够提供以下支撑：

1. 服务开发、应用等标准化；
2. 服务应用监控，优化服务应用等

将来在业务方面也能通过元数据实现业务流程分析、业务流程优化等能力。

下面我们用几个例子，举例说明元数据的作用。

数据治理之中，元数据是整个治理体系落地的技术核心。

比如：在数据标准中将数据标准作为一类业务元数据存储，将其和技术元数据一定程度的关联，去看标准的落地效果。

在数据质量中，通过元数据追溯质量问题。在共享发布中，利用元数据自动形成数据服务等等。

元数据还能够自动化的准确的管理应用的上线、变更， 通常企业系统建设会分为开发、测试与生产三个不同的环境，而在软件开发过程中，无论是需求变更还是 BUG 修改都避免不了元数据的改动，这时候往往会出现开发库、测试库测试通过，而在上线过程中又出现问题的情况，这会让运维部门非常头疼。

此时若通过元数据对系统的上线变更进行管理，自动采集三个环境的库表结构与存储过程等信息，保证各个环境中的元数据都是最新的、最准确的，再将上线环境与测试环境的元数据进行对比，不一致的地方一目了然。如果把系统的开发库、测试库、生产库的元数据都管理起来，上线时突然出现问题的概率就会大大降低。

通过扩展模型，元数据也能够管理微服务，微服务的生命周期有多个阶段，在前期需要与多个微服务协同考虑，上架后也会有多个使用者，在这种复杂的状况下需要管理微服务的全生命周期。

在规划阶段提供标准元数据规范微服务，在设计阶段提供连接其他微服务的元数据信息，在开发阶段使用元数据协助开发测试。

上线后分析微服务的使用情况，并协助维护微服务的变更。最后微服务下架时将微服务的元数据存档，并确保对目前体系不产生影响。

同时微服务的不同版本间的元数据的变化也可以做追溯和分析。

最后，未来元数据将是连接业务，数据与服务的企业核心基础设施，可扩展的元数据架构也能够产生更多更有价值的应用场景。

今天的分享就到这里，谢谢大家，也欢迎大家提出问题。

Q&A

Q1：谈谈您对于基于元数据驱动的自动化文档编写、ETL 设计、调度设计、测试设计、数据质量管控和业务监控的可行性、难点和思路？目前我正在设计这块的东西。

王轩：我觉得这个问题蛮好，也是我们思考很久的问题。
其中难度在于如何收集更多的元数据，同时能够用自动化的手段和工具紧密结合。

比如，ETL 设计，很多 ETL 是重复性的，如何能够通过一定规则自动生产 ETL 任务，我们有了一系列的方法，不过支持的工具的类型有限制。

比如数据质量管控，其中很明显的是能够用元数据的血统分析，获得问题数据的源头，但是这还不够，是不是能够自动形成数据质量检核方法？ 和业务元数据结合，就能够自动生成一部分检核方法。

Q2：对元模型的图看不清，能不能额外讲解下？怎么实现多表的元元模型？谢谢

王轩：其实遵照规范，是有很多表，在这里需要做一定的简化，实现需要的就可以了。

Q3：想了解一下你们用什么存储元数据？

王轩：目前用关系数据库存储，用 MOF 规范存储元数据的限制也在这里，表间关系会很复杂，这样就限制了存储的方式。但是可以在应用层用一些技术解决性能的问题。

Q4：元数据有很多上下游关系，这种场景下用关系数据库会有性能问题吗？

王轩：坦白的说，会有。 尤其在元数据管理大数据环境的时候。

元数据的数量级会增加，这样就必须要解决性能问题，我们也做了很多尝试，比如预先的汇总，预先的分析。比如，利用内存数据库缓存等。

现在也在研究用图数据库实现，但还没有加入到产品中。

Q5：王老师，您说元数据是数据治理的核心，那我想问个关于数据治理的问题，在数据治理中，数据标准是否可以通过元数据来落地？如果可以，能讲下主要思想吗？非常感谢！

王轩：数据标准的落地是一个非常复杂的问题，除了技术以外有很多管理和组织架构的因素。

我们把数据标准作为一种特殊的业务元数据存储在元数据中（利用可扩展的能力）。 数据标准中的标准项中也有每个标准建议的字段英文。

这样可以通过技术元数据的自动匹配发现与表与数据标准的不一致的地方，从而促进标准的落地进程，在很多客户那里有很好的效果。

Q6：分布式系统的环境下，如何有效的管理元数据? 元数据管理与主数据管理在实现上有什么异同点?

王轩：先回答第二部分问题，元数据和主数据是有很大不同，一个管理的是数据的定义，一个管理的是数据本身。但是也有统一的地方，都需要集中的管理。

那么前一部分问题，比如在微服务环境中的元数据是个典型的分布式系统，我们现在在新一代产品中已经有很好的管理方式，还是基于可扩展的元模型，管理更多的内容，从而实现更好的分析和应用。

Q7：目前你们是基于什么样的考量而不使用图数据库的呢？

王轩：我团队的元数据产品已经发展了 8 年，团队已经认为可以使用图数据库，后续会逐步加入，在保证产品稳定的基础上。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。