【第三部分实施篇】第8章元数据管理

1.1. 概述与关键概念

1.1.1. 元数据的定义
根据国家标准《GB/T 36073-2018 数据管理能力成熟度评估模型》中的定义，元数据是关于数据或数据元素的数据（可能包括其数据描述），以及关于数据拥有权、存取路径、访问权和数据易变性的数据。《GB/T 18391.1-2009 信息技术元数据注册系统（MDR）第1部分：框架》对元数据的解释为，定义和描述其他数据的数据。通俗地讲，元数据就是在具体数据值之外的、描述数据各类属性的内容，是数据的标签、说明书和关系网。它描述数据的背景、含义、来源和关系，让使用者能快速理解并找到所需的数据。

1.1.2. 元数据管理的目标
元数据管理的核心目标是让数据能被看见、被理解、被信任、被管控，最终将数据转变为可管理、可追溯、可复用的企业核心资产。它通过对数据的全面描述，为数据治理各项工作提供统一的上下文和基础依据，打通业务与技术之间的隔阂，支撑高效、安全的数据驱动决策。
(1) 实现数据资源的全面可视
构建企业级数据资产地图，系统化采集和管理分散在各系统中的技术、业务与操作元数据，让使用者能够快速发现和定位所需数据资产，解决“数据找不到”的问题。
(2) 保障数据语义的一致性理解
通过统一的业务术语、清晰的定义和口径说明，确保业务、技术和治理人员对数据的含义与规则有一致、准确的认知，解决“数据读不懂”的问题。
(3) 支撑数据质量与可信度提升
通过血缘分析追踪数据脉络，通过质量规则定义与结果反馈评估数据健康状态，增强数据的可靠性、可追溯性，解决“数据不可信”的问题。
(4) 加强数据安全与合规管控
依据数据分类分级标签实施差异化的安全策略，并结合数据权责关系与访问日志，实现对敏感数据使用的有效监控与审计，保障数据安全合规。
(5) 明确数据权属与管理责任
建立并维护清晰的数据责任人体系，确保每项核心数据都有明确的业务归属和管理职责，为数据治理工作的有效执行提供组织保障。

1.1.3. 关键概念

1.1.3.1. 元数据的类型
基于不同功能在数据管理和业务运营中所扮演的角色及发挥的作用，一般将元数据分为业务元数据、技术元数据和操作元数据。
(1) 业务元数据
业务元数据主要关注数据的内容和状态，包含与数据治理相关的详细信息。业务元数据包括与技术无关的名称、概念定义、主题域、实体和各个属性；每个属性的数据类型和其他特征；业务范围描述、计算公式、算法及业务规则、值域等。主要是面向业务人员从业务视角解释数据的含义和用途。常见的业务元数据主要包括业务定义、数据标准、业务指标、数据质量规则、数据安全级别等。

(2) 技术元数据
技术元数据提供数据的技术细节、存储数据的系统，以及数据在系统内、系统间流转的流程。技术元数据主要面向技术人员，用技术语言从数据库、数据表、字段等几个方面描述数据，让技术人员更加明确数据的存储和结构。技术元数据也可以服务于业务人员，通过元数据厘清数据关系，让业务人员更快速地找到想要的数据，进而对数据的来源和去向进行分析。常见的技术元数据包括数据库名称、字段名称、字段长度、字段类型、约束信息、数据存储类型、数据存储位置等。

(3) 操作元数据
操作元数据描述了数据处理和访问的细节，是描述数据的操作属性。常见的操作元数据包括访问者、数据访问方式、访问限制、数据处理作业的结果、系统执行日志、数据备份时间、数据归档时间等。

1.1.3.2. 元模型及CWM
元模型是元数据库的数据模型，即定义和描述元数据结构的模型。元模型为元数据提供了统一的框架和语法。它定义了组织中有哪些类型的元数据（如业务、技术、操作元数据），这些元数据有哪些属性，以及它们之间如何关联。这就像为数据世界制定了“宪法”，确保大家说同一种语言，数据能够被准确理解和管理。
以华为元模型为例，它由业务元数据、技术元数据和操作元数据组成，其中业务元数据主要包含主题域分组、主题域、业务对象、逻辑实体、属性、数据标准等；技术元数据主要包含数据库、表、字段等；操作元数据主要是各类日志，如用户访问日志、数据库日志等。

表 1 华为元模型示例

CWM(Common Warchouse Metamodel，公共仓库元模型)是OMG（对象管理组织）在数据仓库系统中定义的一套完整的元模型体系结构，用于在不同的数据仓库工具、数据仓库平台和元数据仓库之间进行元数据交换。随着CWM规范的逐渐成熟，CWM的应用不再局限于数据仓库领域。目前，CWM支持以模型驱动的方法进行元数据交换，即根据CWM规范构造共享元数据的统一模型。这些统一的模型与具体产品无关，而是以XML文档的格式进行数据存储和交换。

1.1.4. 与其他模块的关系

1.1.4.1. 元数据与数据仓库
元数据为数据仓库的建设与运营提供蓝图与说明书。它定义了数据仓库中数据的结构、含义、来源与加工逻辑——即哪些数据来自何处（技术元数据），它们代表什么业务含义（业务元数据），以及如何被加工和访问（操作元数据）。数据仓库的构建与使用工作则严重依赖于这份蓝图：ETL开发需遵循元数据定义的数据转换规则，数据模型设计需依据元模型规范，而最终用户则通过元数据来理解和查询数据仓库中的内容。没有准确、完整的元数据，数据仓库就会成为一个难以理解和维护的“数据黑箱”。

1.1.4.2. 元数据与数据模型
元数据是描述和定义数据模型的具体内容与规则。数据模型（尤其是概念模型和逻辑模型）定义了数据的业务实体、属性及其关系，这些定义本身（如实体名称、属性定义、关系说明）就是核心的业务元数据。同时，物理数据模型所对应的数据库表结构，则是技术元数据的主要组成部分。因此，数据模型管理是在概念和逻辑层面创建和维护业务元数据的过程，而元数据管理则将这些模型内容，连同其技术实现和运维信息一并纳入体系进行统一治理和应用。

1.1.4.3. 元数据与数据质量
元数据为数据质量管理工作提供规则定义与上下文。数据质量的评估标准（如完整性、准确性、一致性规则）本身作为业务元数据被定义和管理。数据质量管理工作的开展则严重依赖于这些元数据：质量规则引擎根据元数据中定义的标准执行校验，而质量评估结果（如合格率、问题数据样本）又作为操作元数据反馈回系统，为数据的可信度提供直观标签。没有元数据明确定义“什么是好数据”，数据质量工作就将失去目标和依据。

1.1.4.4. 元数据与数据标准
元数据是数据标准在具体数据资产上的承载与体现。数据标准管理定义了企业关于数据的统一规范（如命名、格式、值域），这些标准是作为一种权威的业务元数据被发布和管理的。数据标准落地工作的本质，就是将标准化的数据元与物理世界中的具体数据库、表、字段进行关联。通过这种关联，元数据系统能够自动获取并展示每个字段应遵循的标准，并驱动后续的质量检查，从而确保标准从定义到执行的闭环。

1.1.4.5. 元数据与数据安全
元数据为数据安全管控提供分类分级依据与策略附着点。数据安全管理的首要步骤是对数据资产进行敏感度识别，其产出——数据分类分级标签，是关键的业务元数据。数据安全控制措施的实施则直接依赖于这些元数据：安全网关和数据库访问控制引擎可以读取数据表的分类分级标签，并自动执行相应的脱敏、行级过滤或访问阻断策略。元数据在这里充当了沟通业务安全要求与技术安全实施的桥梁。

1.1.4.6. 元数据与数据集成
元数据为数据集成工作提供源端与目标端的语义映射关系。数据集成任务需要清晰地知道源数据的结构（技术元数据）、含义（业务元数据）以及如何转换到目标模型，所有这些信息都包含在元数据中。数据集成工作的设计与开发必须严格遵循并实现元数据所定义的映射和转换规则。一个强大的元数据管理系统能够自动生成集成任务的基础代码，并清晰地展现数据在流动过程中的血缘关系，极大地提升了集成工作的效率与可靠性。

1.2. 元数据管理实施指南

1.2.1. 落地思路

通过建立标准化的元模型框架，系统性地集成多类元数据，最终支撑数据治理核心场景的落地应用，实现从被动管理到主动赋能的转变。

图 1 元数据管理落地思路图

(1) 元模型定义
通过元数据需求分析明确业务目标和治理要求，在此基础上定义统一的元模型框架，覆盖业务、技术和操作三类元数据及其关联关系，为后续元数据集成和存储提供标准规范。
(2) 元数据集成和维护
从数据库、数据集成工具、BI工具、文档等各类数据来源自动化采集技术元数据，通过人工和系统结合的方式补充业务和操作元数据，并发布到统一目录中，解决“数据在哪”的痛点。同时建立持续的维护机制来更新元数据，保证其准确性和时效性。
(3) 元数据应用
基于统一的元数据目录，支撑数据发现、影响分析、数据血缘追溯等核心应用场景，实现数据资源的可视化导航、精准定位变更影响范围，使数据可追溯、可分析，推动数据治理能力向智能化、自动化演进。

1.2.2. 实施策略

- 技术先行、分层建设
元数据可以作为整个数据治理的链条，其成果也依赖数据质量、数据标准、数据安全等其他模块的治理成果。
因此元数据管理不宜追求一步到位的大而全方案。更有效的策略是选择当前业务痛点最集中的领域作为突破口，例如从核心的客户数据或财务数据入手，先利用轻量级工具实现这部分关键数据的技术元数据自动采集和业务含义补充，快速搭建起一个可用的“数据查询手册”。这样做能以最小成本验证元数据管理的价值，让团队在几个月内就看到成效。在取得初步成果并积累经验后，再逐步将管理范围扩展到其他业务系统，如同滚雪球一样持续完善，这种务实路径能有效控制风险并保持团队信心。
- 场景嵌入、提升数据可读性
实施元数据管理必须紧贴业务需求，避免陷入纯技术建设的陷阱。策略核心是将元数据能力直接嵌入到业务人员日常的数据查找和使用场景中，例如为解决“找不到客户相关信息”或“看不懂销售报表指标”这类具体问题，提供可通过业务关键词搜索的数据目录和清晰易懂的数据说明。当业务人员发现通过元数据系统能快速解决他们工作中的实际问题时，元数据管理就从一项IT任务转变为提升整体运营效率的支撑工具。
这种以解决实际问题为出发点的方式，能自然形成“使用－反馈－优化”的价值闭环，为元数据管理的持续发展提供内在动力。

1.2.3. 常见挑战与解决方法

- 高维护成本阻碍价值实现
在元数据的实施过程中，需要花费大量的时间来完成元数据的模型定义、采集和维护等任务。如果这些任务多由人工处理，将导致元数据实施周期长、成本高且错误频发。这不仅使管理本身效益低下，更阻碍了元数据的价值实现：无法有效完成复杂的数据血缘与影响分析（手工梳理低效、易错），更无法驱动数据标准、质量与安全策略的自动化落地（人工执行充满延迟和疏漏）等。
因此，元数据管理需要转向以自动化工具为核心的模式。通过多源集成与自动采集的工具，能够无缝适配关系型数据库、大数据平台、国产数据库等多种环境，并有效提取元数据。借此，元数据的维护得以从繁重的手工操作中解放，其核心价值才能逐渐释放，从而构建起事前可预防、事中可干预的高效可信数据治理体系。
- 静态管理模式难以适应动态环境
大数据时代，数据环境本身正变得日益复杂且高度动态化。数据持续流动、转换，其相关的来源、血缘、质量等元数据也时刻变化。如果采用静态或周期性的元数据管理方式，既难以捕获和处理复杂的数据关系，更无法跟上元数据自身的实时变化节奏，比如难以构建实时、准确的企业级数据资产地图。这导致元数据描述滞后、失真，使其无法作为可信的治理依据。
应对这一挑战，需要将管理范式从“人工录入与维护”转向“算法自动识别与生成”，通过嵌入数据生命周期的自动化规则，在数据生成、加工与使用的关键环节实现实时校验、自动打标与主动控制，确保元数据能够实时、准确地反映数据环境的当下状态。

1.3. 元数据管理实施流程

1.3.1. 实施概述

1.3.2. 元模型定义

1.3.2.1. 实施概述
表 2 步骤1 元模型定义实施概述

1.3.2.2. 活动
1.3.2.2.1. 元数据需求分析
元数据需求分析的主要目的是搞清楚“我们需要哪些元数据”以及“谁需要用它来解决什么问题”。通过摸家底阶段与关键用户访谈和梳理核心业务流程，收集并确认元数据的管理需求，确保后续设计的元模型能够切实支撑业务运作和数据治理。避免建设一个脱离实际、无人使用的“元数据空中楼阁”。
(1) 识别利益相关方与应用场景
首先，需要找到元数据的潜在使用者（如数据工程师、数据分析师、数据管家等），了解他们想用元数据来做什么。只有理清了真实的使用场景和核心诉求，才能确保元模型的设计具备实际价值。常见的元数据应用场景就是解决数据找不到、读不懂和不可信问题，以下是几个场景举例。
场景一：数据工程师小李接到任务，需要为新的风控模型寻找所有与“交易行为”相关的数据表。面对成千上万张命名不一的表，仅凭记忆和猜测（如搜索 txn, trade, pay 等）犹如大海捞针，耗费数天时间仍担心遗漏关键数据源，严重拖慢项目进度。
场景二：数据治理团队构建“客户主题库”，需要从十几个业务系统中梳理客户相关数据。面对源端数千张命名不规范的表和上万个技术字段，团队完全无从下手——他们无法快速识别哪些表存储的是客户基础信息、哪些是交易记录、哪些是互动行为，更无法理解各个系统中“客户ID”的关联关系。
场景三：数据运维工程师小张接到业务反馈，称核心报表中的“当日销售额”数据异常偏低。他缺乏对这条数据加工链条的清晰视图，不知道它由哪个任务产出、依赖哪些源表，只能手动翻查多个ETL脚本，排查效率极低，业务方也因此对数据治理成果产生质疑。
(2) 需求整合
在收集到大量应用场景需求后，对其进行归类和整合。将散乱的需求归纳为几个关键的主题，明确每一项需求对应的业务价值、相关方，初步分析所需元数据，为下一步的元模型设计提供直接的输入。

表 3 元数据需求整合模板及示例

1.3.2.2.2. 元模型定义
基于需求分析的结果，设计出组织级的元模型。元模型定义的是空的、标准化的架子，或者说是一套标准的容器。它需要涵盖技术元数据、业务元数据和操作元数据三个维度，将分散的技术、操作数据与业务术语进行关联映射，形成从业务到技术、从源头到消费端的全链路视图。
组织根据每一类元数据来源（如数据库表、ETL工具以及BI工具等），系统地梳理和定义具体元数据项，形成元模型。元模型通常应该遵循标准化的CWM（公共仓库元模型）规范，并结合企业实际进行扩展与裁剪，确保模型兼具通用性与可落地性。

表 4 元模型模板及示例

1.3.3. 元数据集成和变更

1.3.3.1. 实施概述

表 6 步骤2 元数据集成和变更实施概述

1.3.3.2. 活动
1.3.3.2.1. 技术元数据采集
组织的数据环境通常包含成千上万的数据库对象，手动梳理如同大海捞针，不仅工作量巨大、极易出错，且元数据一旦发生变化，手工方式无法及时同步，会导致元数据快速失效。因此，在元数据采集中，自动化工具不是可选项，而是必选项。
(1) 自动化采集
依据定义的元模型，选择并配置合适的元数据采集工具。在工具中配置好需要连接的数据源信息，然后执行自动扫描和采集。工具需要支持连接组织内各种类型的数据源，如关系型数据库、大数据平台、国产数据库等。
需要注意的是，采集任务通常选择业务低峰期或夜间执行，以避免对业务系统造成性能影响。
传统自动化采集工具仅能识别已知格式的技术元数据，对非标准命名的表、字段、隐藏的接口依赖等覆盖不足。此时可以借助AI工具，通过模式识别算法，自动解析数据库注释、SQL 脚本注释等，推断表/字段的业务归属；智能识别跨系统的隐性依赖（如通过 API 调用日志发现未登记的元数据流转关系）等。
(2) 人工筛查
采集到原始元数据后，数据团队需要进行一次快速的人工筛查。核心目标是识别并过滤掉那些明显不需要纳入管理的对象，如表名中包含 test、tmp、temp、backup等的表。通过这一步，可以减少需要管理的元数据规模，让团队将精力聚焦在真正有价值的业务数据上。
(3) 整理未采集的元数据
对于无法通过工具自动采集的技术元数据，则用人工梳理的方式进行补充。数据团队基于摸家底环节梳理的数据资源清单和元模型，形成该部分数据的元数据清单，与自动化采集的部分合并，确保技术元数据的完整性。

1.3.3.2.2. 业务、操作元数据补充
为技术元数据注入丰富的业务属性和上下文信息，形成完整的元数据清单，让数据变得可理解、可信任。这是实现数据业务价值的关键一步，因此还需要通过人机结合的方式补充业务元数据和操作元数据。
业务、操作元数据可通过系统集成的方式获取。将元数据工具与ETL工具、BI工具、数据质量工具、数据开发工具等平台打通，通过API接口或日志解析等方式，定期或实时获取所需信息。
除了系统集成，业务元数据的补充更多地是部门协作的过程。识别出需要补充业务元数据的核心资源，比如重要的基础表、指标字段等。然后请相关业务部门按照数据权属关系补充自身管理范围内的业务元数据，如人力资源和社会保障部门补充HR系统中的元数据。当然，最后还需数据治理团队对补充的内容进行确认，保证元数据的质量。
各部门补全业务元数据的过程通常耗时耗力，还容易出现语义不一致等问题。而AI 工具可以基于组织已有的业务术语库、知识图谱，自动匹配技术元数据（如表名、字段名）与业务概念，推荐对应的业务含义、所属主题域及责任部门等，减少业务人员的大量分析、梳理工作。

1.3.3.2.3. 元数据维护
元数据维护是确保元数据生命力的“运营”环节。它通过建立常态化的流程和机制，应对数据环境的不断变化，保证元数据的准确性、及时性和有效性，使得元数据体系能够持续赋能业务。
(1) 建立分类变更流程
根据采集方式的不同，需要分类设计变更流程。
对于自动采集的技术元数据（如表结构变更），应该依然通过自动化工具实时或定时获取其变更，并记录完整的变更日志，确保与真实数据环境同步。
对于手工维护的元数据（如业务定义、责任人、安全级别），则需要建立标准的申请－审批流程，变更需审批通过后方可生效，确保所有人工调整都是受控和可追溯的。

图 2 元数据变更流程示例

(2) 实施定期审查
建立元数据的定期健康检查机制。可以设置每季度或每半年对核心数据资源的元数据进行核查，由数据管家推动业务责任人共同确认元数据的有效性，识别并解决过期、缺失或不准确的信息。同时，持续监控自动化采集任务的运行状态，确保技术元数据源的稳定性。通过定期审查，能够推动元数据质量的持续提升。

1.3.4. 元数据应用

1.3.4.1. 实施概述
表 7 步骤3 元数据应用及服务实施概述

1.3.4.2. 活动
1.3.4.2.1. 元数据查询
(1) 元数据目录
元数据目录中收录了业务元数据、技术元数据和操作元数据，这是一份完整的数据档案。组织可以基于这份档案，建立起精准、高效的数据检索能力，当数据用户有数据使用需求时，可以通过关键词搜索或条件筛选直接定位目标，并获得全面、准确的数据描述。
需求分析阶段的场景一，数据工程师小李可以通过元数据目录搜索“交易行为”，快速定位到相关数据表，并查看其业务定义、字段含义、来源系统及更新频率等关键信息，快速筛选所有相关数据源。
(2) 数据资产地图
数据资产地图是一个业务视角的导航工具，通过提供一个宏观的数据全景视图，告诉数据用户有哪些数据，在哪里可以找到这些数据，以及数据间的上下游关系。

图 3 数据资产地图示例

1.3.4.2.2. 元数据分析
元数据分析通过深入挖掘元数据之间的关系与模式，将静态的信息转化为动态的洞察，为数据运维、治理和架构优化提供关键决策依据。
(1) 血缘分析
血缘分析就像为数据制作一份详细的“履历”，它清晰地讲述数据来自哪个原始业务系统，具体经历了哪些加工任务，每一步处理都改变了什么，才形成了最终的那个数据表或指标。其价值在于，当发现最终数据有误时，可以沿着它的来路一步步回溯，快速精准地找到问题的根源，是源系统出了问题还是中间的某个加工环节出了差错，从而极大地缩短了排查问题的时间。
血缘分析的实现，通常依赖于采集到的技术元数据和操作元数据，通过解析ETL任务、SQL脚本中的逻辑，提取出“读取了哪个源表”“生成了哪个目标表”这些关键信息，并将这些点串联成完整的加工链路图谱。
(2) 影响分析
影响分析是血缘分析的“反向推演”，它主要用来回答一类重要问题：“如果某个业务系统修改或者删除一张数据表，会‘牵连’到哪些下游的报表、业务系统和关键指标？”它能有效防止因考虑不周导致的业务报表异常或数据服务中断，让每一次系统升级或数据重构都心中有数、安全可控。
其实现机制与血缘分析同源，都是基于已构建好的数据血缘图谱，只不过这次是从某个数据资源出发，去寻找所有直接或间接依赖它的下游对象，并列出详细的影响范围清单。
(3) 冷热度分析
冷热度分析相当于为数据资源贴上“活跃度”标签，它可以通过分析数据被访问的频率、最近一次被访问的时间等操作元数据，来区分出哪些是经常被使用的“热门”数据（如日常监控报表依赖的表），哪些是长期无人问津的“冷门”数据（如已完成项目的归档数据）。这个分析能协助IT团队更高效、集约地管理资源，比如将“冷数据”转移到更便宜的存储上以节省大量成本，同时确保“热数据”拥有高性能的访问路径。
(4) 关联度分析
关联度分析致力于发现数据资源之间的“隐藏关系”，它通常综合外键关系、查询日志以及血缘链路等多种元数据，通过算法计算出一个关联度得分，从而识别出那些在业务上本应紧密关联的数据群体。该分析能帮助数据团队更好地组织数据，比如在构建数据资源目录门户时，将高关联的数据放在一起，方便查找；当数据用户发现一个数据时，也能智能地推荐其他强相关的数据，提升数据发现和使用效率等。

（或访问：https://xcnoejbrkx3v.feishu.cn/drive/folder/HCXufFf6ilq0ejdF5Hmc3CJhnYf）

本书采用了开放式共创的编撰模式。我们坚信，内容的可靠性与实践性来自持续的交流与共创。因此，我们诚挚邀请您——每一位关注数据治理的同行者、实践者与思考者——加入本书的共创计划。

如果您在阅读过程中，提出关键修正、贡献具有借鉴价值的优质案例，或补充了不可或缺的核心内容，我们将诚挚邀请您成为本书的共同署名共创者，并参与后续的专题研讨与行业交流，共同推动数据治理领域的实践进步与生态发展。

愿这本书不仅是一本指南，更是一次连接行业、凝聚共识、共创未来的行动。

【第三部分 实施篇】第8章 元数据管理

【第三部分实施篇】第8章元数据管理