数字化时代，企业需要知道它们拥有什么数据，数据在哪里、由谁负责，数据中的值意味着什么，数据的生命周期是什么，哪些数据安全性和隐私性需要保护，以及谁使用了数据，用于什么业务目的，数据的质量怎么样，等等。这些问题都需要通过元数据管理解决，缺乏有效的元数据管理，企业的数据资产可能会变成拖累企业利润的＂包袱＂。 数据已经成为增强企业竞争力的核心要素，有效地管理和使用数据成为企业的刚需。越来越多的企业使用元数据管理工具来管理云计算、物联网、数据湖中所产生的数据，以便更容易地理解、更快地查找和更有效地管理企业数据，实现数据的价值。 01 元数据管理概述 没有元数据，数据其实就没有任何意义。元数据看起来只是一堆毫无意义的文字和数字，但本质上它为企业的各类数据提供了上下文环境，使企业能够更好地了解、管理和使用数据。 1.1 什么是元数据？ 元数据是关于数据的组织、数据域及其关系的信息，简言之，元数据就是描述数据的数据。 概念总是生涩的，对于没有IT背景的人来说比较抽象，不容易理解，下面举几个例子。 示例1：歌词中的元数据 有一首很多80后耳熟能详的歌曲叫《小芳》，歌词中有这么一句：＂村里有个姑娘叫小芳，长得好看又善良。＂我们对这句歌词做一下分析。姓名，小芳；性别，姑娘（女）；长相，好看；性格，善良；住址，村里。＂小芳＂是被描述的对象，而＂姓名＂＂性别＂＂长相＂＂性格＂＂住址＂就是描述＂小芳＂的元数据。 示例2：户口本中的元数据 户口本中除了有姓名、身份证号、出生日期、住址、民族等信息外，还有家庭关系，如夫妻关系、父子关系、兄弟关系等。这些信息就是描述一个人的元数据，通过户口本中的元数据，我们不仅能够了解一个人的基本信息，还能够了解其家庭关系。 示例3：图书馆中的元数据 图书馆都会用一个叫作＂图书目录＂的文件夹来管理藏书，图书目录包含图书名称、编号、作者、主题、简介、摆放位置等信息，用来帮助图书管理员管理和快速查找图书。元数据就如同图书馆的图书目录一样，能够帮助数据管理员管理数据。 示例4：元数据好比字典 字典包含一个字的注音、含义、组词、举例等基本信息及其字体结构、相关引用、出处等。另外，我们可以通过拼音或偏旁部首查到这个字。所有这些信息都是对这个字的详细描述，它们就是描述这个字的元数据。 示例5：元数据就像地图 地图是按一定比例运用线条、符号、颜色、文字注记等描绘显示地球表面的自然地理、行政区域、社会经济状况的图。通过地图，您能够找到自己所处的地理位置，了解您从哪里来，到哪里去，途中要路过哪些地方。元数据也具备这样的特点，它能够帮助企业了解自己有哪些数据，这些数据存放在哪里，数据的来源、去向及加工路径等。 元数据与数据的不同之处在于：元数据描述的不是特定的实例或记录，IT部门和业务部门都需要高质量的元数据来理解现有数据；元数据是比一般意义上的数据范畴更加广泛的数据，不仅表示数据的类型、名称、值等信息，还提供数据的上下文描述，比如数据的所属业务域、取值范围、数据间的关系、业务规则、数据来源等。 可以用5W1H模型来理解元数据，如表1所示。 表1 用5W1H模型理解元数据 1.2 元数据的3种类型 按照不同应用领域或功能，元数据一般大致可分为三类：业务元数据、技术元数据和操作元数据。 1.2.1 业务元数据 业务元数据描述数据的业务含义、业务规则等。明确业务元数据可以让人们更容易理解和使用业务元数据。元数据消除了数据二义性，让人们对数据有一致的认知，避免＂自说自话＂，进而为数据分析和应用提供支撑。 常见的业务元数据有： 业务定义、业务术语解释等； 业务指标名称、计算口径、衍生指标等； 业务引擎的规则、数据质量检测规则、数据挖掘算法等； 数据的安全或敏感级别等。 1.2.2 技术元数据 技术元数据是结构化处理后的数据，方便计算机或数据库对数据进行识别、存储、传输和交换。技术元数据可以服务于开发人员，让开发人员更加明确数据的存储、结构，从而为应用开发和系统集成奠定基础。技术元数据也可服务于业务人员，通过元数据厘清数据关系，让业务人员更快速地找到想要的数据，进而对数据的来源和去向进行分析，支持数据血缘追溯和影响分析。 常见的技术元数据有： 物理数据库表名称、列名称、字段长度、字段类型、约束信息、数据依赖关系等； 数据存储类型、位置、数据存储文件格式或数据压缩类型等； 字段级血缘关系、SQL脚本信息、ETL信息、接口程序等； 调度依赖关系、进度和数据更新频率等。 1.2.3 操作元数据 操作元数据描述数据的操作属性，包括管理部门、管理责任人等。明确管理属性有利于将数据管理责任落实到部门和个人，是数据安全管理的基础。 常见的操作元数据有： 数据所有者、使用者等； 数据的访问方式、访问时间、访问限制等； 数据访问权限、组和角色等； 数据处理作业的结果、系统执行日志等； 数据备份、归档人、归档时间等。 元数据的分类及实例见表2。 表2 元数据的分类（以＂客户＂信息为例） 1.3 元数据的6个作用 在信息世界，元数据的主要作用是对数据对象进行描述、定位、检索、管理、评估和交互。 描述：对数据对象的内容、属性的描述，这是元数据的基本功能，是各组织、各部门之间达成共识的基础。 定位：有关数据资源位置方面的信息描述，如数据存储位置、URL等记录，可以帮助用户快速找到数据资源，有利于信息的发现和检索。 检索：在描述数据的过程中，将信息对象中的重要信息抽出标引并加以组织，建立它们之间的关系，为用户提供多层次、多途径的检索体系，帮助用户找到想要的信息。 管理：对数据对象的版本、管理和使用权限的描述，方面信息对象管理和使用。 评估：由于有元数据描述，用户在不浏览具体数据对象的情况下也能对数据对象有个直观的认识，方便用户的使用。 交互：元数据对数据结构、数据关系的描述方便了数据对象在不同部门、不同系统之间进行流通和流转，并确保流转过程中数据标准的一致性。 元数据以数字化方式描述企业的数据、流程和应用程序，为企业数字资产的内容提供了上下文，使得数据更容易理解、查找、管理和使用。准确的元数据是必不可少的，也是迅速、有效地对数据去粗取精的关键。没有元数据，数据就毫无意义，只不过是一堆数字或文字而已。因此，对于元数据的有效管理是企业数据治理的基础。 1.4 什么是元数据管理 根据维基百科的定义，元数据管理是指与确保正确创建、存储和控制元数据，以便在整个企业中一致地定义数据有关的活动。 元数据管理是对涉及的业务元数据、技术元数据、操作元数据进行盘点、集成和管理。采用科学有效的机制对元数据进行管理，并面向开发人员、业务用户提供元数据服务，可以满足用户的业务需求，为企业业务系统和数据分析的开发、维护等过程提供支持。 可以从技术、业务和应用三个角度理解元数据管理。 技术角度：元数据管理着企业的数据源系统、数据平台、数据仓库、数据模型、数据库、表、字段以及字段间的数据关系等技术元数据。 业务角度：元数据管理着企业的业务术语表、业务规则、质量规则、安全策略以及表的加工策略、表的生命周期信息等业务元数据。 应用角度：元数据管理为数据提供了完整的加工处理全链路跟踪，方便数据的溯源和审计，这对于数据的合规使用越来越重要。通过数据血缘分析，追溯发生数据质量问题和其他错误的根本原因，并对更改后的元数据进行影响分析。 企业元数据管理的主要活动包括： 创建并记录主题领域的实体和属性的数据定义； 识别数据对象之间的业务规则和关系； 证明数据内容的准确性、完整性和及时性； 建立和记录内容的上下文（数据血缘、数据影响的全链路跟踪分析）； 为多样化的数据用户提供一系列上下文理解，包括用于合规性、内部控制和更好决策的可信数据； 为技术人员提供元数据信息，支持数据库或应用的开发。 1.5 元数据管理的3个目标 企业元数据管理的本质是有效利用企业数据资产，让数据发挥出尽可能大的价值。元数据管理可以帮助业务分析师、系统架构师、数据仓库工程师和软件开发工程师等相关干系人清楚地知道企业拥有什么数据，它们存储在哪里，如何抽取、清理、维护这些数据并指导用户使用。 以下元数据管理目标是企业的普遍诉求。 1.5.1 建立指标解释体系 满足用户对业务和数据理解的需求，建立标准的企业内部知识传承的信息承载平台，建立业务分析知识库，实现知识共享。能够回答以下问题： 企业有哪些数据？ 什么是企业有效客户？有效客户和客户有何区别？ 什么是产品的生命周期？ 这个数据还叫什么名字？ 数据仓库中的存储过程是谁写的？它用来干什么？现在还在用吗？ 典型应用有数据资源目录和业务术语表。 1.5.2 提高数据溯源能力 让用户能够清晰地了解数据仓库中数据流的来龙去脉、业务处理规则、转换情况等，提高数据的溯源能力，支持数据仓库的成长需求，降低因员工换岗造成的影响。元数据有助于回答以下问题： 这张表是从哪个业务系统中抽取过来的？ ETL过程是否对数据进行过加工处理？进行了哪些处理？ 指标数据是从哪些表汇总计算出来的？ 典型应用有血缘分析、影响分析、全链路分析。 1.5.3 数据质量稽核体系 通过非冗余、非重复的元数据信息提高数据完整性、准确性。元数据管理解决的问题是如何将业务系统中的数据分门别类地进行管理，建立报警、监控机制，出现故障时能及时发现问题，为数据仓库的数据质量监控提供基础素材。能够回答以下问题： 今天的在线用户数为什么是0？ 为什么A报表中的本月收入值与B报表中的不同？ 典型应用有指标标准和数据质量规则。 1.6 元数据管理的4个挑战 尽管企业越来越意识到元数据管理的重要性，但是在实际的数据治理中，元数据管理技术和方法仍面临着很多挑战。 1.6.1 局部的元数据管理 虽然很多企业已经意识到元数据管理能够创建对数据的统一描述并确保数据的一致性，但是，目前国内企业的元数据管理多数是建立在新建系统或数据仓库项目的局部治理上，而不是企业级的元数据管理，特别是对于企业采购的套装软件的治理显得十分薄弱。主要原因是，要将中央元数据仓库的元数据与套装软件产生的元数据进行匹配和映射，需要做大量工作。有的企业的元数据管理平台成为摆设，或者只有部分IT人员在用，很少甚至完全没有尝试在整个企业中使用和推广集中化的元数据。这在一定程度上限制了企业数据资产的共享或重用。因此，元数据管理需要全局、集中化的管理策略。 1.6.2 手动的元数据管理 在企业元数据管理项目的实施中，需要花费很长的时间来完成元数据的梳理和定义、元数据适配器的开发、元数据的采集、元数据的维护等任务。这些任务绝大多数是需要人工手动处理的，手动的元数据管理和维护十分烦琐且容易出错，这使得项目的成本提高，交付的周期变长。 因此，元数据管理需要更加有效的方法和自动化程度更高的工具。 1.6.3 日趋复杂的数据环境 大数据时代，随着越来越多的非结构化、半结构化数据渗透到企业的数字环境中，采用传统的元数据管理方式来采集、处理和检索元数据变得越来越具有挑战性。尤其是在处理复杂的数据关系时，虽然人们很容易根据认知关联来判断两个或多个事物是否相关，但目前的元数据管理工具却常常无法做到。 因此，元数据管理需要更智能化的技术。 1.6.4 数据的频繁变化 企业的数据是在数据供应链中不断移动的。这里所说的数据供应链，是指从数据创建到数据的加工处理、存储使用的整个生命周期链条。随着数据的不断创建、抽取和转换，有关数据来源、血缘、转换过程、质量级别以及与其他数据的关系的元数据也会随时变化。企业需要将自动化算法和规则应用于数据资产管理中，自动识别和生成元数据，减少手动维护的情况，从而确保元数据描述准确可靠。 1.7 元数据管理的4个阶段 从元数据的发展历史来看，元数据管理主要经历了4个阶段：分布式桥接阶段、中央存储库阶段、元数据仓库阶段、智能化管理阶段（见图1）。 图1 元数据管理的4个阶段 1.7.1 分布式桥接阶段 分布式的元数据管理使用元数据桥实现不同工具间的元数据集成，这是一种点到点的元数据体系结构。分布式的桥接方式自然会导致分布式的元数据分发机制，这违背了数据仓库＂集中存储，统一视图＂的处理原则，也是它的主要弱点。用这种方式集成元数据会大幅增加开发和维护费用，而且通常将一种格式的元数据转换为另一种格式时，都会有一定的信息损失。 分布式的元数据结构需要对互相共享元数据的数据库进行同步，尤其是重复元数据的更新须被检测并通告，以保持一致性。 1.7.2 中央存储库阶段 建立具有特定目标和需求的元数据中央存储库，由它来统一采集、存储、控制和分发元数据。例如，CRM、SCM等应用系统从中央存储库中检索、使用元数据。 在这种模式下，元数据依然在局部产生和被获取，但会集中到中央存储库进行存储，业务元数据会手工录入中央存储库中，技术元数据分散在文档中的部分也通过手工录入中央存储库中，而散落在各个中间件和业务系统中的技术元数据则通过数据集成的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式进行了关联。 每个应用系统都必须实现它自己的数据库访问层（另一种形式的桥接），各大BI工具厂商通常都保证它们的工具本身就能够支持元数据管理，例如Informatica的Metadata Manager、IBM的MetaStage。然而在具体实现中，它们的工具只是提供桥梁，从像Oracle这样的RDBMS、Hyperion Essbase之类的MDDB、BusinessObjects之类的报表工具，甚至像ERWin这样的数据建模工具中提取信息，然后将提取出的信息存储到一个集中式的中央存储库中。 使用元数据中央存储库可以在一定程度上解决定义全局可用且被广泛理解的元数据的需求，使元数据在整个企业层面可被感知和搜索，极大地方便企业获取和查找元数据。但这并没有完全根除问题：元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的对象，而同一个对象则使用了多个不同的名字，有些没有纳入业务系统管理的元数据则容易缺失。中央存储库仍然需要使用元数据桥，无法根除受制于特定厂商的问题。 1.7.3 元数据仓库阶段 元数据仓库遵循基于CWM（公共仓库元模型）的元数据管理策略。CWM是用来输入、输出共享公共仓库元数据的一个完全的语法和语义规范，提供了一个描述数据源、数据目标、转换、分析和处理的元数据管理基础框架，为不同工具和产品的元数据共享和交换提供了一个切实可行的标准。 通过构建基于CWM的元数据仓库，数据源、ETL工具、各类报表和BI工具、各类数据库系统的元数据有了一致的标准，各软件工具只需要建立一个与元数据仓库连接的CWM适配器就能实现相互之间的元数据交换或共享。 与中央存储库模式相比，基于CWM的元数据仓库模式更新数据更加及时，并支持增量元数据的版本管理，而中央存储库的元数据更新周期通常在一天以上，并且需要将所有不同时期的元数据都存储下来才能支持元数据版本管理。但本质上，元数据仓库模式并没有多大变化，业务元数据仍然需要手动补录，业务元数据和技术元数据之间大多还是需要通过手工方式进行映射，因此管理成本无法降低很多。 当前，大部分企业的元数据管理处于中央存储库和元数据仓库这两个阶段。 1.7.4 智能化管理阶段 在这个阶段，元数据管理的特点是自动化、智能化，通过与人工智能、机器学习等技术融合，实现元数据提取、整合、维护等多个过程的自动化和智能化。 （1）元数据提取 对于半结构化、非结构化的数据，例如文本文件、音视频文件，采用文本识别、图像识别、语音识别、自然语言处理等技术，自动发现和提取其元数据，形成有价值的数据资源池。 （2）元数据整合 在元数据的整合方面，通过语义模型，标签体系自动采集相关的技术元数据和业务元数据，自动建立技术元数据与业务元数据的关系，并将其存储进元数据存储库中。 （3）元数据维护 在人工智能技术的帮助下，元数据的管理和维护更加智能，例如：通过自定义规则探查元数据的一致性，并自动提醒更新和维护，确保元数据质量；通过语义分析为元数据自动打标签，实现元数据的自动化编目等。 在这个阶段，逻辑层次元数据的变更会被传播到物理层次，同样，物理层次变更时，逻辑层次将被更新。元数据中的任何变化都会触发业务工作流，以便其他业务系统进行相应的修改。 02 元数据管理方法 从实施层面来看，元数据管理包括业务目标理解、元数据需求规划、元数据设计、元数据管理体系的设计等。 2.1 业务目标理解 元数据管理是利用可视化的用户体验，基于灵活、健壮的元数据管理架构，实现企业数据资产的标准化、集中化管理。企业实施元数据管理需要首先从理解业务需求入手，只有理清了业务需求和目标，才能做出合理的元数据规划。 通常企业实施元数据管理的主要业务诉求如下。 （1）建立企业数据资产目录 数据即资产的理念已经得到企业的广泛认可。面对不断增长、不断变化、日益复杂的数据环境，企业需要数据资产的简单发现和跟踪能力。通过管理元数据，企业能够快速发现数据资产的分布和关系，形成企业数据资产目录。 （2）消除冗余，加强数据复用 通过元数据管理，建立基于CWM的元数据仓库，实现企业元数据的统一管理，并将元数据仓库作为＂单一数据源＂，为企业的应用开发提供可复用的数据模型和元数据标准，以实现元数据的重复利用，减少冗余或未使用数据，从而提高工作效率，降低软件开发成本，缩短项目交付时间。 （3）降低因人员流动而导致知识流失的风险 企业重要的数据资产常常因关键员工的调离或离职而＂消失＂，这里所谓的＂消失＂通常并不是因为员工将数据恶意删除或拿走，而是企业数据资产的存放方式、存储位置等关键数据都只留在关键员工的大脑中，一旦该员工离开公司，数据资产也就隐没在＂茫茫数海＂中了！而统一的元数据管理能够降低企业这种数据＂消失＂的风险。 （4）提供数据血缘探查能力，提高数据分析的质量 数据来自什么地方以及如何产生、处理和交付数据，这为用户提供了重要的背景知识。探查源系统中的数据可以暴露和解决数据的不准确、不一致问题，从而提升数据的质量。 此外，元数据的统一管理，提供变更管理、版本控制等能力为不断变更的业务需求所带来的影响提供了支撑，并加快了新应用开发项目和数据集成项目的开发速度。开发人员可以依赖统一、标准的元数据来轻松、准确地确定他们的项目所需的数据，从而节约项目开发成本，提升项目交付效率。 2.2 元数据需求规划 在充分理解企业元数据管理诉求和目标之后，需要进行元数据规划，设计元数据管理策略，以促进元数据目标的实现。 元数据贯穿企业数据资产流动的全过程，主要包括数据源的元数据、数据采集的元数据、数据仓库的元数据、数据集市的元数据、应用服务层的元数据和BI层的元数据等。 进行元数据的需求规划时，需要了解清楚企业的数据环境，明确数据资产的分布，明确数据的流向和路径，从而进一步确定元数据在数据库环境中的存储情况，如数据结构、数据字典、数据关系、报表工具、其他第三方系统或工具等，以及是否需要元数据梳理模板，手动整理元数据作为补充等。 元数据需求规划应重点关注的需求如下。 元数据模型需求：命名规范、结构、元素及关联关系等。 元数据接口需求：元数据资料库及其内容，适配器、所有者、系统访问、元数据血缘关系等。 元数据系统需求：元数据采集、元数据管理、元数据应用等。 数据安全需求：数据的分类分级、敏感数据分布、敏感数据管理要求等。 数据质量需求：数据质量规则、数据标准定义等。 数据管理需求：数据管理的组织、流程、制度、考核等。 元数据需求规划的步骤如下： 1）企业战略调研：调研企业的业务发展战略和主要业务领域的业务发展规划，梳理IT建设的历史、现状和初步规划。 2）数据管理调研：调研企业数据管理的背景、问题、目标，以及企业数据管理目前的相关制度、流程和组织。 3）元数据现状清单：功能性信息需求、逻辑模型、物理模型、业务术语字典、已有数据环境、系统文档等。 4）数据问题分析：基于现状评估及成熟度评估，找出差异，定位问题并进行问题根本原因分析，结合行业业务、数据发展要求，制定问题解决优先级计划，并制定改进方案。 5）制定行动路线：元数据实施路线的制定应聚焦企业当前最紧迫、最重要的建设内容，确保项目范围可控、成效可见。 2.3 元数据规划设计 2.3.1 元数据设计原则 每个企业的业务各不相同，元数据的设计必须围绕其特定的业务需求展开，需要确保企业收集正确的元数据清单以解决特定的业务问题。元数据设计应遵循以下原则。 （1）简单性与准确性原则 对信息对象的描述应简单易懂，应尽量基于共识采用业务语言进行设计，尽量避免使用晦涩难懂的技术语言。当然，也要考虑简单化可能导致描述不准确，需在二者之间进行权衡。 （2）互操作性原则 元数据的互操作性体现在对异构系统间的互操作能力的支持，即在各种元数据标准下建立元数据，不仅要满足当前应用对数据的操作，还应考虑在企业整体IT环境中的互操作性。 （3）可扩展性原则 企业的数据环境时刻在发生变化，因此元数据的设计应具备一定的可扩展性，应允许用户在不破坏既有标准的前提下，扩充一些元素或属性。 （4）用户需求原则 元数据设计的目的是向用户充分揭示信息资源，因此用户需求应作为元数据设计的最终衡量标准，特别是在数据结构与格式的设计、数据元素的增加与取舍、语义规则的制定等方面，要尽可能从用户需求出发，通过用户交互和用户反馈来完善元数据的设计。 2.3.2 元数据设计步骤 元数据设计一般分为分类、定义、获取、发布四个步骤，并以设计结果作为基线，纳入元数据平台管理中。 （1）元数据分类 根据元数据用途及使用者的不同制定元数据分类框架，规划业务元数据、技术元数据、操作元数据所包含的数据类型和集合。明确元数据管理的种类，如数据字典、逻辑模型、物理模型、报表定义、维度加工规则、数据映射信息、接口信息等，根据规则进行元数据分类。 常用的元数据分类方式有以下两种： 按照业务主题进行组织，即通过从业务域到业务主题、实体数据、数据模型的逐层分解方式，规划元数据的分类。这是一种站在业务视角管理元数据的方式，能够形成业务人员容易理解的数据目录。 按照数据源进行组织，即通过源数据系统、数据表、数据结构形式展现企业数据目录，这种方式更便于IT人员使用元数据。 在实际的使用中，通常需要将两个分类方式相结合，以形成企业级的元数据地图。 （2）元数据定义 元数据定义就是对数据的业务属性、技术属性、操作属性进行规范化的定义，主要是描述数据属性的信息，如属性名称、用途、存储位置、历史数据、文件记录等。 （3）元数据获取 元数据的基本要素包括业务术语、业务规则、报表说明、指标定义，技术细节包括各个业务系统的数据结构、代码字段取值、数据迁移与转换规则等。以上元数据除了通过自动化工具获取，有时候还需要通过模板手工整理作为补充。 对于一些数据源（例如一些老旧的信息系统），由于缺乏最初的元数据设计，所以很难获取到准确的业务元数据。这些业务元数据更加需要业务人员的配合，由业务人员进行补充，最终形成并交付业务元数据成果。 （4）元数据发布 评估和分析分散在各个应用系统、各个部门中的业务元数据、技术元数据之间的关联性，建立技术元数据与业务元数据的映射，形成企业级元数据地图，发布元数据基线。 在后续的运维过程中，根据各业务部门的用数需求，分析判断元数据仓库中是否已存在相应的元数据。如果元数据仓库中已有该元数据，则直接共享使用；如果元数据仓库中没有，则需要确定采集方案，进行数据采集，并对采集的元数据进行整理完善，与生产库建立映射关系，最后完成新增元数据的发布。 元数据规划设计是元数据管理实施中最重要，也是工作量最大的一个过程，这是国内大多数企业元数据管理的现状。究其原因，主要还是数据管理体系不够成熟，也可以说是数据不够成熟。很多企业从一开始就没有完整的数据规划，比如业务术语、指标的定义，现在几乎要整体倒推，获得元数据自然就比较困难。 2.4 元数据管理体系设计 在数据治理整体框架下，建立元数据管理体系，从组织、制度、流程、技术与工具等方面保障元数据的有效实施和运营管理，规范元数据的日常采集和处理活动，帮助企业有效管理元数据。 组织保障：明确业务牵头部门、业务与信息化的协作关系，明确各部门数据认责范围。在数据治理团队的指导下，针对企业的数据管理组织现状，建立公司高层支持、中层管理协调、基层执行三个层面的数据治理组织，明确各层的工作职责，为元数据管理工作提供组织保障。 制度保障：元数据管理是企业的IT基础设施，涉及的系统较广，需要调动的资源较多，在实施的过程中，企业高层管理者需要给予强有力的支持，并制定相应的规章制度进行保障，这是项目实施持续推进的动力。 流程保障：为保证数据治理措施的落地执行，需要从数据认责、标准管理、质量管理等多个方面进行流程设计，制定企业范围内数据的变更管理流程，保证信息系统中的数据与管理规范、数据标准的一致性。 技术与工具：搭建统一的元数据管理平台，实现企业级元数据集中管控，支持元数据采集、元数据管理、元数据共享、元数据血统分析、元数据影响分析、企业数据地图等功能。 运营维护：定义捕获、维护业务元数据、技术元数据、操作元数据，定期分发和交付元数据。 监控管理：提供元数据的新增和变更流程，控制元数据新增、变更等操作，支持元数据的日常监控，管理元数据版本，做好元数据的血缘分析、影响分析。 统计分析：元数据系统运营情况统计报告，支持元数据查询、元数据使用情况分析（如冷热度分析）等。 宣传推广：通过企业内部网络、会议等各种渠道，推广元数据管理平台，提高元数据管理平台的使用量，提升元数据在企业中的价值认识度。 03 元数据管理技术 从技术层面来看，元数据管理技术主要包括元数据采集、元数据管理、元数据应用和元数据接口等。 3.1 元数据采集 在数据治理项目中，常见的元数据有数据源的元数据、数据加工处理过程的元数据、数据仓库或数据主题库的元数据、数据应用层的元数据、数据接口服务的元数据等。 元数据采集服务提供各类适配器来满足以上各类元数据的采集需求，并将元数据整合处理后统一存储于中央元数据仓库，实现元数据的统一管理。在这个过程中，数据采集适配器十分重要，元数据采集不仅要能够适配各种数据库、各类ETL、各类数据仓库和报表产品，还需要适配各类结构化或半结构化数据源。 3.1.1 关系型数据库 通过元数据适配器采集来自Oracle、DB2、SQL Server、MySQL、Teradata、Sybase等关系型数据库的库表结构、视图、存储过程等元数据。关系型数据库一般都提供了元数据的桥接器，例如Oracle的RDBMS，可实现元数据信息的快速读取。 3.1.2 NoSQL数据库 元数据采集工具应支持来自MongoDB、CouchDB、Redis、Neo4j、HBase等NoSQL数据库中的元数据，NoSQL数据库适配器多半利用了自身管理和查询Schema的能力。 3.1.3 数据仓库 对于主流的数据仓库，可以基于其内在的查询脚本，定制开发相应的适配器，对其元数据进行采集。例如MPP数据库Greenplum，其核心元数据都存储在pg_database、pg_namespace、pg_class、pg_attribute、pg_proc这几张表中，通过SQL脚本就可以对其元数据进行采集。Hive表结构信息存储在外部数据库中，同时Hive提供类似show table、describe table之类的语法对其元数据信息进行查询。 当然，也可以利用专业的元数据采集工具来采集数据仓库系统的元数据。 3.1.4 云中的元数据 随着公有云的日趋成熟，尤其是在中小企业之间，通过提供安全的云连接将云端企业元数据管理用作核心IT基础架构的扩展已经成为现实。云端企业元数据管理通过各种上下文改善信息访问，并将实时元数据管理、机器学习模型、元数据API推进流数据管道，以便更好地管理企业数据资产。 3.1.5 其他元数据适配器 建模工具： PowerDesigner、ERwin、ER/Studio、EA等建模工具适配器。 ETL工具： PowerCenter、DataStage、Kettle等ETL工具适配器。 BI工具： Cognos、Power BI等前端工具中的二维报表元数据采集适配器。 Excel适配器： 采集Excel格式文件的元数据。 当然，目前市场上的主流元数据产品中还没有哪一个能做到＂万能适配＂，在实际应用过程中都需要进行或多或少的定制化开发。 3.2 元数据接口 建立元数据查询、访问的统一接口规范，以将企业核心元数据完整、准确地提取到元数据仓库中进行集中管理和统一共享。 元数据接口规范主要包括接口编码方式、接口响应格式、接口协议、接口安全、连接方式、接口地址等方面的内容。 接口编码方式： 接口编码方式必须在接口的头信息中注明，常用的接口编码方式有UTF-8、GBK、GB2312、ISO-8859-1。 接口响应格式： 元数据接口常用的报文格式，XML或JSON。 接口协议： REST/SOAP协议。 接口安全： Token身份认证。 连接方式： POST。 接口地址： http://url/service?[query]。 3.2 元数据管理 从技术的角度看，元数据管理一般包括元模型管理、元数据审核、元数据维护、元数据版本管理、元数据变更管理等功能。 3.2.1 元模型管理 元模型管理即基于元数据平台构建符合CWM规范的元数据仓库，实现元模型统一、集中化管理，提供元模型的查询、增加、修改、删除、元数据关系管理、权限设置等功能，支持概念模型、逻辑模型、物理模型的采集和管理，让用户直观地了解已有元模型的分类、统计、使用情况、变更追溯，以及每个元模型的生命周期管理。同时，支持应用开发的模型管理。 支持元模型的全生命周期管理。元模型生命周期中有三个状态，分别是设计态、测试态和生产态。 设计态的元数据模型，通常由ERWin、PowerDesigner等设计工具产生。 测试态的元数据模型，通常是关系型数据，如Oracle、DB2、MySQL、Teradata等；或非关系型数据库，如MongoDB、HBase、Hive等。 生产态的元数据模型，本质上与测试态元数据差异不大。 通过元数据平台对应用开发三种状态的统一管理和对比分析，能够有效降低元数据变更带来的风险，为下游ODS、DW的数据应用提供支撑。 3.2.2 元数据审核 元数据审核主要是审核已采集到元数据仓库中但还未正式发布到数据资源目录中的元数据。审核过程中支持对数据进行有效性验证并修复一些问题，例如缺乏语义描述、缺少字段、类型错误、编码缺失或不可识别的字符编码等。 3.2.3 元数据维护 元数据维护就是对信息对象的基本信息、属性、被依赖关系、依赖关系、组合关系等元数据的新增、修改、删除、查询、发布等操作，支持根据元数据字典创建数据目录，打印目录结构，根据目录发现、查找元数据，查看元数据的内容。元数据维护是最基本的元数据管理功能之一，技术人员和业务人员都会使用这个功能查看元数据的基本信息。 3.2.4 元数据版本管理 在元数据处于一个相对完整、稳定的时期，或者处于一个里程碑结束时期，可以对元数据定版以发布一个基线版本，以便日后对存异的或错误的元数据进行追溯、检查和恢复。 3.2.5 元数据变更管理 用户可以自行订阅元数据，当订阅的元数据发生变更时，系统将自动通知用户，用户可根据指引进一步在系统中查询到变更的具体内容及相关的影响分析。元数据管理平台提供元数据监控功能，一旦监控到元数据发生变更，就在第一时间通知用户。 4 元数据应用 4.1 数据资产地图 按数据域对企业数据资源进行全面盘点和分类，并根据元数据字典自动生成企业数据资产的全景地图。该地图可以告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。数据资产地图支持以拓扑图的形式可视化展示各类元数据和数据处理过程，通过不同层次的图形展现粒度控制，满足业务上不同应用场景的图形查询和辅助分析需要（见图2）。 图2 数据资产地图示例 4.2 元数据血缘分析 元数据血缘分析会告诉你数据来自哪里，经过了哪些加工。其价值在于当发现数据问题时可以通过数据的血缘关系追根溯源，快速定位到问题数据的来源和加工过程，减少数据问题排查分析的时间和难度（见图3）。 图3 元数据血缘分析示例 4.3 元数据影响分析 元数据影响分析会告诉你数据去了哪里，经过了哪些加工。其价值在于当发现数据问题时可以通过数据的关联关系向下追踪，快速找到有哪些应用或数据库使用了这个数据，从而最大限度地减小数据问题带来的影响。这个功能常用于数据源的元数据变更对下游ETL、ODS、DW等应用的影响分析。 血缘分析是向上追溯，影响分析是向下追踪，这是这两个功能的区别。 4.4 元数据冷热度分析 元数据冷热度分析会告诉你哪些数据是企业常用数据，哪些数据属于僵死数据。其价值在于让数据活跃程度可视化，让企业中的业务人员、管理人员都能够清晰地看到数据的活跃程度，以便他们更好地驾驭数据，处置或激活僵死数据，从而为数据的自助式分析提供支撑。 4.5 元数据关联度分析 元数据关联度分析会告诉你数据与其他数据的关系，以及它们的关系是怎样建立的。关联度分析是从某一实体关联的其他实体及其参与的处理过程两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，如表与ETL程序、表与分析应用、表与其他表的关联情况等，从而进一步了解该实体的重要程度。