元数据也是数据领域经常提及的名词。相较于数据标准、数据模型，元数据似乎更加“玄乎”。本文希望通过对元数据从定义、形式到应用实践的介绍厘清概念，为数据管理打实基础，抛砖引玉，仅供参考。本文约11000字，阅读全文预计需要20分钟。
一、引言
大数据时代，数据已经公认是一项重要的资产，运用和管理数据资产的能力是企业的核心竞争力之一。2020年3月30日中共中央、国务院发布《关于构建更加完善的要素市场化配置体制机制的意见》，数据作为一种新的生产要素被正式写入了中央文件。随着企业数字化应用不断创新，企业产生的数据正在指数级增长，然而数据孤岛严重、血缘不清晰、数据多重存储、缺乏数据标准、数据质量参差不齐等问题不断涌现，严重制约企业对数据的使用。
- 公司有哪些关键业务数据？对外提供了哪些数据服务？
- 业务流程变化会带来哪些数据变化？信息系统改造需要多少费用？
- 数据在各业务条线和信息系统中是否一致？
- 报表指标的计算公式是什么？原始数据从哪里得到？
- 数据实体的责任人是谁？有哪些用户能够访问？
- 数据的安全等级和数据质量是如何衡量的？
以上诸多问题常常困扰着企业，除了数据本身，人们迫切的需要了解关于数据的一切，使得用于描述这些信息的元数据获得了越来越多的关注和认知。没有元数据，数据无法被理解，也就没有任何意义，可以说元数据是提升数据价值发挥的前提，元数据管理是企业数据治理和数字化转型的核心之一。
二、元数据基本概念
（一）元数据定义
元数据（metadata）最常见的定义是“关于数据的数据”或“描述数据的数据”。Meta一词来自于希腊语的前缀，在逻辑学中有更高层次的含义。《GB/T 18391.1-2009 信息技术 元数据注册系统 (MDR) 第1部分：框架》把元数据定义为定义和描述其他数据的数据[1]。元数据描述了数据本身、数据表示的概念及数据与概念之间的关系。
从描述对象和目的的角度理解，元数据是为了描述、记录、共享、使用和管理数据，对数据的组织结构、表示含义和使用方法等方面进行定义或描述的数据。我们讨论的元数据通常是指狭义元数据，其概念随着数据库技术的发展而出现，最初是用来描述关系型数据库中的数据结构，随后推广到其他被数字化记录和存储的数据，如excel文档、文本文件、网络页面等。广义元数据则将描述的对象泛化至所有可以被定义或描述的客观事物，如流程、事件、对象关系等。元数据提供了数据使用的上下文环境，使其潜在的用户不必事先具备对数据的先验知识。
图2-1 图书目录和数据目录
举例来说，图书目录是描述图书馆馆藏图书的元数据。如图2-1所示，图书目录通过图书名称、分类、作者、主题等信息进行图书内容检索，通过库房书架记录图书存放位置，通过借阅人、借阅时间等开展借阅活动管理。如果没有图书目录，图书馆将无法检索、定位和管理图书。数据目录之于数据业务就如同图书目录之于图书馆，缺少数据目录作为元数据，企业就不能将数据作为资产管理。
通俗地说，任何用以帮助理解事物的信息都可以称为元数据。从广义角度，我们日常所开展的工作如业务流程梳理、信息系统建设、数据标准设计，本质都是构建元数据，并按元数据的规则开展业务或提供服务，企业架构中的业务、应用、数据、技术架构，数据管理领域内的数据模型、数据安全、数据标准和主数据也都属于元数据的范畴。
图2-2 企业架构的元数据表示
（二）元数据和数据的关系
元数据和数据间的概念容易混淆，导致在实际工作中识别元数据经常面临困境，其主要原因是元数据和数据关系的相对性及多样性。
1.元数据和数据是相对的
元数据是一种特殊的数据。一项数据作为元数据还是数据，主要取决于应用场景。正所谓横看成岭侧成峰，在不同的应用场景下，元数据和数据之间可以相互转化，即某种场景下的元数据，可能是另一场景下的实例数据。
图2-3 横看成岭侧成峰（图片来源于网络）
元数据和数据是相对的。如图2-4所示，在创建和维护客户信息场景下，客户表作为元数据定义客户属性，在统计数据资产目录场景下，客户表是一项业务实例数据。
图2-4 元数据的相对性
2.元数据具有多面性
事物普遍具有多面性，同一数据在不同应用场景下需要用不同元数据描述。人们比较熟悉的是直接面向生产经营应用领域的数据，对其元数据具有较直观的认知。而对于非直接用于生产经营目的的数据，往往是基于管理和维护需求对生产经营活动的辅助信息，往往也被笼统地看作生产经营数据的“元数据”。
图2-5 元数据的多面性
如处理某个用户对某项功能的访问请求，实际真正查询的是对具体对象的访问许可，其实质是用户角色权限模型下的实例数据。虽然将其称为“元数据”不够严谨，但是随着数据治理和组织精细化管理的需要，这些非直接用于生产经营的或内部管理需要的数据得到了越来越重要的应用，需要对其真正元数据有正确的认识，并开展相应的数据管理的活动。
三、元数据分类
（一）按元数据来源
《DAMA数据管理知识体系指南》按数据的来源将元数据分为业务元数据，技术元数据和操作元数据[2]323-325。除此之外，管理元数据也得到了广泛认知。
图3-1按来源分类的元数据
1．业务元数据：业务概念、业务逻辑及相互关系的描述性数据，使组织对业务的理解有一致的认知。常见的业务元数据包括：业务术语级定义、业务规则、业务流程、数据标准、概念数据模型和逻辑数据模型等。
2．技术元数据：信息系统中数据存储、处理和交互的描述性数据，是系统开发的基础和依据。常见的技术元数据包括：物理数据模型、系统程序、映射关系、系统接口，数据接口等。
3．操作元数据：处理和访问数据的细节的描述性数据。常见的操作元数据包括：作业执行日志，版本的维护和升级计划，数据归档和备份规则。
4．管理元数据：数据资源管理与维护属性的描述性数据。常见的管理元数据包括：数据属主、数据访问权限等。
各种分类的元数据不是孤立存在，而是相互依存。技术元数据是业务需求在信息系统中的实现，如物理数据模型是概念数据模型的细化实现，对象约束反映的是业务关系和规则。管理元数据描述的管理属性源自开展业务服务的管理需要。业务元数据是最核心的元数据，组织开展任何事物，本质都是业务需求，都应为业务服务。就使用而言，不同类型的元数据间区别并不严格，各种类型的元数据通常集成在一起描述数据不同方面的属性，如数据标准同时具有业务，技术和管理属性。也正是因为技术、业务等元数据的在不同领域的应用，使得跨专业复合型人才成为稀缺的宝贵资源。
（二）按元数据表现形式
根据不同的数据对象和应用场景，元数据定义的方式也不尽相同，没有统一的格式。根据常见的表现形式，元数据可以分为以下几类：
1．表格型元数据：用列表示数据属性，用行表示实例数据，形成二维表格描述具有相同属性的数据，如关系型数据库表，excel表格等。
2．关系型元数据：用节点表示对象，用连线表示节点间关系。如结构图，组件图。
3．流程型元数据：用不同的图形表示对象和事件，用有向线段表示对象和事件联系及事件顺序，常用于描述业务工作流程，如序列图、协作图、活动图和状态图等。
4．文档型元数据：更多的采用自然语言描述原则性规范，如各种规章制度，管理办法等。
四、元数据体系结构
由于元数据自身也是一种数据，定义和描述元数据的数据，称为元元数据，也称为元模型，元元数据的元数据，称为元元元数据，也称为元元模型。以此类推，理论上可以存在无穷的元数据，直到元数据可以被他自身解释，或者由不需要被证明或的公理、常识所定义。
元数据不是唯一的，不同的元数据描述数据的方式和准确程度也有差异。因此如何定义元数据显得格外重要。在所有描述方法中，建模通过抽象公共属性，描述事物的本质特征，其概括能力最强，最具有通用性和统一性。根据抽象程度不同，OMG（Object Management Group对象管理组织）提出MOF(Meta Object Facility元对象机制)[3]将数据模型分为4个层次：信息层（M0）、模型层（M1）、元模型层（M2）和元元模型层（M3）。
元数据体系结构图
1. 信息层(information layer)：信息层是通常意义上的业务数据的集合，主要职责是描述业务的详细信息，如客户，协议等。
2. 模型层(model layer)：模型层由元数据的集合组成,表示的是数据的模型。各种模型可以有不同的语法结构和表现形式。如数据库表结构、文件标签结构等。
3. 元模型层（metamodel layer）：元模型层由元元数据集合组成(元元数据的实例)，是建模语言的集合。元模型定义了元数据的抽象语法结构和语义，如UML，XML，ER模型等。
4. 元元模型层（meta-metamodel layer）：元元模型是为了描述元模型而定义的一种”抽象语言”，这种语言足够抽象到可以描述包括其自身在内的任何可想象到的元数据，如MOF，CDIF（CASE Data Interchange Format）等。元元模型定义了元模型的结构和语义，如将所有概念抽象为对象和对象间的关系，使用元元模型更多的是把它作为一个规范和工具，去设计和实现更优秀的元模型建模系统。
对于元数据体系的每层结构，上层数据是下层数据的抽象，下层的数据是上层数据的实例。上层的抽象可以对应下层的多个实例，采用相同的语法结构和语义定义下层，可以将不同类型的元数据关联起来。通过在上层元模型建立映射，可以在不同类型的元数据之间进行转换。实际工作中，能被直接信息技术识别和使用的一般是模型层元数据，我们通常能使用到的最上层是元模型层，即采用合适的建模语言定义数据模型，使用数据模型创建、使用和管理实例数据。
五、元数据应用
（一）描述数据架构
数据架构是企业架构的四个重要组成部分之一。《DAMA数据管理知识体系指南》对数据架构的定义是：“识别企业的数据需求（无论数据结构如何），并设计和维护总蓝图以满足这些需求。使用总蓝图来指导数据集成、控制数据资产，并使数据投资与业务战略保持一致”[2]71。数据架构是数据管理的基础，大多数组织的数据超过了个人可以理解的范围，因此有必要通过不同抽象层级即元数据来描述。数据架构是企业级高阶的元数据，其中最重要的元数据是数据模型和数据流。
数据模型是数据的组织方式，根据抽象层次可分为概念数据模型、逻辑数据模型和物理数据模型。其中，概念数据模型是根据业务架构形成的，主要描述组织中的最重要的业务对象及其相互关系。逻辑数据模型是对概念数据模型进一步的分解和细化，根据业务规则确定所有的实体和关系，并定义实体的属性、主键和外键。物理数据模型是面向具体的数据库管理系统物理实现的设计模型。数据模型一般用ER实体关系模型表示，描述的是数据的静态属性和关系。
图5-1 逻辑数据模型
如图5-1所示，逻辑数据模型图较为直观地展示了业务模块及其关联关系，有助于组织从业务概念到业务逻辑关系形成统一理解。
数据在组织中的流转是动态的。数据流展现了数据在业务流程、不同存储位置、业务角色和技术组件之间的流动，描述了数据的来源和去向，以及数据在多个处理过程中的转换。数据在产生、处理、流转到消亡过程中形成类似人类社会的亲缘关系，也形象地称为数据血缘。根据抽象粒度的不同，数据流可以描述不同层级数据模型如主题域、业务实体、乃至字段属性级的映射关系。数据流反映的是数据和数据处理过程中的动态关系。
图数据模型用节点表示对象，有向边表示对象间的关联关系，包含数据和数据处理过程的数据流非常适合用图数据模型进行建模，具体方式如下图所示：
1．数据节点：表示数据存在形式的抽象，包括数据库表、文件、系统接口、信息流或其中的字段。
2．事件节点：表示业务逻辑的抽象，包括流程处理、数据加工等任何业务功能。
3．数据节点指向事件节点的边：表示事件对数据的消费，数据是事件的输入。
4．事件节点指向数据节点的边：表示事件对数据的生产，数据是事件的输出。
5．数据节点指向数据节点的边：表示数据间的包含、引用等关系。
6．事件节点指向事件节点的边：表示事件间的调用等关系。
图5-2 数据流模型图
数据流模型图将数据流链路中的事件节点和数据节点统一到一个模型图中，具备以下功能。
1．实现模型间的关系发现。通过对节点间有向边的路径遍历，进行数据模型和事件模型间的关系运算，如影响传播和来源追踪等，进而发现关联关系。
2．提供多领域视图。数据资产管理领域主要关注处于组织边界的数据节点，而数据开发领域主要关注事件节点和处于系统边界的数据节点。
3．提供多粒度视图。通过上卷下钻在系统级、表级、字段级等多种粒度下的数据流模型间切换。浅灰色背景框表示某个系统的边界，在此边界内所有节点归属为上级数据节点或事件节点，可上卷收拢至更粗粒度的数据流。虚线表示下级数据节点和事件节点间的关联关系，可下钻展开为更细粒度的数据流。
数据模型和数据流从静态视图和动态视图描述了组织的数据架构，可以提供数据资产目录梳理、元数据分析、ETL任务调度，数据中台服务优化、应用运维等级评估等一系列的元数据应用服务。
（二）建立数据资产目录
良好的数据资产管理是实现数字化转型，释放数据要素价值的关键。中国信通院发布的《数据资产管理实践白皮书》将数据资产（Data Asset）定义为由组织合法拥有或控制，以电子或其他方式记录，可进行计量或交易，能直接或间接带来经济效益和社会效益的数据资源[4]。而数据资产目录，通常也被称为数据目录或数据资源目录，是数据资源的分类组织清单，包括了数据资源的业务定义、存储位置、数据结构、各数据之间的关联关系等，使用户可以快速、精确地查找到自己关心的数据资产。图5-3描述了数据资产的管理架构，元数据管理是数据资产管理活动的基础支撑，数据资产目录是数据资产管理的起点，同时也是需要不断补充完善的目标，元数据则是建立数据资产目录的来源依据。
图5-3 数据资产管理架构
基于元数据建立数据资产目录的主要步骤包括：
1．数据资产盘点：从数据流图的组织边界和系统边界识别数据的来源和提供的数据服务，从对数据维护和引用的事件识别组织内的主数据，甄别组织核心数据资产主体，通俗来说就是摸清”家底”。2．目录框架设计：参考行业数据模型如金融行业FS-LDM，根据概念数据模型和业务流程，对数据资产进行多维度多层级主题模块划分。
3．数据标签设计：结合企业战略和经营目标，形成组织特色的数据安全等级、数据共享、数据属主、业务画像等数据标签。
4．数据资产标签化：数据目录中的资产与数据标签形成多对多的网状关联体系，便于数据检索。数据资产目录的组织通常采用分层结构，如图5-4，华为将数据资产目录分为5层[5]：
L1为主题域分组，是公司顶层信息分类，通过数据视角体现公司最高层面关注的业务领域。
L2为主题域，是互不重叠数据的高层面的分类，用于管理其下一级的业务对象。
L3为业务对象，是业务领域重要的人、事、物，承载了业务运作和管理涉及的重要信息。
L4为逻辑数据实体，是指描述一个业务对象具有一定逻辑关系的数据属性集合。
L5为属性，是描述所属业务对象性质和特征，反映信息管理的最小粒度。
图5-4 数据资产目录结构
数据资产目录在宏观层面为组织提供了数据资产的整体视图，使数据资源信息统一、详尽、透明，降低了“找数据”的沟通成本，为数据的使用和大数据挖掘提供了支撑。数据资产目录的设计模型是业务层级的数据标准，所以其本身也是一种元数据的应用，数据资产的梳理过程即是构建元数据的过程。
（三）血缘分析和影响分析
血缘分析是指查找数据的上游输入来源和生产加工过程。在实际使用报表和数据分析过程中经常遇到的场景包括：1、多个数据指标不一致，无法判断正确结果。2、对计算结果存有疑虑，要求获得原始数据进行验证。这些问题的根源是数据流路径对于最终用户而言是“暗箱操作”，用户需要追溯数据来源和统计口径，以便快速定位和找到数据问题的原因，最终确信数据处理结果。
图5-5 元数据血缘分析
如图5-5所示，在数据流模型下，血缘分析通常从目标节点出发向前追溯，经过输入和输出有向边能够到达目标节点的所有路径组成了该节点的血缘关系图。血缘分析图展示了数据仓库系统中，全流程定期报送灵活查询事实表所依赖的所有数据来源和处理作业。路径上的数据节点和事件节点及其关联关系清晰的描述了数据处理加工的完整过程。
影响分析是指查找数据的下游输出目的对象和消费处理流程。系统的升级改造和问题处理中，常见的问题是某个数据源或业务流程会对哪些下游系统造成怎样的影响，需要分析数据的去向和传播路径。
图5-6 元数据影响分析图
影响分析通常从目标节点触发向后遍历，经过输入和输出有向边能够到达的所有路径组成了该节点的影响关系图。图5-6影响分析图展示了数据仓库系统中，基于登记系统提供的登记请求流水加工生成的所有目标结果。
血缘分析和影响分析打通了数据来源至数据集成平台至最终输出数据产品之间的链路，可以对数据和事件的出入度、引用频率进行量化，实现对数据价值的评估，不仅仅适用于数据仓库等OLAP系统，同样适用于OLTP类业务系统。
（四）调度ETL任务
ETL任务调度是指有序地控制ETL数据处理任务启动和运行。ETL任务调度最核心的部分是表示和处理作业之间的依赖关系，使得作业在满足必要前置条件下尽可能早地并行处理，否则可能引起数据错误（如未完成输入更新导致输出结果不一致）和运行错误（如对同一数据对象同时进行读写操作导致事务冲突或死锁），一般采用有向无环图（DAG）工作流作为作业调度模型。
在数据流图中，作业间的依赖关系体现为前置作业的输出结果是后继作业的输入，ETL任务的启动只需依赖其直接前置作业的完成。从数据流图系统边界的事件节点出发，沿着输入边能到达的路径上所有事件节点及由路径遍历顺序生成的表示事件节点间后继关系的有向边，即组成了ETL任务调度所需的DAG工作流。
图5-7 作业依赖关系
数据仓库系统可逐步从现有的自动化作业调度系统control-m直接调度原子作业模式过渡到调度总控作业，减少因数据仓库系统原子作业变更导致的调度系统变更，降低系统耦合性，减少操作风险，实现基于元数据的自动化调度。
六、元数据管理
元数据管理是指识别、采集、存储元数据的计划、实施和控制活动，用以确保元数据的质量,使组织能一致地定义数据并使用元数据服务满足业务需求[2]。元数据是数据治理的基石，数据治理首先就要管理元数据，当元数据定义清晰，设计合理，数据质量必然随之提升。
（一）元数据管理的挑战
尽管越来越多的组织意识到元数据管理的重要性，但是在实际的数据治理工作中，元数据的特性使其管理工作仍面临着很多困难和挑战。
1．分散性。元数据也是一种数据，散落在各个不同时期独立建设的业务流程、信息系统中，天然地形成信息孤岛，且形式繁多，种类各异，质量参差不齐，也需要数据治理。
2．局部性。每个人都只是组织中的一环，看的的是不同层面、不同阶段、不同维度的元数据，对其他元数据难以理解，如产品、运营、开发、运维角色有各自关注的元数据，拥有不同层面的数据知识，但是没有人能掌握完整的元数据。即便建设有元数据管理系统，绝大部分情况下只有少部分IT人员使用，很少甚至完全没有尝试在整个组织中使用和推广集中化的元数据，这在一定程度上限制了组织数据资产的共享或重用。
3．偏离性。元数据对数据描述的准确性存在偏差。获取元数据的方式主要包括正向设计和逆向工程。正向设计是指,从业务需求出发定义元数据，缺点是随着需求细化和变更，元数据无法完全从一开始设计完善，存在设计和最终实现存在客观偏差。逆向工程是指从业务流程和系统现状出发梳理元数据，目前大部分场景采用这种模式，缺点是工作量大，难以维护。元数据的识别是一个迭代的过程，往往两种模式兼有并存，如果不与实际生产过程相结合，元数据很容易荒芜废弃，如同数据一样，需要形成质量管理闭环。
4．多样性。正如元数据有多种表现形式，元数据没有统一的标准，即便使用相同的元模型进行设计，实现同一目标的元数据也不是唯一的，并没有绝对正确的标准答案，元数据的设计很大程度上依赖于方法论和最佳实践。
（二）元数据管理成熟度
元数据管理成熟度大致可分为以下五个层级：
1．初始级
元数据的管理是随机的。元数据分散于日常的业务和职能管理中，仅在局部范围使用。元数据的识别和定义极度依赖个人工作需要和工作方法，元数据知识很难共享和保存，一旦当事人工作调动，这些元数据将永远消失。
2．定义级
随着业务流程或信息系统的复杂度提升，人们开始普遍感知到元数据信息的重要性。元数据开始在业务规章、需求分析和概要设计等文档以及信息系统设计开发中被定义，并在同一单元模块的相关人员中共享，但总体仍处属于竖井模式，跨系统和业务条线的互通互联非常困难。
3．管理级
开始制定组织级的元数据管理办法，开展计划的集中采集和管理。业务分析员、数据拥有者和应用开发者开始能够自觉地将元数据信息加载到中央知识库中。元数据在整个组织层面可被感知和搜索，极大地方便了组织获取和查找元数据。局部业务单元或开发小组如不通知元数据的各个关联方，将不能按照自己的想法对业务流程和系统进行单独修改。但元数据还未标准化，各项元数据之间主要还是通过手工方式进行映射，元数据的识别很大程度依赖基于现状的逆向工程。
4．驱动级
组织具有较完整的顶层设计和规划，建立了较完整的元数据体系和元数据规范，能够使用统一的元模型制定组织级元数据，跨系统跨业务领域的元数据关联关系较为完善，数据集成、流转成本显著降低。元数据管理成为一项常规工作，业务流程、信息系统设计开发、数据的生产和消费均遵循事先确定的元数据设计，在元数据的指导下有序开展。
5．优化级
元数据管理是高度自动化的，是业务处理的最关键组成部分。对元数据的定义和修改可自动实现组织范围内的业务流程改造和所需的系统变更。通过对元数据的分析和调整，可以持续优化各项业务流程，实现数字化业务转型。
以上五个元数据管理的层级成熟度依次递进，但各层级间的界限不是绝对的，不同领域的元数据也可能处于不同的层次。参照模型可以帮助组织评估其元数据管理能力，并根据业务需要制定路线图实现元数据管理水平的提升。
（三）元数据管理工具
高效的元数据管理离不开数字化工具的支持。三十年前，数据资产可能是数据库中的若干张核心业务表，如今企业拥有一系列令人眼花缭乱的不同类型的数据资产，包括关系数据库或 NoSQL 存储中的表、实时流数据、数据中台的指标和服务等。应对元数据管理的困难和挑战，也出现了许多元数据管理工具帮助数据专业人员搜索、发现、定义、共享和访问数据知识，比较典型的元数据管理工具有Apache Atlas、Linkedin的DataHub和国内亿信华辰的EsPowerMeta，普元的MetaCube等。
Apache Atlas是Hadoop大数据生态体系下开源的数据治理和元数据框架，与各种 Hadoop 组件具有广泛的集成。主要架构包括：
1．底层采用JanusGraph作为图存储引擎。
2．核心层提供元数据的获取与导出，类型系统和图形引擎等核心功能，支持从HBase、Hive、Sqoop、Storm、Kafka等各种源获取元数据，支持用户自定义和管理元数据模型和元数据对象，支持字段级别的数据血缘追溯。
3．接口层提供丰富的REST API和消息传递接口进行外部集成。
4．应用层具有优秀的UI支持，以图形化方式展示元数据，为Hadoop集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。Atlas因其支持横向海量扩展、良好的集成能力和开源的特点，在行业中逐渐普及或对其进行二次开发，社区活跃度较高。
亿信华辰的EsPowerMeta是基于B/S架构的元数据管理平台，其整体框架分为数据源层、采集层、数据层、功能层和访问层，主要功能特性包括：
1．内置丰富的适配器，提供各种数据库、ETL工具、报表工具和各类结构化或半结构化数据源的元数据自动化采集。
2．基于CWM（公共仓库元模型）标准扩展元模型，提供管理接口实现自定义扩展。
3．支持元数据的全文搜检索和图形化展示，提供血缘分析、影响分析、全链分析、关联度分析、属性差异对比分析等丰富的元数据分析应用。
基于数据平台的元数据管理相对成熟，也是业界最早进行元数据管理的切入点，但各个解决方案还没有明确提出一个完整的管理模式，更多的是对特定的局部元数据的管理。当前各类元数据管理系统的大部分功能集中在对各种数据源的适配和对ETL程序的自动分析，以及元数据的模型表示和查询应用，很大程度上减少了人工识别作业元数据的繁琐工作，但还较少涉及各元数据间的关联关系表示，缺乏与业务系统集成的管理流程，这也将成为元数据管理工具今后的重点发展方向。
（四）元数据管理实践
1.企业级数据管理
在元数据管理的探索和实践中，国家开发银行总结提出的“基于元数据管理实现企业级数据管理”[6]的实施方法具有较典型的借鉴意义。
国家开发银行于2009年启动元数据管理工作，逐步形成以管理办法为指导、数据标准为保障、系统支持为手段的元数据管理体系。一是发布元数据管理办法，规定了元数据管理的范围、内容和流程，明确了元数据设计、开发、采集和使用各环节的相关方责任，制定了IT系统新建和变更时的元数据审批流程，对元数据管理工作的有效开展提供了重要指导和规范。二是制定并执行数据标准，实现数据标准的动态闭环管理。一方面在元数据设计过程中落地数据标准，在数据模型上线前通过元数据审核功能检验数据标准落地情况；另一方面，通过元数据的设计发现标准的缺失和不足，从而推动标准的制定与完善，截止2014年就已完成 1735 项标准落地，标准实施覆盖了90%以上的业务以及全部关键IT系统。三是建设以元数据管理、数据标准管理和数据质量管理为主要功能的数据管理系统，实现了对重要生产系统、ODS 和数据仓库、部分管理分析类系统的元数据采集与管理，支持全行数据模型审批、数据标准和数据质量考核等工作。
2.监管数据标准化
2019年12月30日，中国银保监会正式发布新版的信托业监管数据标准化规范，业内俗称信托EAST4.0，其核心由一系列元数据构成，是金融行业通过元数据进行数据管理的一项重要实践。
数据架构层面：用架构图描述数据来源和数据整体流向，探索统一报送路径，逐步构建、优化标准化监管数据体系，通过统一数据源和填报口径，解决多头报送、数出多源等问题，通过数据流向和关联关系分析开展交叉校验和总分核验，提高数据质量。
6-1 数据架构图
数据模型层面：用实体关系ER图表示数据结构。信托监管标准化起源于银行监管数据模型，在演化过程中舍弃了不适用部分，增加体现信托业务特色的业务实体和属性，主要包括信托产品、会计、募集和运用等板块。通过设计关键属性和主外键关系，如交易对手实控人和所属集团、金融产品关联项目等，使得关联方和资金来源投向穿透成为可能，为信托监管、信息统计和行业自身风险管理提供了理论基础。
数据标准层面：采用层级结构描述数据表、数据项和数据元，其中数据元标准优先遵循银保监体系下监管数据标准，特别是公共数据标准和客户数据标准，在同一监管体系下的数据元实现统一，使得跨行业跨系统的关联分析更为方便和准确。
6-2 数据标准层次结构
技术接口层面：用规范文档描述文件组织结构，数据格式，信息保护，采集模式，报送方式等，实现系统对接和自动化。
数据质量层面：基于数据模型和数据标准生成约4000项数据检核规则，定期进行数据质量审核和更正，开展数据治理专治活动，累计揭示2000余项数据质量问题。
行业治理层面：相对于银行证券，信托产品非标准化特点突出，业务发生频率较低，信息化程度较弱，手工台账依赖程度高，数据质量较差，监管数据标准化规范制定的元数据可帮助行业完成业务数字化建设，有助于促进提升信托行业信息科技水平和数据治理能力。
结束语
元数据是数据资源的设计模型和应用操作指南，也是业务、技术、管理的统一，是实现数据集成和复用、业务流程构建和完善、技术开发的统一指导即数据中台、业务中台和技术中台的基石。元数据管理在识别、记录元数据的基础上，关键是要解决数据模型、数据标准、数据质量、数据安全、数据生命周期、数据服务的贯通问题，进行数据描述层面的信息融合，帮助组织更好地对数据资产进行管理，理清数据之间的关系，实现精准高效的分析和决策。数据的真正价值在于数据驱动决策，元数据管理的未来趋势企业级元数据管理将成为企业信息管理和数字化转型的核心。
任何业务、技术、数据的规范管理过程，在初始阶段梳理工作量巨大，短时间内都会对实际工作造成负面的影响，如审核、维护元数据，优化和重构现有流程系统带来的额外工作，不是所有人都能立刻理解规范化所带来的优点，也需要一定权衡和反复的沟通。元数据的建设不是一蹴而就的，需要慢慢的积累和演变。在实施元数据管理的过程中，应避免过早地盲目追求大而全的目标，坚持应用驱动的原则，以最需要共享的，处于关键业务流程节点和系统交互的主数据所对应的元数据为当前建模和管理的重点，采取增量、渐进的方式逐步提升元数据管理水平。抛砖引玉，仅供参考。
参考资料
[1] GB/T 18391.1-2009 信息技术 元数据注册系统 (MDR) 第1部分：框架[S]. 北京: 中国标准出版社, 2009
[2] 数据管理协会（DAMA国际）. DAMA数据管理知识体系指南[M]. 北京: 机械工业出版社, 2020
[3] ISO/IEC 19508:2014(en) Information technology – Object Management Group Meta Object Facility (MOF) Core[S].
[4] 中国信息通信研究院云计算与大数据研究所. 数据资产管理实践白皮书5.0 [R]. 2021: 3
[5] 华为数据之道[M]. 北京: 机械工业出版社, 2020:75-77.
[6] 滕光进. 元数据管理的探索与实践[J]. 金融电子化, 2014(04): 56-58.
文章来源：数据修行微信公众号