元数据新型存储架构的探索_元数据存储方案-CSDN博客

补充：

1.物理表结构稳定版本数据治理

元数据驱动数据存储学习总结笔记_Revivedsun的专栏-CSDN博客1 背景日常后台业务开发都会涉及到数据存储问题。每个需求建立新的存储模型并进行开发是常用的手段。随着需求量增多，思考后也会看到一些共性。在数据存储层面。通过有效的抽象，提炼模型，提高系统开发效率。「元数据驱动的 SaaS 架构技术思考」这篇文章文章讲了通过标准加扩展能力保证数据安全，并支持多租户共性及个性问题构建SaaS产品实现对不同业务模式支持，提供更高效的开发能力。2 常见业务开发模式通常基于贫血模型开发，分析完需求，创建数据表，随后开发数据表的CRUD服务。数据表通常是和需求中的定义完全对应https://blog.csdn.net/Revivedsun/article/details/113481838

2.实践curdapi

crudapi 增删改查接口crudapi是crud+api组合，表示增删改查接口，是一款零代码（低代码，0代码，low code，无代码）可配置的产品。使用crudapi可以告别枯燥无味的增删改查代码，让您更加专注业务，节约大量成本，从而提高工作效率。crudapi的目标是让处理数据变得更简单，所有人都可以免费使用！无需编程，通过配置自动生成crud增删改查RESTful API，提供后台UI管理业务数据。基于主流的开源框架，拥有自主知识产权，支持二次开发。crudapi curdapi crduapi crdu curd crud cud crdhttps://crudapi.cn/ 3.数据治理之元数据管理实践

数据治理之元数据管理实践_ITPUB博客http://blog.itpub.net/31562043/viewspace-2675935/4.美团

美团配送数据治理实践 - 美团技术团队大数据时代的到来，让越来越多的企业意识到数据资产的价值。但是如果企业在走向数字化过程中遗忘了数据治理，可能再多的投入都会变成一种“徒劳”。https://tech.meituan.com/2020/03/12/delivery-data-governance.html5.数据治理--元数据

数据治理--元数据 | AppZone元数据是对某个潜在信息性对象做出的陈述。在浏览其他网页的时候会看到元数据被称之为 “数据的数据”。为了更好的描述元数据到底是什么东西，我以一本《Metadata》书作为例子进行说明。《Metadata》第二页记录着该书的 CIP 信息、作者、出版社、书号、定价、印次、字数等信息，而这些信息都是用于描述《Metadata》这本书的元数据。一条元数据记录就是关于一个资源的主谓宾陈述集合。例如：达芬奇https://zoeminghong.github.io/2020/02/08/%E6%95%B0%E6%8D%AE%E6%B2%BB%E7%90%86%E5%85%83%E6%95%B0%E6%8D%AE/

6.peopleo的基础

PeopleSoft基础知识整理 - Poborsky - 博客园1.关于四种ID：User ID登陆PS系统使用的IDAccess ID关系数据库超级管理员ID，通常具有所有数据库权限，用户登陆后使用此ID连接数据库，由PS系统维护安全性，一般只用一个Symbolhttps://www.cnblogs.com/kgb250/archive/2012/09/17/2679873.html PeopleSoft精华之生效日期在PeopleSoft的应用中，生效日期(EFFDT)贯穿始终，成为数据模型中管理带时间线对象的利器。它言简意赅却又威力无比。https://mp.weixin.qq.com/s/6kzpFPLmYwDGMQ3X0rrccA

7.云上数据治理整体方案：

方案概述_应用与数据集成平台 ROMA Connect_最佳实践_企业数据以API形式开放共享_华为云随着信息化技术的不断发展，企业的业务系统越来越多，各业务系统间需要进行数据的互联互通，以提升企业的运作效率。如何实现企业内新老业务系统之间的数据安全互通，甚至是跨企业业务系统的数据安全互通，成为企业越来越重视的问题。随着企业的跨区域发展，企业的业务系统也随之部署到各区域子公司中，总公司与各区域子公司的业务系统间需要时常进行业务交互。若不同https://support.huaweicloud.com/bestpractice-roma/roma_05_0012.html

引言：

一个软件产品存储架构是需要仔细斟酌和考虑的事情，既要保持稳定性也要保持跟上主流技术的发展趋势。元数据产品从最初主要支持关系型的数据管理到现在的大数据平台、数据湖、微服务这种新的数据架构形态的管理。原有的存储架构从分析元数据关系效率、检索速度都不能满足应用的需求了。

目录：

一、国内主流元数据产品发展现状

二、当前元数据存储架构存在的问题

三、新型存储架构的探索

四、新型存储架构的应用

五、新型存储架构的优点

一、国内主流元数据产品发展现状

国内主流的元数据产品主要有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、元数据节点示例：