数据仓库详细介绍之元数据

本文目录CONTENTS

☞ 元数据定义

☞ 元数据分类

☞ 元数据价值

☞ 元数据应用

☞ 项目制场景下的元数据管理

☞ 规范化的元数据管理

元数据的文章，网上已经有很多了，元数据相关概念有限所以重复度很高。

本文将相关概念汇集，争取给大家介绍的全面一点。

1. 元数据定义

元数据（Meta-data）是描述数据的数据（The data about data），更准确点应该叫 The information abut data。如何理解这句话？就是描述信息、实体、系统的数据。

举几个例子

175，大家有概念吗？如果我说这是一个男孩儿的身高大家是不是就懂了。如果我再加一个他才 14 岁信息量是不是更大了？因此：数据+元数据(描述数据的数据)=信息。

遥控器，上边一堆按键如果没有文字说明大概率是没人会用的。我们只有通过按键上的标记+使用说明书这些遥控器的元数据，才能够很快的了解其功能并学会使用。

数据库，每个数据库里都会有一堆的字典表，里边存储了数据库、表、字段、索引、视图、函数、存储过程、存储位置，也会有记录许多日志比如每一次的查询日志、数据库各种运行日志等。这些数据字典和数据库运行日志就是一个数据库的元数据，我们通过查询元数据就能了解到数据库里存储了哪些数据、数据库的查询性能、负载、健康状况等全方位的数据库信息。

数据不会自己管理自己，需要通过元数据去管理他们。

详见：一文读懂元数据的概念、分类及作用

2. 元数据分类

行业内通常会把元数据分为四类，但我习惯把操作元数据归为技术元数据，所以事实上是分为三类。接下来我们逐个讲解下，力争把数据仓库涉及到的元数据全都涵盖进去。

2.1 业务元数据

广义来讲，所有用于描述业务各种逻辑的信息都可称为 Business Metadata。

这包括但不仅仅限于如下信息：

商业术语：Business Glossary, 包括名词和详细定义。

术语分类：Taxonomies，对于上述的商业术语的逻辑归类，可构成 Glossary Tree。

业务规则：Business Rule。

业务流程：Business Process，包括Activity, Input, Output, Supplier, Consumer, 等等。

业务元数据，在实际业务中，需要不断的进行维护且与业务方进行沟通确认。但这类数据很难在元数据管理系统中体现。

2.2 技术元数据

广义来讲，所有在计算机系统中的各类数据的描述均可称为 Technology Metadata

这里我把操作类的比如各种日志也都归为技术元数据了，大家按个人理解也可以单列出来。

数据仓库中的技术元数据一般包含以下五类：

数据源元数据

存储元数据

计算元数据

调度元数据

数据应用元数据

2.2.1 数据源元数据

数据源的 IP、端口、数据库类型。

数据获取的方式，是抽取还是推送，是文件还是直连数据。

数据存储的结构，关系表还是 Json，以及各列的定义。

2.2.2 存储元数据

包含物理模型和物理存储：

表/列的详细信息（名称、备注、存储位置等），这是最最重要的数据资产。

存储资源总量、使用情况、增长情况、空闲等。

如果有视图、索引、存储过程、函数的也要算进来。

主题域划分、总线矩阵、词根库等等。

表、视图等的使用情况。

还有两种数据，虽然不属于元数据（规范点讲应该算作主数据），但对于数仓至关重要：编码映射数据、统一维度数据

2.2.3 计算元数据

包含 ETL 配置和计算资源：

ETL 任务流定义，多少条任务流、用途是啥、所属层级。

ETL 流程依赖，这个至关重要，后续的数据流转和数据血缘都依赖于此。

计算资源总量、使用情况、空闲等。

代码部署位置，比如服务器位置、文件目录结构等。

运行日志，记录了 ETL 运行的关键信息。

2.2.4 调度元数据

调度时机、调度日志、以及可能会有的任务依赖。

调度系统本身部署和运行所需其它信息。

2.2.5 应用元数据

应用列表、最晚出数时间、BI 模型和物理模型的映射关系等等。

指标/标签定义（名称、口径），当然这个归到业务元数据也能说的通。

各个应用的使用情况（谁什么时候使用了什么）。

2.4 管理元数据

人员管理领域相关，包括管理流程、人员组织、角色职责、各种规范等。

数据管理活动相关，比如数据质量管理、数据资产管理、安全管理、成本治理等等过程中新产生的元数据。

3. 元数据价值

数据仓库的元数据，是对数据仓库所有环节（数据源、集成同步、存储、计算、数据管理、数据应用等等）沉淀下来的数据的描述性信息和过程日志信息，我们梳理数据资产、查找和使用数据、评估数据质量、了解数仓健康状况、成本治理等等都会首先从数仓元数据入手。

帮助数据平台了解自己本身的情况

例如我有哪些数据、我存储的数据有多大、如何找到我所需要的数据、我的数据何时产出等信息。完善的元数据是我们快速掌握数仓系统的关键。

自动化监控告警

我们根据对元数据的分析，可以自动化的获取数仓运行状况、评估模型和 ETL 代码的规范度、识别源数据变更、监控存储和计算资源的负载等等。

高效精准沟通

一方面，元数据中的管理元数据会记录不同用户、角色、部门的数据权限。如果有数据需要进行通知，则可以快速查询系统进行群发邮件等方式进行沟通，从而避免了造成沟通环节的缺人和多人情况发生。

另一方面，在与产品沟通业务或是与研发沟通接口时，可以根据业务元数据，确认彼此沟通的指标、维度含义。从而在根源上避免交流的歧义。进而提高沟通效率。

快速分析变更影响

因元数据被集中维护并管理引用关系，当发生变更时，可以通过元数据管理系统以实时分析出其所影响的业务功能、应用系统、涉及人员、是否涉及监管等影响信息。

4. 元数据应用 4.1 影响分析

在开发中，我们经常会遇到以下问题：

如果我要改动某个表或 ETL任务会造成怎样的影响？如若我要调整某个任务流的调度时间又会造成怎样的影响？

如果没有元数据，那我们可能需要遍历所有的脚本和数据才能得到想要的答案；而如果有成熟的元数据管理，那我们就可以直接得到答案节省大量时间。

4.2 血缘分析

血缘分析是一种技术手段，用于对数据处理过程的全面追踪，从而找到某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。元数据对象之间的关系特指表示这些元数据对象的数据流输入输出关系。

在元数据管理系统成型后，我们便可以通过血缘分析来对数据仓库中的数据健康、数据分布、集中度、数据热度等进行分析。

4.3 数据地图

可以对数仓内的数据有一个宏观整体的认识：总项目数、总表数、占用存储量、存储趋势图、项目占用存储 Top、表占用存储 Top、热门表等等。

可以检索查找我们需要的数据：查找表结构表描述、查找表血缘、查找表权限、查找表的使用情况。

详见：什么是数据仓库元数据？什么是数据地图？

4.4 自动化监控告警

我们可以通过对各种元数据的分析，比如数据源元数据、ETL 运行日志、数据质量稽核日志、模型设计代码开发规范规范等，去自动识别问题，然后第一时间触发告警，以便尽早的解决问题。

4.5 数据质量管理

数据质量管理依托数仓元数据，同时也会产生新的元数据。

详见：数据仓库之数据质量建设方案

5. 项目制场景下的元数据管理

元数据管理，我们不必拘泥于形式，结合生产实际够用即可。

另外，上文中的元数据分类，个人感觉实际生产中并不会刻意参考，我们通常会根据数仓建设的流程去归类，不同环节产生不同的元数据。

实际上做项目的场景，甲方关注最多的是最终的数据应用以及交付时候的文档是否完备。甲方都不关心乙方更不会去专门梳理元数据了。所以元数据通常都是分散的，甚至很多都是文档，元数据管理主要依靠数仓规范，依靠领导的监督，挺难的。

源数据分析阶段，我们会产出数据源元数据，记录数据源有哪几个、数据如何访问如何采集、采集的内容有哪些、同步加载策略和时机是什么等等。元数据存储介质是文档。

需求分析阶段，我们会产生最终应用相关的元数据，比如多少张报表、每张报表有多少维度多少指标、报表的展现形式、筛选条件、排序规则、指标口径等等。元数据存储介质是文档。

模型设计落地阶段，我们产生物理模型元数据。元数据存储介质是模型设计文档，或者数据库的元数据。

ETL 设计开发阶段，我们产生 ETL 映射文档、ETL 流程依赖、数据血缘元数据。元数据存储介质是 ETL 设计文档。

上线运行阶段，我们还会产生任务调度、任务运行日志、存储空间使用情况、数据质量校验等元数据。元数据存储介质是日志文件或者数据库或者调度系统元数据。

6. 规范化的元数据管理

时过境迁，随着互联网时代的普及，大多数看重数据的公司都会组建自己的数据，市面上做数据的公司也大多是 Saas 模式，就算还用私有化的方式部署也都会有成熟的数据采集、存储、展现工具，附带的也会有数据治理工具、数据资产管理工具等等。

既然有了这么多完善的工具了，那么元数据管理自然而然的也会规范很多，接下来我们逐个阐述。

6.1 元数据生产

成熟的数仓应该会有完善的开发、检查、调度、数据管理等工具，元数据的生产也应该是通过工具沉淀，而不能像项目制那种只能依靠管理手段强制落文档了。

工具的好处，除了自动记录元数据外，还有规则校验的功能这在很大程度上降低了出错的概率。

6.1.1 建模工具

我们可以有一个系统，用来做模型设计，提交的时候会做校验（表字段命名是否符合规范是否存在于词根库、是否有备注、表的一些属性所属主题域所属分层等是否已指定）

如果没有这个系统的话，那么就需要有个程序定期检测数据存储的元数据，发现问题及时上报解决，确保元数据生产环节的准确、完整、合规。

6.1.2 指标/标签系统

首先会有个相对稳定的分类体系，所有指标或标签必须先在该系统注册并且挂靠到已有的分类体系下。然后定义好必要的属性，比如中英文名称、计算口径等等。

指标体系的属性模板

标签体系的属性参考

6.1.3 数据开发工具

数据开发工具，也可以是个 ETL 工具或者 shell 脚本+调度系统。

我们需要实现如下功能：数据计算、运行日志记录、参数传递、代码格式化和规范性校验、任务依赖配置。

数据计算的代码通常会是 SQL 语句，该工具记录下来的信息，就是完整的 ETL 元数据，另外我们可以通过解析 SQL 自动生成数据血缘。

6.1.4 调度配置工具

数据开发完成后，我们需要将任务流装载到调度工具里，调度工具会记录调度元数据，同时调度任务执行日志也可以当作 ETL 运行日志。

6.1.5 数据质量工具

我们通过数据质量工具，配置稽核校验规则，对关键数据进行卡点校验，而这些校验程序运行日志和运行结果都会成为数据质量元数据。

具体的数据质量工具设计思路，我会在下一篇做介绍。

6.2 元数据采集

元数据采集，就是定期将 6.1 提到的元数据生产工具产生的各种元数据搜集汇总起来，为下一步的管理和应用做准备。

如果没有元数据生产工具，就只能人肉录入了，但数据质量很难保证。

6.3 元数据管理

元数据管理的目的，一个是检查元数据生产环节的数据质量发现遗漏或者错误及时纠正，另一个就是对元数据做进一步分析转化，以便监控数据仓库整体的运转情况，同时为各种元数据应用提供数据支撑。