元数据新型存储架构的探索
转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：
一个软件产品存储架构是需要仔细斟酌和考虑的事情，既要保持稳定性也要保持跟上主流技术的发展趋势。元数据产品从最初主要支持关系型的数据管理到现在的大数据平台、数据湖、微服务这种新的数据架构形态的管理。原有的存储架构从分析元数据关系效率、检索速度都不能满足应用的需求了。
目录：
一、国内主流元数据产品发展现状
二、当前元数据存储架构存在的问题
三、新型存储架构的探索
四、新型存储架构的应用
五、新型存储架构的优点
一、国内主流元数据产品发展现状
国内主流的元数据产品主要有MetaCube、MetaOne、MetaManager等，基本上都采用了遵循MOF规范，设计了可扩展的元数据存储架构。这种存储架构的特征就是，以元模型管理为基础，元模型是描述元数据的元数据。你可以把元数据当做一种特殊的数据，要存储这种特殊的数据，需要事先定义它的结构。就和我们管理学生的数据一样，要先定义学生数据模型。如下图:
元模型设计有两种方式:
第一种方式如上左图所示，要管理那些元数据事先就定义好它的元模型，比如要管理字段这种元数据，我就定义字段都包括那些属性，比如字段英文名称、字段名称、字段类型、字段长度、精度等。然后按照字段的属性，建一张表专门存储字段这种元数据。
第二种方式，就是基于MOF的元模型设计，定义一系列的管理元模型的模型，就是元元模型。如上右图，这里面有类表、类属性表、类组合关系和类继承关系等等，这些就是元元模型。采用这种方式就解决了模型稳定性的问题，还带了很灵活的扩展性。当一个组织要增加一种新的元数据管理时，只需要通过元模型管理的功能，定义好元数据的属性（包含属性与元数据存储表字段映射关系）。元数据采集适配器按照模型的定义，把元数据存储到表。使用的时候，在按照元模型的定义把表里的元数据转义出来，展现到页面上。
二、当前元数据存储架构存在的问题
方式一：按照要管理的元数据类型一对一建表
如果要建一个元数据管理系统，只管理字段元数据，那就只需要建这一张表就可以了。但是一个组织里要管理元数据有很多，按照第一种方式，就需要不断的新增加表，以管理更多的元数据。这样就严重破坏了模型的稳定性。一般很少有人采用这种方式。
方式二：通过元模型管理定义元数据的属性
这种方式的缺点就是，违背了Java面向对象的编程思想，程序处理逻辑复杂，需要编写大量的自定义SQL来实现元数据的管理。如下图所示查询元数据基本信息的逻辑。除了元数据公共属性instance_id(ID),instance_name(名称),instance_code（编码）,parent_id（父ID）,classifier_id（元数据类型）,namespace（上下文命名空间）外，还有fileld这个动态属性，是需要在java程序中动态拼接的。如下图所示：
再来看下T_MD_INSTANCE表的结构，如下图，我们发现里面有大量STRING_1、STRING_2 .....STRING_40的字段。设置40个扩展字段，不会全部用到，用到的代表什么含义由元模型来决定。
以字段元数据来举例，要知道STRING_8这个字段代表什么含义，需要从元模型表、元模型属性表和元模型属性映射表来解读。
在显示一个元数据的基本信息的时候，需要通过至少4张表才能显示出来。
三、新型存储架构的探索
说到元数据存储架构，有人会很自认想到有分布存储分散管理，分布式存储集中管理、统一存储集中管理之分。这种属于宏观的存储架构，我们不展开讨论。这里是在统一存储集中管理的假设下来讨论元数据微观的存储架构。
我们把元数据管理系统的表划分为三类：
- 一类是元数据系统管理表例如元模型管理表之类的。这类数据（例如元元数据）量不大，但对元数据管理很重要。
- 一类是元数据的应用表例如元数据关联关系等，元数据中的血缘分析、影响分析和数据地图的数据就是来源于这里。有点类似与人的社交网络分析。这个需要对海量的元数据进行分析，并将关系存储起来。
- 一类元数据的事实表；即通过元数据采集适配器采集到来的原始的元数据。这类元数据可读性很差，是不能拿给用户直接来使用的。其显著的特点是数据量大，为了保持其时效性，需要按照一定频率进行更新。
对元数据管理系统的三类表的特点有了了解后，我们在来分析要使用那种存储架构
显然第一类数据，要用关系型数据库比较合适，数据量不大，单一致性的要求比较强。例如开源的Mysql,如果在配合redis内存数据库，那就更好了。
第二类数据，关联关系的存储，比较推荐图数据库，例如Neo4j。之前使用过关系型数据库对这类数据进行存储。在关系比较复杂的情况下，检索的速度比较慢。因为这是一个类似与网状的关系图。要检索的数据呈几何倍数的增长。
第三类数据，元数据事实表，采用非关系型数据库存储能够较好满足其特点。推荐使用HBase作为元数据存储层。
四、新型存储架构的应用
关键应用一：
用HBase数据库存储元数据对象Hbase元数据实例表的设计，要注意两点：
- 一是要区分元数据不变属性和可变属性的区分。不变属性是指每一类元数据都固有属性。例如code、name、path可变属性：是根据元数据类型的不同而发生变化的属性。例如表类型的元数据和字段类型的元数据，可变属性是不一样的。例如字段含有的属性例如字段类型、字段长度等这些属性在表类型的元数据中是没有的。
- 二是：rowkey的设计，在这里我们选择将元数据code+元数据类型+元数据路径这三项数据进行MD5加密生成的字符串作为元数据的ID，而不是随机生成的字符串作为元数据ID，是为了保证进入到元数据存储库的元数据ID都是唯一的，不会出现重复的问题。而这个ID将作为元数据rowkey。
正是因为不同类型的元数据属性差异很大，而Hbase数据库字段是可以扩展的，为实现不同元数据的统一一张表提供了可操作性。
1.1 在HBase插入元数据示例：
1.2 元数据的修改，也是通过Put操作完成。这里不展开说明。
1.3 元数据的删除
为了能够快速的检索到符合条件的记录。我们这里还会涉及一张索引表，通过元数据code、元数据名称、元数据类型、元数据路径，索引到相应的RowID,来快速查询元数据详情信息。
关键应用二:
用图数据库来存储关联关系,图数据库中的节点、属性、关系和label四类基本概念，而元数据的图形展现出来也是节点、关系、节点基本属性和关系的基本属性。我在这里把Node4j和元数据关系的存储做了示例。没有把node4j集成到项目中，当然网上有Spring Data Neo4j和Node4j数据库集成的示例，可以轻松的把Node4j和java项目结合在一起。由于时间的问题，我没有做测试。只是使用单独的Node4j数据库做了元数据关系存储的验证。
2.1、元数据节点示例：
2.2 在图数据库上操作
五、新型存储架构的优点
通过新型存储架构，将元数据系统用到的表进行分类存储，发挥不同数据库的优势，从而提升元数据管理系统的查询、展现效率。
- 优点1：解决了关系型数据库表的预留字段的限制。
- 优点2：降低了程序实现的复杂度。
- 优点3：提升了数据的查询、展现效率。
精选提问：
问1：如果用非关系型数据库存储元数据，那元数据管理的上层，即构建血缘分析、影响分析、数据地图等功能模块时，会不会受影响？这些功能都需要各个元数据的互相关联才能进行。
答：元数据管理的上层，即构建血缘分析、影响分析、数据地图等功能这些功能需要跟着调整的。因为元数据存储的介质已经发生变化了，连接方式也不同。但前端展现影响不大。
问2：Netflix Metacat 和元数据管理平台区别是什么呢？
答：这个工具没有对元数据集中存储，大多数据元数据仍分散在各个系统/工具中，只存储了业务和用户定义的元数据。Metacube是将各类元数据都进行了集中管理和存储的。
问3：在数仓建设的基础上，能否举一个元数据应用的场景？
答：典型的应用场景是数仓的运维了，通过元数据管理数仓的元数据对象及关联关系。构建可视化的数据链路。
问4：主数据实施与元数据的关系？
答：主数据项目实施与元数据不是强关联关系。如果对主数据模型要求很高，可以引入元数据工具，能够解决主数据模型的版本、变更管理的需求。
问5：比如某应用系统现在采用传统存储方式，想要改为使用元数据存储，是否有这种场景，场景转换的瓶颈是什么？
答：这个问题，我的理解是某系统使用的关系型数据库存储的元数据，现在要迁移到新的元数据存储架构上。这种场景是有的，我们现在做的新的存储架构的探索就是为了进行底层存储架构的迁移。转换的瓶颈基本上是主要功能的重新开发了，需要对新的存储架构比较了解。
问6：元数据是一个很广泛的概念。包含技术元数据、业务元数据、操作元数据。麻烦老师讲下具体的含义与区别？
答：技术元数据、业务元数据和操作元数据是DAMA对元数据划分，其实还有管理元数据的说法。从我个人理解，其实划分界限不是很严格的，技术元数据中其实也包括了业务元数据。例如字段 name，中文含义是姓名，这个元数据就是技术、业务元数据的结合体。
关于作者：刘庆会，普元云计算和大数据产品部架构师，主要负责普元大数据治理产品研发和项目实施，十年大型企业信息数据治理架构设计与建设经验，为多家大型金融机构、企业设计与规划数据管理整体框架和项目实施。数据行业有着深入的研究和洞察，并对企业信息化平台建设，数据治理及大数据平台建设有着丰富经验。