讲讲元数据

前言

做了一些元数据的系统，分享一些相关的理解与体会。
掺杂个人理解与实操历史，不一定是最佳实践。

元数据一般指的是 定义数据的数据。

对于一个后端系统或者大数据集群来说，基本的元数据就是在执行ddl时产生的各种库表字段等信息。

这里面都记录了当前实例或集群的大部分基础元数据，且在元数据更新时实时更新这个库。
当然还有一些元数据比如数据血缘，关联关系，热度信息，业务元数据等需要一些其他手段获得。

首先进行元数据的采集和整合。这边都以hive举例。

可能会有想法如果只是展示的话可以直接连metastore库，没必要再采集到后端，这样也不会有延时。但后期不一定会在一个集群，而且库表字段等还要有其他的各种关联数据，统计数据，因此采集到后端是比较稳妥的做法。

对于库，表，字段，分区等信息，直接使用metastore库获取。
采取定时同步的策略，按库来同步。因为同步全量时间会比较长，可以分两种定时同步：
第一种为获取表名列表对比已同步的老表，只采集新表，这样会比较快；
第二种为获取全量的表和字段结构对比，新增的做insert，修改的做update；
同时也保留一种手动触发方式，可以让用户手动同步库或表。

对于血缘，热度，关联关系等信息，目前比较直接的是使用hiveHook。
血缘hiveHook直接有LineageLogger类可以使用获取到表血缘和字段血缘。(不过这个有时候会有问题，就会比较难于排查)；热度需要sql解析出表名和字段名，对用到的都进行统计；关联关系是在查询的时候用户对表或字段进行了关联;拿到这些数据后可以直接放到一个消息队列里，然后起一个服务用来存数据和提供接口。
另一种方式：通过yarn，hook，离线任务，即时查询等的来源采集到每天运行sql，使用sql解析比如antlr4和hive自带的Hplsql.g4解析出上面这些信息，直接存储至后端，解析文件可以自行做优化。

对于业务元数据，比如表负责人，层级划分，业务划分，打标签等。
因为表字段等信息是从hive同步来的，且创表人一般都为系统账号，因此表负责人来源一个为从离线任务同步而来，另一个为从建模工具同步而来。
层级划分业务划分一般是按库名或表名的规则就可以区分开，在采集的时候就加上，后期有误的话需要人工维护。
其他一些业务元数据采取批量导出导入和页面上维护。

元数据平台一般作为数据地图，除了采集到元数据以外，还要对元数据进行校正，变更记录，使用说明，统计等。
在采集表字段等元数据时，对元数据的保留一份历史版本，可以做变更查询与报警。
在接口上实现对一些业务元数据的校正和使用说明。
定时统计元数据，展示一些元数据的全局数据，总计，top榜等。

平台界面上，除了对上述所有元数据的展示，同时也有各类元数据的统计和图表展示，还有各类的操作可以操作一些业务元数据。

除了元数据平台上的功能外，元数据也可以有其他很多的应用。
比如元数据的指标建设，将字段元数据与指标进行绑定，从而让元数据更贴近业务；
比如在控制数据权限时，需要用到表字段的策略；
比如在即时查询时用户需要查看库表字段信息来完成sql；
比如在数据监控与数据质量中，也需要用到元数据；

赏

支付宝打赏

微信打赏

赞赏一下