美文网首页
当我们谈元数据的时候,我们在谈什么

当我们谈元数据的时候,我们在谈什么

作者: 数据小吏 | 来源:发表于2024-01-27 22:05 被阅读0次

    我们谈元数据的时候,我们在谈什么?

    个人定义在产品上,数据管理主要集中在元数据管理的概念上,和数据治理的区别是什么?个人在数据管理和数据治理上怎么区分的,后续再详细介绍。

    同时,这里介绍的元数据主要面向开发过程,如果将元数据变成资产了,面向数据消费者,后续在数据运营篇中介绍数据地图的时候再详细说明。

    元数据基本概念

    元数据,关于数据的数据。标准解释法,如果第一次接触这个概念的话会觉得摸不着头脑。有的也会借一个例子,比如举出菜市场的例子。说是每种菜的价格、产地、生产时间等等。

    如果,让我来进行很粗略的说法,元数据就是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是在什么场景下使用那?

    以上就是个人对于数据管理-元数据部分的相关理解。

    相关文章

      网友评论

          本文标题:当我们谈元数据的时候,我们在谈什么

          本文链接:https://www.haomeiwen.com/subject/lbuiodtx.html