我们谈元数据的时候,我们在谈什么?
个人定义在产品上,数据管理主要集中在元数据管理的概念上,和数据治理的区别是什么?个人在数据管理和数据治理上怎么区分的,后续再详细介绍。
同时,这里介绍的元数据主要面向开发过程,如果将元数据变成资产了,面向数据消费者,后续在数据运营篇中介绍数据地图的时候再详细说明。
元数据基本概念
元数据,关于数据的数据。标准解释法,如果第一次接触这个概念的话会觉得摸不着头脑。有的也会借一个例子,比如举出菜市场的例子。说是每种菜的价格、产地、生产时间等等。
如果,让我来进行很粗略的说法,元数据就是schema信息。更进一步就是表的名字、字段、类型、描述。这样理解起来更简便,当然也更粗糙些。
这里更进一步说下,元数据有时候还会升级为数据资产,个人理解主体仍旧就元数据,元数据增加一些管理属性、业务属性,就变为数据资产了。本质上还是元数据。
🔑 我一直不理解不确定,把简单的东西复杂化是一种能力,还是复杂问题简单化是一种能力。
以元数据为中心构建数据平台
不管元数据在概念上怎么定义,作为大数据平台的产品经理都需要将概念落到实处。从整个大数据平台上说下元数据在大数据平台中的位置。一句话来说的话,整个大数据平台是以元数据为中心来构建的。
从最开始的数据集成,集成的源端、目标端需要有元数据。集成之后的数据开发过程需要元数据。开发之后创建数据服务,也需要元数据。即席查询分析需要元数据。报表展示需要元数据。可以通过元数据,将大数据平台中各个模块都串起来。所以,可以称为以元数据为中心来构建大数据平台。
元数据管理应该包含哪些数据源类型
如果简单来说元数据就是schema,而且元数据又如此重要。那么大数据平台需要管理哪些数据源的元数据那?
首先,大数据平台的一大目标是构建数据仓库,那么数据仓库对应的元数据就需要管理,不管这个数据仓库是HIVE、还是类似阿里的Maxcomputer,都需要在大数据平台进行统一管理。如果说架构中既有湖又有仓,那么湖和仓的元数据也都要统一管理。
其他类型的那,随着大数据平台的能力不断扩大,能够支持的开发类型不断增多,渐渐的也都支持其他类型的数据源。如MySQL、Oracle等等。甚至于将文本、kakfa等都在产品层面上赋予一个schema,有的在名称上称为全域的元数据管理。
有了这种对文本、kafka等没有schema结构的统一管理,也能能够支持对于没有表结构的数据源的界面化操作了。
包含的元数据管理类型越多,势必会对其他模块有影响,造成平台越复杂。如后续介绍的即席查询,是否需要能够对所有管理的元数据都进行查询?查询的时候是否需要跨源进行关联?这是需要通盘考虑的事情,倒没有好与不好之分,只要整体流畅即可。
元数据同步形式
大部分情况下元数据已经存在底层数据库上了,这个时候就需要进行同步。同步无非两种,一种离线,一种实时。
离线即为创建一个定时的调度,通过调度周期性的抓取到最新元数据。这种会有一定的更新延迟性。
实时即为监控数据库上的日志,当出现变更时,也同步变更平台上的元数据。
但不管这两种方式的哪一种,依旧不能摆脱元数据两层皮的问题。
似乎有一种和底层深度结合的方式,就是元数据直接读取底层的catlog。不会将元数据在平台再次存储。不过这个偏底层,不确定是否是我理解的这样,并且面对上文提到的全域的元数据管理时,需要怎么处理,这些个人没有做过升入的研究,需要再学习学习。
元数据创建两种形式-向导式 脚本式
除了元数据的同步之外,在大数据平台上也可以直接创建元数据。创建有两种形式,一种就是脚本形式。一种是向导的形式。
- 脚本形式
就是一个文本编辑框,在文本编辑框中编写SQL直接创建,这种形式是大部分研发喜欢的形式。符合日常的形式。但是,这种创建形式不能很好的和标准,指标,码表等绑定。
- 向导形式
除了脚本的形式,也可以使用向导的形式来创建表,使用类似表格形式来创建。这种形式需要将表的一行一行来填充、选择类型等等。操作上效率低,而且和研发人员的日常建表习惯也不一致。是不是能够使用推广,个人认为是有一定阻力的。
但是这种形式能够很好的绑定标准、指标、码表等。而且似乎只有这种形式能够将这些信息和表进行绑定。这部分将在后面“数据规划真的可行吗” 中继续介绍。
展示形式
在数据运营篇,会介绍面向运营的元数据展示开启使用数据的第一步—找到数据 ,在运营过程中展示的形式,打破了库的限制,能够更加灵活的来显示出来表信息。但是在面向开发的元数据是单独做一个元数据展示界面,这个界面形式上是库表的层级树,还是可以和面向运营的元数据使用一个。也是可以讨论的一个点。
schema on read 还是schema on writer
以上写的所有都是基于schema on writer形式的,也就是在写入数据的时候,就已经确定了schema信息了,这也是大家在日常中普遍使用的。但是,随着,数据湖的推广,越来越多出现schema on read的形式了。这种形式的核心是,schema信息不是在数据写入的时候指定,而是在读取的时候,再赋予schema信息。因为个人在现有的产品设计中,没有接触到这类的形式,所以目前对这种形式的schema在什么场景下应用,持一定的怀疑态度。后续有接触到了,再进行更新。
针对数据湖模式下的scheme on read 有一点是想不清楚的,如果我在向数据湖导入数据的时候,我是知道导入文件的结构的,那么我为什么不直接创建一张表,建立这张表和导入文件的映射关系,读取表的时候,就能够读取导入文件了,也就是直接使用schema on writer了。如果我在导入文件的时候,不知道导入文件的结构,没法建立与之映射的表,那么谁来保证,我在读的时候,就能够知道应该建立怎样的表与导入文件做对应那?也就是说scheam on read是在什么场景下使用那?
以上就是个人对于数据管理-元数据部分的相关理解。
网友评论