元数据通用查询的初步设计

这是学习笔记的第 1797篇文章

在建设运维平台的时候，其中的一个重中之重就是元数据建设，数据库方向的元数据设计是分为了多个维度，有主机，实例，集群，数据库等。

从无到有的过程会发现元数据的建设的第一大优点就是统一集中的方式，统一能够减少很多数据不一致的入口，在这个过程中也需要做反反复复的稽核。

第二个优点就是数据管理的入口更加清晰了，以前梳理的数据恨不得所有数据都在一行里面，有了指定的数据维度，整个过程就会变得体系化，哪些数据到哪个表中，哪些关系需要特意维护等。

这样确实也带来了一些便利，然后就是一系列问题了。

首先带来的问题是元数据的不一致。元数据能够录入，但是修改的时候流程化是不足的，从开始设计的时候就是迭代的思路，所以每一个维度都有一个专门的入口，比如实例管理，主机管理，集群管理等。每个入口都有具备增删改查的权限。从开始权限上就做了收缩，能够添加，有限的修改，但是不能随意删除，但是显然在后期的维护中是存在问题的，元数据既然存在就势必会有变化的可能，而这种变更的比例相对来说是比较低的，从不同的入口去变更可能对其他维度的数据会造成不一致的结果。

第二个是数据冗余带来的数据问题，不同的维度中，为了避免数据反复引用，所以会刻意做一些冗余设计，这种冗余设计就会带来一些数据不一致的潜在隐患。

比如实例的信息在集群层面会体现出来，但是很可能一些补充的字段在实例和集群中都存在，最开始录入数据的时候会觉得这是一种很赞的设计方法，但是数据发生变化之后不能够联动，就会造成很多困扰。

举个例子，我们从最开始到现在迭代了多个版本，最后元数据的部分有了多个入口，虽然从数据的联系上是可以从任意一个维度来串联起来的，但是显然不会有人这么做。

我收集了同事使用元数据的一些应用场景和出发点，最后发现，大家使用实例管理的需求最强烈，需求强烈到其他的入口都几乎被忽略了。

而且从后期的数据稽核工作中发现了很多细小的问题，如果元数据经不起推敲，那么大家对它就会失去信赖，后续就不会以它作为数据的基础参考，这样一来，元数据所能发挥的意义就很有限了。

所以我觉得既然大家对于实例管理的需求这么强，那么我们可以按照实例维度来重点建设，元数据通用查询的工作就摆上了日程。

另外实例管理有一个缺点就是我们虽然使用实例管理的需求强烈，但是很多查询场景是基于IP维度来查询的，所以我们查询的的维度其实是主机维度，信息的展示是实例维度。那么我们可以吸取这些特点，设计的demo就可以简化一些。

然后在这些维度中，把已有的各个维度的数据统一展示出来，其实元数据的部分没有做什么变化，但是数据变得更加有条理，更加清晰了。