写在前面：
这是一个系列文章，沉淀了我在数据治理领域的一些实践和思考。共分为5篇。分别是：
一、大数据治理：那些年，我们一起踩过的坑
主要讲讲数据治理工作中常见的一些误区。
二、要打仗，你手里先得有张地图：数据治理之元数据管理
这一篇讲讲元数据的概念和具体应用场景。
三、不忘初心方得始终：数据治理之数据质量管理
提升数据质量，始终是数据治理工作中最重要的目标之一。本篇讲述如何科学地进行数据质量管理。
四、书同文车同轨：数据治理之数据标准管理
数据标准的落地始终是难题。本篇希望能提供一些数据标准建设的思路。
五、大数据的淘金之旅，数据治理之数据资产管理
不管厂商把它们叫什么：业务标签，数据资产，还是知识图谱管理，本质上都是从数据中提炼出来的资产。怎么管理和应用好这些资产，是现今数据治理的重要研究课题
这些观点是一家之言，欢迎同仁们商榷，可以发邮件给我：jiangzhenbo.hi@163.com，或者加我微信：401172028，共同探讨数据治理相关领域的问题。
谢谢。
正文：
这篇文章主要讲数据治理的基础和核心之一：元数据。从关于元数据的三个概念谈起，讲到元数据的分布范围和如何获取元数据，最后从几个常见的应用出发，谈谈元数据的一些实际应用场景。
元数据是一个相当抽象、不易理解的概念，所以第一个章节，我们先把元数据是什么搞懂。这一章节共提出三个概念。
1、元数据（meta Data）是描述数据的数据。
这是元数据的标准定义，但这么说有些抽象，技术同学能听懂，倘若听众缺乏相应的技术背景，可能当场就懵逼了。产生这个问题的根源其实是一个知识的诅咒：我们知道某件事情，向不了解的人描述时却很难讲清楚。
要破解这个诅咒，我们不妨借用一个比喻来描述元数据：元数据是数据的户口本。让我们想想一个人的户口本是什么，是这个人的信息登记册：上面有这个人的姓名，年龄，性别、身份证号码，住址、原籍、何时从何地迁入等等，除了这些基本的描述信息之外，还有这个人和家人的血缘关系，比如说父子，兄妹等等。所有的这些信息加起来，构成对这个人的全面描述。那么所有的这些信息，我们都可以称之为这个人的元数据。
同样的，如果我们要描述清楚一个实际的数据，以某张表为例，我们需要知道表名、表别名、表的所有者、数据存储的物理位置、主键、索引、表中有哪些字段、这张表与其他表之间的关系等等。所有的这些信息加起来，就是这张表的元数据。
这么一类比，我们对元数据的概念可能就清楚很多了：元数据是数据的户口本。
2、元数据管理，是数据治理的核心和基础。
为什么我们说元数据管理是数据治理的核心和基础？为什么在做数据治理的时候要先做元数据管理？它的地位为何如此特殊？
让我们想象一下，一位将军要去打仗，他必不可少，必须要掌握的信息是什么？对，是战场的地图。很难相信手里没有军事地图的一位将军能打胜仗。而元数据就相当于是所有数据的一张地图。
在这张关于数据的地图中，我们可以知道：
我们有哪些数据？
数据分布在哪里？
这些数据分别是什么类型？
数据之间有什么关系？
哪些数据经常被引用？哪些数据无人光顾？
……
所有的这些信息，都可以从元数据中找到。如果我们要做数据治理，但是手里却没有掌握这张地图，做数据治理就犹如是瞎子摸象。后续的文章中我们要讲到的数据资产管理，知识图谱，其实它们大部分也是建立在元数据之上的。所以我们说：元数据是一个组织内的数据地图，它是数据治理的核心和基础。
3、元数据是描述数据的数据，那么有没有描述元数据的数据？
有。描述元数据的数据叫元模型(meta Model)。元模型、元数据、数据之间的关系，可以用下面这张图来描述。
对于元模型的概念，我们不做深入的讨论。我们只需要知道下面这些：
元数据本身的数据结构也是需要被定义和规范的，定义和规范元数据的就是元模型，国际上元模型的标准是CWM(Common Warehouse metamodel，公共仓库元模型)，一个成熟的元数据管理工具，需要支持CWM标准。
在大数据平台中，元数据贯穿大数据平台数据流动的全过程，主要包括数据源元数据、数据加工处理过程元数据、数据主题库专题库元数据、服务层元数据、应用层元数据等。下图以一个数据中心为例，展示了元数据的分布范围：
业内通常把元数据分为以下类型：
技术元数据：库表结构、字段约束、数据模型、ETL程序、SQL程序等。
业务元数据：业务指标、业务代码、业务术语等。
管理元数据：数据所有者、数据质量定责、数据安全等级等。
元数据采集是指获取数据生命周期中的元数据，对元数据进行组织，然后将元数据写入数据库中的过程。
要获取到元数据，需要采取多种方式，在采集方式上，使用包括数据库直连、接口、日志文件等技术手段，对结构化数据的数据字典、非结构化数据的元数据信息、业务指标、代码、数据加工过程等元数据信息进行自动化和手动采集。
元数据采集完成后，被组织成符合CWM模型的结构，存储在关系型数据库中。
这一章节我们主要讲元数据的几个典型的应用。
先看一张元数据管理的整体功能架构图，有了元数据，我们能做些什么，从这张图里一目了然：
1.元数据查看
一般是以树形结构组织元数据，按不同类型对元数据进行浏览和检索。如我们可以浏览表的结构、字段信息、数据模型、指标信息等。通过合理的权限分配，元数据查看可以大大提升信息在组织内的共享。
2.数据血缘和影响性分析
数据血缘和影响性分析主要解决“数据之间有什么关系”的问题。因其重要价值，有的厂商会从元数据管理中单独提取出来，作为一个独立的重要功能。但是笔者考虑到数据血缘和影响性分析其实是来自于元数据信息，所以还是放在元数据管理中来描述。
血缘分析指的是取到数据的血缘关系，以历史事实的方式记录数据的来源，处理过程等。
以某张表的血缘关系为例，血缘分析展示如下信息：
数据血缘分析对于用户具有重要的价值，如：当在数据分析中发现问题数据的时候，可以依赖血缘关系，追根溯源，快速地定位到问题数据的来源和加工流程，减少分析的时间和难度。
数据血缘分析的典型应用场景：某业务人员发现“月度营销分析”报表数据存在质量问题，于是向IT部门提出异议，技术人员通过元数据血缘分析发现“月度营销分析”报表受到上游FDM层四张不同的数据表的影响，从而快速定位问题的源头，低成本地解决问题。
除了血缘分析之外，还有一种影响性分析，它能分析出数据的下游流向。当系统进行升级改造的时候，如果修改了数据结构、ETL程序等元数据信息，依赖数据的影响性分析，可以快速定位出元数据修改会影响到哪些下游系统，从而减少系统升级改造带来的风险。从上面的描述可以知道：数据影响性分析和血缘分析正好相反，血缘分析指向数据的上游来源，影响性分析指向数据的下游。
影响性分析的典型应用场景：某机构因业务系统升级，在“FINAL_ZENT ”表中修改了字段：TRADE_ACCORD长度由8修改为64，需要分析本次升级对后续相关系统的影响。对元数据“FINAL_ZENT”进行影响性分析，发现对下游DW层相关的表和ETL程序都有影响，IT部门定位到影响之后，及时修改下游的相应程序和表结构，避免了问题的发生。由此可见，数据的影响性分析有利于快速锁定元数据变更带来的影响，将可能发生的问题提前消灭在萌芽之中。
3.数据冷热度分析
冷热度分析主要是对数据表的被使用情况进行统计，如：表与ETL程序、表与分析应用、表与其他表的关系情况等，从访问频次和业务需求角度出发，进行数据冷热度分析，用图表的方式，展现表的重要性指数。
数据的冷热度分析对于用户有巨大的价值，典型应用场景：我们观察到某些数据资源处于长期闲置，没有被任何应用调用，也没有别的程序去使用的状态，这时候，用户就可以参考数据的冷热度报告，结合人工分析，对冷热度不同的数据做分层存储，以更好地利用HDFS资源，或者评估是否对失去价值的这部分数据做下线处理，以节省数据存储空间。
4.数据资产地图
通过对元数据的加工，可以形成数据资产地图等应用。数据资产地图一般用于在宏观层面组织信息，以全局视角对信息进行归并、整理，展现数据量、数据变化情况、数据存储情况、整体数据质量等信息，为数据管理部门和决策者提供参考。
5.元数据管理的其他应用
元数据管理中还有其他一些重要功能，如：
元数据变更管理。对元数据的变更历史进行查询，对变更前后的版本进行比对等等。
元数据对比分析。对相似的元数据进行比对。
元数据统计分析。用于统计各类元数据的数量，如各类数据的种类，数量等，方便用户掌握元数据的汇总信息。
诸如此类的应用，限于篇幅，不一一列举。
元数据就相当于是数据的户口本和地图，是数据治理的核心和基础。
元数据产生于从数据生产、数据接入、数据加工、数据服务到数据应用的各个环节，整体上可以分为三类：技术元数据、业务元数据和管理元数据。
元数据采集入库后，可以产生冷热度分析、血缘关系分析、影响性分析，数据资产地图等应用。元数据管理可以让数据被描述得更加清晰，更容易被理解，被追溯，更容易评估其价值和影响力。元数据管理还可以大大促进信息在组织内外的共享。
作者信息：
蒋珍波，大数据专家，擅长为客户提供科学合理的大数据解决方案，尤其擅长数据治理、数据中台解决方案。曾先后供职于东南融通、普元信息、数澜科技、数梦工场等公司，负责过数据仓库、大数据平台、数据中台、数据治理等售前咨询工作，和技术团队的管理工作，有政府、大中型企业等多个行业经验。著有畅销专业书籍《数据中台》、《一本书讲透IT售前》。