我们谈元数据的时候，我们在谈什么？

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

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

元数据基本概念

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

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

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