数据治理实战——元数据管理

一、元数据概述

1.1 定义

描述数据的数据，本质还是数据。数据本身带有的技术属性与其在业务运行中的业务属性，称其为元数据，例如：表数据量，占用空间，字段信息，业务描述，负责人，优先级等。

1.2 作用

元数据通过全局统一的数据描述信息及系统化管理，统一数据标准，促进数据集成与共享，打通企业内部数据孤岛，提升数据管理和应用效率。

二、元数据分类

元数据的边界范围及其划分方式，尚未有统一标准。不同行业划分的类别可能会有差异。目前常见元数据分类包括：技术元数据、业务元数据、操作元数据、管理元数据、行为元数据、运营元数据、服务元数据。每个分类下面还有繁多的属性，但是究其本质，可以将元数据根据属性来源划分为两类：

数据本身的特定属性，为技术元数据；
业务赋予的可变属性，为业务元数据；

2.1 技术元数据

技术元数据不可手动编辑，自动获取。 技术元数据一方面服务于开发人员，帮助明确数据存储，结构，权限等信息，为数据开发和系统集成奠定基础。另一方面。技术元数据服务与业务人员，通过数据血缘厘清数据关系，定位业务流程，辅助业务开展。

技术元数据的属性主要包括以下内容：

1）基础信息

表的schema信息以及字段信息等，包含以下字段：库名称，库类型、表名称、表数量、表注释、表分区字段、表分区数量、字段名称、字段类型、字段长度、字段注释、字段默认值、主键信息、外键信息、索引信息等。

2）存储信息

本地存储中的文件信息，包含以下字段：文件路径、文件数量，文件大小，文件类型，压缩格式等。

3）调度信息

离线与实时任务中的信息，包含以下字段：任务名称，任务类型，任务路径，调度时间，调度SQL，调度逻辑等。

4）血缘信息

数据加工流转过程产生的数据与数据之间的关系，包含以下内容：数据节点，流程节点，中间节点，流入节点，节点属性等。

2.2 业务元数据

业务元数据是业务赋予，手动登记。通过明确业务属性，统一数据的业务含义，保持团队认知一致，进而为数据分析和应用更好的提供支撑。

业务元数据的属性主要包括以下内容：

1）业务信息

业务描述，业务部门，业务系统，负责人等

2）标准化信息

用于统一认知，消除歧义，包含以下字段：指标名称，指标层级，指标口径，维度信息，计算方式，映射信息，转换规则等。

3）数据质量信息

针对当前数据进行的质量监控内容，包含以下字段：质量监控名称，监控内容，监控级别，监控规则，告警方式等。

4）权限信息

访问权限，角色权限，用户权限，安全等级等。

5）服务信息

当前数据对外提供服务的方式，包含以下字段：服务方式（接口，报表，sdk等），服务内容，接口信息，负责人等。

三、为什么需要元数据

3.1 数据定位模糊，理解困难

数据开发过程中，常常会迷失在底层海量数据中，无法快速定位目前所需数据。定位到数据后，还需花费大量时间理解当前数据，理解渠道包括但不限于：询问同事、查看数据详情、查询数据权限、查看底层存储、定位影响分析等。综上所述，在使用数据时，往往需要花费大量时间去定位并理解当前数据。

3.2 数据管理能力低下

数据管理能力是企业实现数据资产化的重要前提。业务快速发展，数据量成指数级递增。与此同时却没有一个有效的管理手段，数据散落在各地，存储成本与适用成本上升，导致企业数字化转型，数据化运营无法顺利开展。

3.3 数据孤岛各自为战，标准不一

数据部门的职责之一是汇集各数据，进行集中管理。在此过程中会发现各来源方的数据标准不一，规则混乱，且存在重复建设，部门间互相割裂，都有对数据独到的理解与使用，此时数据孤岛便产生了。出现此情况的原因在于部门间各自为战，缺少统一的元数据管理对数据标准，业务含义等进行同步，从而统一认知，避免数据孤岛的出现。

数据孤岛也成为数据烟囱，不论是“烟囱”还是孤岛，总要有“破局”的时候。

3.4 集成度底，东奔西跑

开发过程中，需要切换各个开发工具进行数据查看与操作。例如通过数据库工具提交SQL操作，通过DolphinScheduler进行任务调度，通过Kafka进行管道操作等。在多个开发工具中定位与操作数据，过程较为繁琐。如果能够打通多个平台，将信息集中展示并且统一操作入口，可以使开发更加高效。

3.5 数据依赖混乱

大数据开发作为数据汇集与数据服务提供方，庞大的数据与混乱的数据依赖导致的管理成本与使用成本飙升。

3.6 数据治理推动困难

数据治理工作涉及范围较广且是一个持续不断的过程。治理需要多个部门，全流程打通。而数据治理的开展，操作，过程把控，结果验证，需要一个统一的元数据管理平台进行辅助。

四、元数据可以做什么

4.1 快速定位，理解数据

通过全文检索以及分类筛选，快速定位目前所需数据，并根据已有元数据信息进行理解。

4.2 数据血缘，流程定位，追踪溯源

数据血缘是在数据的加工，流程过程产生的数据与数据之间的关系。通过构建数据血缘，进行数据关系探查，用于跟踪数据流经路径，追踪溯源。

4.3 统一管理，赋能业务

通过元数据管理平台，赋能与数据开发与业务使用，加速企业数字化转型。

4.4 打通孤岛，对齐认知，统一标准

梳理并登记各业务部门的元数据信息并进行同步。快速对齐各部门的数据认知，统一标准，消除歧义，避免数据重复建设的情况。

4.5 数据集成，快速开发

打通各类开发组件，并且通过元数据管理平台，以数据视角触发各类操作，例如表级调度，权限修改，Schema信息修改，提交SQL任务等。

4.6 推动数据治理

通过元数据管理平台，串联数据链路中的开发人员，管理人员与业务人员，打通多部门，全流程。推动开展数据治理，把控过程，结果验证。

五、元数据管理的落地方式

目前业内常见的元数据管理落地方式，主要有以下三种：

5.1 采用开源系统

常见的开源系统有Metacat、Datahub、Atlas等。采用开源系统最大的优点是投入成本较低，但是缺点主要包括：

适配性较差，开源方案无法完全匹配公司现有痛点；
二开成本高，需要根据开源版本进行定制化开发；

5.2 厂商收费平台

例如亿信华辰，DataPipeline等。此类数据平台中会内置元数据管理系统，功能较为全面，使用方便。但是同样也有以下缺点：

价格昂贵；
需要ALL IN平台，为保障数据血缘的使用，数据业务需要全部迁移到厂商平台中；

5.3 自建

通过设计元模型，构建采集器，后端，前端自建元数据管理系统，此方案开发投入较大，但是有以下优点：

因地制宜，可根据核心痛点定制化开发元数据以及数据血缘系统。
技术积累，对于开发人员来说，从0-1开发数据血缘系统，可以更深刻的理解数据业务。
平台解耦，独立于数据平台之外，数据血缘的开发不会对正常业务造成影响。

六、元数据管理落地实施

6.1 挖掘痛点，推动实施

首先很多公司因为数据量少，团队规模小，没有体会到数据管理混乱带来的困扰，也就没有元数据管理的建设需求。其次因为公司没有元数据建设经验，上级部门不重视等原因所以也无法进行元数据的落地实施。

因此在元数据管理的建设之前，需要深度挖掘当前数据开发与业务推进中的数据管理痛点，并且通过自身的专业能力推广元数据管理的优势，进而推动落地实施。

开发人员自身能够意识到元数据管理的重要性还远远不足，在实施层面还要引起上级重视，推动部门协作，不能闭门造车。

6.2 明确需求，确定边界

进行元数据管理构建之前，需要进行需求调研，明确系统主要功能，从而确定元数据模型的最细粒度，元数据采集的边界范围，系统的应用方式等。根据上文阐述的【二、元数据分类】可以得出，元数据中属性信息众多，在开发时如果将所有属性信息都进行获取且登记，一方面开发成本较大，其次实施过程也较为繁琐。

因此前期需要明确需求，确定系统主要功能以及元数据采集的边界，后续才可以根据业务痛点给出更加准确的解决方案，提高ROI（投入产出比）。

在系统设计阶段，收集了目前痛点以及梳理现有系统以及组件后，明确系统初期建设时的三个核心业务：

数据定位、展示、快速理解。
数据血缘，流程定位，追踪溯源
数据集成，快速开发

所以在初期开发时，可以只针对以上业务进行元数据信息的采集与登记，后续根据迭代需求进行扩展。

6.3 元数据建模

元数据本质上也是数据，开发时需要对其进行数据建模。元数据模型成为元模型。一个统一的元模型可以规范元数据的范围边界，统一元数据格式与存储方式。目前数据领域存在多种类型的数据库系统，例如：

关系型数据库：Mysql、Oracle
MapReduce数据库：Hive
键-值模型数据库：Redis
列族模型数据库：HBase
文档模型数据库：MongoDB
图模型数据库：Neo4j、Nebula Graph
搜索引擎：Elasticsearch
MPP数据库：Greenplum、Doris、StarRocks

各类数据库都有其独特的存储模型与适用场景，但在元数据层面，所有数据都需要统一的元模型，无论数据库是关系行的，还是非关系型的。在元数据层面他们都代表一个个数据实体。

元数据建模一般采用E-R模型，将元数据抽象为 "实体"（Entity）、"属性"（Property）、“关系”（Relationship）来表示元数据各属性以及不同层级之间的关系。

元数据信息的保存采用结构化数据库即可，例如可以采用Mysql保存元数据信息。数据血缘信息采用Neo4j图数据库存储。

6.4 元数据采集

元数据采集算是元数据管理的开发难点，也是最难推进的。首先需要打通各数据组件的采集技术元数据，这是技术难点。其次需要数据开发与使用人员配合进行业务元数据的登记，这是管理难点。

6.4.1 自动化采集【技术元数据】

如果想要真正做一个数据集成度高的元数据管理系统，在目前大数据繁多的组件下，需要打通的组件包括但不限于：

中间件：Kafka、RabbitMq、RockitMq等
数据库：Hive、Kudu、Hbase、Mysql、Doris、StarRocks、Greenplum、ElasticSearch、PostgreSQL等、
调度系统：DolphinScheduler、AirFlow、Oozie等、
底层存储：HDFS、AWS S3 等
计算引擎：Flink、Spark、Impala等
BI报表：Tableau、Superset等

目前团队已打通组件列表如下：

通过JDBC打通Impala获取Hive与Kudu的库表基础信息；
通过文件方式打通Tableau获取中所有报表以及自定义SQL信息；
通过SDK方式打通HDFS获取存储信息；
通过API方式打通DolphinScheduler获取当前表的调度信息以及抽取SQL；
通过SDK方式打通Kafka获取当前表的来源Topic相关信息；
通过API方式获取Spark任务的执行信息和状态；

6.4.2 手动登记【业务元数据】

由于企业缺乏统一的数据标准，数据孤岛现象明显，所以即使采集到技术元数据，也只是方便开发人员进行开发与运维，无法做到真正的统一管理。

此时需要采用人工方式对现有数据进行梳理并登记业务元数据，以实现统一管理。但是在登记过程中，往往会出现很多问题，例如数据标准不一致、业务含义不清晰，相关人员不配合等情况，上述问题主要由于企业忽视数据管理所导致。

所以元数据管理落地之前，需要挖掘目前数据管理的痛点，并且在公司内部推动元数据管理的落地实施，这样才能更好的推动数据的梳理与登记。

6.5 构建数据血缘

待补充~

6.6 管理系统开发

元数据管理系统的功能应包括但不限于以下几点：

元数据概览：展示当前系统纳管的元数据概览，可以从元数据来源组件或项目类别查看。
元数据检索：通过全文检索以及分类筛选的方式，快速定位目前所需的元数据信息。
元数据详情展示：展示当前元数据详情信息，包括技术元数据与业务元数据。
元数据编辑：用于登记业务元数据，并进行更新修改。
数据血缘展示操作：用于前端展示数据血缘信息，并点选操作。
元数据采集管理：用于管理元数据采集的组件连接信息

6.7 元数据驱动

团队目前落地元数据管理后，带来的改进有以下几点：

6.7.1 数据集成开发

通过元数据打通调度系统、中间件、数据库操作等，实现数据的集成式开发，提高开发效率。

6.7.2 元数据查询、定位、展示

通过元数据管理系统定位数据并展示，大大提升数据共享能力，数据部门人来人往的现状得到改善，咨询数据的消息也大幅减少。

6.7.3 推动数据与业务梳理

建设元数据的过程中，通过推动各部门间进行数据梳理，将原先混乱的数据及业务进行整体排查，减少冗余数据，明确业务逻辑。

6.7.4 辅助数据运维

通过对技术元数据中的数据总量进行排序筛选，对数据量极少的表进行下架整改，对数据量极多的表进行逻辑优化。
通过对技术元数据中的表文件数量进行排序，对文件数量极多的数据表进行小文件合并。
通过对技术元数据中的表文件大小进行排序，对占用空间极多的表开启压缩。

6.7.5 规范数据开发

公司内部的开发规范例如库表、字段的命名规范，字段类型规范等。可以通过元数据对目前已有信息进行标准化校验，用于规范数据开发。

6.7.6 梳理数据依赖关系

通过数据血缘梳理数据依赖关系，流程定位，追踪溯源。

6.7.7 成果汇报、工作量统计

通过元数据信息的增减以及构建可视化展示页面，可以快速展示当前数据开发团队的成果，统计工作量等。

七、元数据管理的量化指标

在推动元数据管理落地过程中，经常会有用户询问：元数据模型质量如何？采集信息是否全面？能否解决他们的痛点？做出来是否好用？市面上元数据管理系统那么多，自建的元数据管理系统的核心优势在哪里，元数据管理的优劣从哪些层次进行评价，于是团队量化出了以下三个元数据管理评价的技术指标：

7.1 准确率

定义： 假设一张表实际的数据属性与元数据中采集的数据属性相符，既不缺失也不多余，属性值一致无误，则认为这个表的元数据是准确的，元数据准确的数据量占全部元数据量的比例即为元数据准确率。准确率是元数据中最核心的指标，元数据的属性缺失或异常可能会造成数据不一致，从而导致业务开展顺利进行，严重则会导致生产故障。

团队在实践中通过以下两种途径去尽早发现有问题的血缘节点：

人工校验： 元数据的准确性问题可以通过构造用例来验证。实际操作时，会从线上运行的任务中采样出一部分元数据，人工校验是否正确。
用户反馈： 全量元数据的准确性验证是个漫长的过程，但是具体到某个用户的某个业务场景，问题就简化多了。实际操作中，会与一些业务方深入的合作，一起校验元数据准确性，并修复问题。