元数据新型存储架构的探索

1个月前

新型存储架构,将元数据系统用到的表进行分类存储,发挥不同数据库的优势,从而提升元数据管理系统的查询、展现效率。

转载本文需注明出处:微信公众号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:提升了数据的查询、展现效率。


关于作者:刘庆会,普元云计算和大数据产品部架构师,主要负责普元大数据治理产品研发和项目实施,十年大型企业信息数据治理架构设计与建设经验,为多家大型金融机构、企业设计与规划数据管理整体框架和项目实施。数据行业有着深入的研究和洞察,并对企业信息化平台建设,数据治理及大数据平台建设有着丰富经验。


关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。