引言
元数据管理是企业数据治理的基础，是数据仓库的提升；作为一名数据人，首要任务就是理解元数据管理。本篇文章将为大家梳理元数据的概念，介绍元数据管理在数据仓库的地位。
什么是数据仓库的元数据管理
什么是元数据
元数据（Metadata），又称中介数据、中继数据，为描述数据
的数据（data about data）。
抽象的描述：一组用于描述数据的数据组，该数据组的一切信息都描述了该数据的某方面特征，则该数据组即可被称为元数据。
举几个简单例子:
- 如果一本书是一个“数据"，那么它的书名、封面、出版社、作者、总页码就是它的“元数据”。
- 如果一个电影是一个“数据”，那么它的总时长、制作人、总导演、演员列表就是它的“元数据”。
- 如果数据库中某个表是一个”数据”，那么它的列名、列类型、列长度、表注释就是它的"元数据"。
只要有一类"事物"，就可以定义它的“元数据”。
大多数时候，元数据可以根据代表意义的不同分为业务元数据和技术元数据。
什么是数据仓库
数据仓库 ，由数据仓库之父比尔·恩门（Bill Inmon）于 1990 年提出，主要功能仍是将组织透过资讯系统之联机事务处理（OLTP）经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，做有系统的分析整理，以利各种分析方法如联机分析处理、数据挖掘（Data Mining）之进行，并进而支持如决策支持系统（DSS）、主管资讯系统（EIS）之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助建构商业智能（BI）。
什么是数据仓库的元数据管理
数仓中的元数据，主要记录各主题的定义、不同层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。一般会通过元数据资料库来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。元数据是数据仓库管理系统的重要组成部分，元数据管理是企业级数据仓库中的关键组件，贯穿数据仓库构建的整个过程，直接影响着数据仓库的构建、使用和维护。
为什么数据仓库要进行元数据管理
建设数据仓库所必须
数据仓库是由外部数据、业务数据以及文档资料通过某些 ETL 工具得到的，如果没有一个明确、清晰的规则，根本不可能实现这个过程。
帮助快速理解数仓系统
一方面，数据仓库本质上是一个部门甚至一个公司的重要项目，开发时间冗长。中间不可避免的会产生人员流动，如果没有清楚的元数据，那会对整个系统乃和整个项目造成重大影响；
另一方面，数据仓库做为整个部门、公司的分析数据出口，并不仅仅对数据人员服务； DM 层对业务人员， DIM 对其他开发人员都是不可避免的。如果有清楚的元数据来说明数仓系统，就会节约双方大量的沟通时间。
高效精准沟通
一方面，元数据中的管理元数据会记录不同用户、角色、部门的数据权限。如果有数据需要进行通知，则可以快速查询系统进行群发邮件等方式进行沟通，从而避免了造成沟通环节的缺人和多人情况发生。
另一方面，在与产品沟通业务或是与研发沟通接口时，可以根据业务元数据，确认彼此沟通的指标、维度含义。从而在根源上避免交流的歧义。进而提高沟通效率。
保证数据质量
理想的元数据做到了对数据仓库结构的描述，仓库模式试图，维，度量，层次结构，到处数据库的定义，以及数据集市的位置和内容。
因此，我们可以很确定的判断哪些数据是肯定准确无误的、哪些数据是可能有问题的、哪些数据是肯定有问题的。
简单的说就是每一个字段都应该有它的取值范围、业务定义等信息，元数据定义好了自然就可以应用到数据质量检测、评估等方面，进而通过数据质量管理流程真正提高企业的数据质量。
降低数据系统建设成本
假如元数据建设完备，所以取得信息会更准确快捷，使数据系统建设不返工或少返工，减少分析工作量，加强各方的统一理解以及沟通效率，进而使开发成本最小；
快速分析变更影响
因元数据被集中维护并管理引用关系，当发生变更时，可以通过元数据管理系统以实时分析出其所影响的业务功能、应用系统、涉及人员、是否涉及监管等影响信息；
为未来做好准备
大数据、人工智能、数据湖、数据中台、商业智能等企业的战略级应用系统能够依赖良好的元数据管理而发挥出其应有的效果。
数仓中元数据的组成
元数据贯穿整个数据仓库，根据情况可以分为三种：业务元数据、技术元数据和管理元数据。
业务元数据
业务元数据主要描述 ”数据”背后的业务含义；从业务角度描述业务领域的相关概念、关系——包括业务术语和业务规则。
- 主题定义：每段 ETL、表背后的归属业务主题。
- 业务描述：每段代码实现的具体业务逻辑。
- 标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。
- 标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。
业务元数据，在实际业务中，需要不断的进行维护且与业务方进行沟通确认。
技术元数据
指技术细节相关的概念、关系和规则，包括对数据结构、数据处理方面的描述。以及数据仓库、ETL、前端展现等技术细节的信息。
数据仓库中的技术元数据一般包含以下 4 大系统：数据源元数据；ETL 元数据；数据仓库元数据；BI 元数据。
-
数据源元数据
例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。
-
ETL 元数据
根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。
-
数据清洗元数据
数据清洗，主要目的是为了解决掉脏数据及规范数据格式；
因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。
-
数据处理元数据
数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。
源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
-
-
数据仓库元数据
数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；
业务系统、数据仓库和数据集市的体系结构和模式等。
-
BI 元数据
汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。
管理元数据
管理领域相关，包括管理流程、人员组织、角色职责等。
也有很多观点建议将 管理元数据拆分融入 业务元数据和技术元数据中。
如何建设数仓元数据管理
任何系统的元数据管理建设都是十分艰难的，数据仓库更是如此；但另一方面，这个建设过程又是非常重要的。我们暂以 CWM 标准作为数据仓库的元数据标准参考，在实际建设中进行借鉴，这样看起来更专业。
CWM （CommonWarehouseMetamodel公共仓库元模型）是 OMG 组织在数据仓库系统中定义了一套完整的元模型体系结构，用于数据仓库构建和应用的元数据建模。公共仓库元模型指定的接口,可用于启用交换仓库之间元数据仓库和业务智能工具、仓库平台、应用的元数据建模和仓库元数据存储在分布式异构环境 CWM 元模型由一系列子元模型构成。
由于 CWM 制定时间是 2001 年，且过于细节深入，因此笔者认为其更适合作为开发参考而非开发标准。
由于元数据包含极广，我们在建立元数据管理系统的时候，绝对不能盲目追求大而全、一步到位，要坚持目标驱动的原则，在实施的时候要采取增量式、渐进式的建设原则。具体的建设步骤如下：
- 在建设数据仓库系统的初期，只需确定源系统的元数据构成和 数仓我们想要实现的元数据内容：比如，我们只想通过元数据来管理数据仓库中数据的转换过程，以及有关数据的抽取路线，以使数据仓库开发和使用人员明白仓库中数据的整个历史过程。
- 确定源系统和元数据构成后，先将源系统的元数据整理并记录，可以用文档记录；也可以存入关系型数据库中。
- 随着数据仓库系统的建设，逐步将需要的元数据补充录入——例如 DM 的语义层、ETL 的同步规则；
- 数据仓库建设完成后，对元数据进行结构化、标准化储存。
总之，建立元数据管理系统一定要坚持关注标准，又不被标准所束缚的原则，建立符合自身目标的元数据管理系统。
元数据的应用场景
影响分析
在开发中，我们经常会遇到以下问题：
如果我要改动某个表、ETL，会造成怎样的影响？
如果没有元数据，那我们可能需要遍历所有的脚本、数据。才能得到想要的答案；而如果有成熟的元数据管理，那我们就可以直接得到答案，节省大量时间。
血缘分析
血缘分析是一种技术手段，用于对数据处理过程的全面追踪，从而找到某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。元数据对象之间的关系特指表示这些元数据对象的数据流输入输出关系。
在元数据管理系统成型后，我们便可以通过血缘分析来对数据仓库中的数据健康、数据分布、集中度、数据热度等进行分析。
血缘分析是 data science 非常重要的应用，未来笔者会单独展开介绍。
ETL 自动化管理
在数仓中，很大一部分 ETL 都是枯燥重复的步骤。
例如源系统-ODS 层的：表输入——表输出。
又比如 ODS-DW：SQL 输入——数据清洗——数据处理——表输出。
以上的规则其实就属于一部分元数据。
那理论上完全可以实现，写好固定脚本，然后通过前端选择——或 api 接口。
进而对重复的 ETL 实现自动化管理，降低 ETL 开发的时间成本。
数据质量管理
数据清洗的逻辑，简单的说可以分为不同的数据类型和指定的特殊处理列。
我们只需指定不同数据类型的默认清洗规则，和部分特殊列的特殊处理逻辑，即可实现智能快捷的数据清洗。
数据质量管理，属于 数据治理 与 元数据管理 交集，更偏向数据治理方面。未来也会展开更详细介绍。
数据安全管理
在阿里推崇的数据中台中，一切数据接口指标，都会从数据仓库中出口。因此理论上，我们只需在此处的元数据中对管理元数据的权限进行配置，即可实现全公司的数据安全管理。
常见的元数据管理系统
apache atlas
Apache Atlas 是 Apache 基金会的孵化项目，是 Hadoop生态圈的数据治理和元数据框架。Atlas 是一套核心基础治理服务的集合，有很好的伸缩性和可扩展性，能够满足企业对 Hadoop生态系统的多样性需求，并能和企业的数据生态系统集成。
它为 Hadoop 集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。
但 atlas 的缺点是：只能对 hadoop 的元数据进行管理（虽然也是连的 Mysql ），对传统数据库的支持力度非常小；同时血缘分析也只支持特定的数据库。
wherehows
Wherehows 定位于元数据仓库,元数据存储于 mysql 中，它从不同的源系统中采集元数据，并进行标准化和建模，从而作为元数据仓库完成血缘分析。由 linkedin 开源。支持 Docker 部署。
优势：
- 支持元数据历史版本及对比分析。
- 一站式的元数据分析管理系统。
劣势：
- 支持的源系统比较少
- 开源版本仅支持 Azkaban 调度任务的血缘分析。其他调度任务仅能获得元数据信息，而没有血缘信息。
- 血缘分析较粗，不支持列级血缘。如 HDFS 仅能显示数据文件之间的血缘。
- Web UI 仅提供查询能力，相关配置需要调用 API 接口。
- 缺乏用户、权限管理能力。
这个工具最大的问题是 开发不完善，准确的说，笔者还未看到有人安装成功过。
其他
元数据管理系统的建设，对整个公司都有着非常高的需求，因此其他系统会很难找。而收费的例如 informatica 等产品，又很难拿到实际 demo 来测试。
其他杂谈
元数据管理系统，是对一家公司数据更高的考验，想要搭建成功，至少满足以下条件：
- 整个公司数据的集成——数据仓库的搭建
- 整个公司业务流程的完善——"业务中台"的实现
- 整个公司技术开发的统一——"技术中台"的实现
如果说数据仓库是数据的集成，那元数据管理系统就是整个公司业务、技术、管理的统一。
从这个角度来看，元数据管理系统的定位是高于数据仓库的，这也是笔者虽然标题是《数据仓库的“元数据管理”》，但花了大量篇幅在介绍元数据的原因。
阿里所推崇的数据中台，理念上比较接近 数据仓库+元数据管理。
但换个角度，任何业务、技术、数据的规范过程，短时间内都会对实际工作造成负面的影响。不是所有人都能理解规范化所带来的优点，这里也需要一定权衡和反复的沟通。
用 ETL 的开发举一个例子。
- 全部用 SQL 解决——开发很快，结果也很少出错。但未来可能要读一个上千行的 SQL。
- 全部用 python 解决——开发、维护的代码门槛较高，且性能相比 SQL 相差何止百倍
- python 来调度 SQL ——笔者较为推崇的方法，将处理逻辑变为 python 的函数、类，但底层逻辑使用 SQL 实现。从而达到一个相对平衡的角度
因此，笔者认为，无论是数据人员还是 IT 开发、测试甚至产品项目业务，都应有元数据的概念，记录有价值的元数据，利己利人。如果最终决定进行元数据管理系统的建设，也会节约大量时间。