【数仓】数据仓库的元数据管理（三）

看了一些其他文章，有说定义的，有画图的，其中也不乏有一些很不错的文章

 

数仓系列：

【数仓】数据仓库的思考（一）：https://blog.csdn.net/lsr40/article/details/105576047

【数仓】数据仓库的建设（二）：https://blog.csdn.net/lsr40/article/details/105639190

 

但是其实没有一个统一的概念说明元数据管理的边界应该是什么，所以大家的做法会有所不同，有些元数据管理还会把数据质量模块也加入进来，有些可能是独立出来一个监控数据质量的模块，当然大家的目的都是想实现数仓的完整架构，只是各有各的方式和步骤~

 

之前看过一句话，觉得很有意思：

元数据管理其实就是解决，数据的哲学问题，我是谁，我从哪来，又要到哪去？

 

1、表的血缘分析：

表的上下游依赖关系

我们常常会不知道这张表的前后关系，由哪些表生成这张表，这张表最后又去了哪里，然后就需要从各种sql，存储过程，代码，甚至kettle等ETL工具中来找到我们想要的信息，耗时又耗力

因此如果有可以在开发的过程中就把表的上下游依赖录入到元数据管理平台中，那会方便很多

如图（虽然画的很丑）：

 

数据库存的时候：

1、通过product_id或者topic_id来区分不同链路

2、通过label字段，来标识每张表的等级（属于ods还是dwd还是dws，临时表就写tmp，维表就写dim）

3、通过order字段来标识表的先后顺序，ods层order=0，dwd层order=10，dws层order=20，以此类推，比如dwd到dws中间临时表，order就可以使用11，多张临时表就12,13往后，如果dim指向tmp表，那order就和tmp表一样，否则就和tmp叫一样order往后排就行了

4、如果存在join，需要记录是哪种join（可以用实线，虚线和箭头的方向来表示inner还是leftjoin），通过什么字段join（单独做一张表来记录如何关联，当然实在不想记录。。。也行吧）

备注：上图的title是ods，dwd，dws，dm，这是数仓基础的分层，那么如果是一个数据产品的血缘关系的话，是不是可以自定义title，同一个层的表有没有先后依赖关系，这些可能都需要实际做的时候，加入人工的思考与判断

如何自动的收集：

如果是sql的话，其实做sql解析还是做得到的，可以百度到相关的东西，使用正则，或者一些sql解析工具包啊是ok的

如果是写成代码，或者存储过程，这就比较麻烦了，一般是需要手动去填写相关信息

如果是kettle或者其他框架写好了一串流程，那么也不太好收集这部分信息，所以类似这个，是否可以自研一个调度框架来解决这个问题（大多数人使用kettle应该用的是shell，sql，写文件，发邮件等基础功能），要做一个自研的框架，并把流程写到里面应该是没什么太大问题，然后每天定时调度功能也写一下就好（当然肯定是需要版本迭代更新，提供新的功能，仁者见仁智者见智了）

 

 

2、表，字段信息管理

各种类型的数据库都会有各自的元数据信息，比如hive，我们可以通过show create table xxx，来查看一张表的建表语句

因此我们如果自己管理整条链路上的所有表的元数据，也可以通过类似的方式收集，关于如何保存这些元数据，可以参考hive的元数据库的做法！

Hive元数据信息对应MySQL数据库表：https://www.cnblogs.com/qingyunzong/p/8710356.html

举个例子，甚至可以记录每张表的count（定时count下，看表的膨胀率，可以是全量count也可以是新增分区的count，看日趋势）

可以根据不同的数据库不同的功能去新增一些字段记录更多的信息，比如greenplum中，每张表都会有distributed by(xxx)，也需要记录，又比如mysql里表有引擎的，是InnoDB还是MyISAM等等，所以也是需要根据实际用的不同数据库去微调自己的元数据记录的方式

当有新建表的需求的时候，如果可以做出一个平台，直接在平台上建表，那么元数据就可以实时更新的，但是如果是直接连接数据库操作的话，就应该定时去show tables，然后查询所有表的建表信息，然后解析之后保存到正确的表中，并且如果有已存在的非临时表的信息查询出来和上次不一样的话，应该有适当的报警！

额外说几点：

1、表或者业务线的负责人

2、记录该表的生成规则！（比如该表存了活跃的人的行为，那么如何定义这个活跃的人，应该有适当的说明甚至有样例sql）

2、字段一定要有注释，甚至有时候字段的生成规则也需要记录！（因为有些字段涉及到了计算，为了验证数据或者口径统一，就需要计算的方法，给出样例sql，并且要标明中文含义，避免同一个字段，大家的叫法不同），当然也可以不在这里记录，在专门的指标库中记录也可以

3、记录下该表数据保存周期，比如存近一年，或者近6个月这样，让大家有个概念

4、修改相关信息造成的影响（通知或者告警）：向下追溯元数据对象改变对下游的影响，是不是要发通知或者邮件给下游所有负责人

 

3、权限管理

当然既然是一个平台，就会有权限的设置，其实不就是增删改查元数据的权限吗，根据业务线开通，然后有底层人员（管理员），有数据分析人员，业务人员不同等级的权限，只要这里的元数据查看，不涉及到真实数据的查询，那权限相对没那么重要。

除非是在元数据平台中，也有预览数据的功能，那就需要查看数据之前的开通权限，并且数据展示时的脱敏操作，例如电话号码中间4位加密啊等等的一些隐私字段加密功能，那么就需要在设计表的字段信息存放的时候，给每个字段加上权限等级，以此来做数据的保密！

 

emmmm，暂时说这么多吧，主要还是要看这个元数据管理平台想做多少，简单的方法，也可以提供一个wiki，或者文档解释下相关的信息就可以，复杂的话可以做成一个大的应用服务，功能点还是蛮多的！

如果有什么还需要补充的或者各位有疑惑的，可以给我留言，相互探讨下

没啥好说的，反正努力吧，多学习，多开阔视野，多提高技术水平！