数据仓库详细介绍（八.元数据）

元数据的文章，往上也有很多了，而且重复度很高。我这里只是做个概念汇集，争取给大家介绍的全面一点。

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

举几个例子

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

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

数据库，每个数据库里都会有一堆的字典表，里边存储了数据库、调度、表、字段、索引、视图、函数、存储过程、每一次查询、数据库健康检查日志等等一系列数据。这些数据字典和数据库运行日志就是一个数据库的元数据，我们通过查询元数据就能了解到，数据库里存储了哪些数据、数据库的查询性能、负载、监控状况等全方位的数据库信息。

这句经典请铭记于心：数据不会自己管理自己。而我们需要通过元数据去管理他们。

行业内通常会把元数据分为四类，接下来我们逐个讲解下，力争把数据仓库涉及到的元数据全都涵盖进去。

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

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

业务元数据，在实际业务中，需要不断的进行维护且与业务方进行沟通确认。这类数据很难在元数据管理系统中体现，指标体系和标签体系，这两个还有点可能性。

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

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

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

还有两种数据，虽然不属于元数据（主数据可能更能合适些），但对于数仓至关重要：编码映射数据、统一维度数据

包含 ETL 配置和计算资源：

人员管理领域相关，包括管理流程、人员组织、角色职责、各种规范等。数据管理活动相关，比如数据质量管理、数据资产管理、安全管理、成本治理等等过程中新产生的元数据。

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

帮助数据平台了解自己本身的情况例如我有哪些数据、我存储的数据有多大、如何找到我所需要的数据、我的数据何时产出等信息。完善的元数据是我们快速掌握数仓系统的关键。

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

高效精准沟通一方面，元数据中的管理元数据会记录不同用户、角色、部门的数据权限。如果有数据需要进行通知，则可以快速查询系统进行群发邮件等方式进行沟通，从而避免了造成沟通环节的缺人和多人情况发生。另一方面，在与产品沟通业务或是与研发沟通接口时，可以根据业务元数据，确认彼此沟通的指标、维度含义。从而在根源上避免交流的歧义。进而提高沟通效率。

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

在开发中，我们经常会遇到以下问题：如果我要改动某个表、ETL，会造成怎样的影响？如若我要调整某个任务流的调度时间，会造成怎样的影响？

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

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

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

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

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

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

此处放置稽核告警链接

数据质量管理会依托数仓元数据记录的信息，同时也会产生新的元数据。具体内容，我们在“数仓数据质量”部分再详细展开。

此处放置数据质量上篇

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

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

但通常一个数仓项目，甲方看的更多的是最终的数据应用以及交付时候的文档是否完备。所以元数据通常都是分散的，甚至很多都是文档，元数据管理主要得看管理得看领导要求，挺难的。

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

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

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

模型设计落地阶段，我们产生物理模型元数据。元数据存储介质是模型设计文档。或者数据库的元数据。ETL 设计开发阶段，我们产生 ETL 映射文档、ETL 流程依赖、数据血缘元数据。元数据存储介质是 ETL 设计文档。

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

时过境迁，随着互联网时代的普及，大多数看重数据的公司都会组件自己的数仓团队，市面上做数据的公司也大多是 Saas 型的，就算还是私有化项目制部署大多也都是现有自己的产品，也都会有成熟的数据采集、存储、展现工具，附带的也会有数据治理工具、数据资产管理工具等等，可以说已经很完善了。

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

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

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

我们可以有一个系统，通过系统创建表，提交的时候会做校验（表字段命名是否符合规范是否存在于词根库、是否有备注、表的一些属性所属主题域所属分层）

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

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

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

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

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

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

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

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

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

如果没有元数据工具生产，就只能人肉录入了，但数据质量就不好说了。

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

](https://mp.weixin.qq.com/s/Wu8TegQSsht6GBT6wPJKBw)