元数据是描述数据的数据，用于打破业务和IT之间的语言障碍，帮助业务更好地理解数据。
元数据是数据中台的重要的基础设施，元数据治理贯彻数据产生、加工、消费的全过程，沉淀了数据资产，搭建了技术和业务的桥梁。
一、 华为数据分类管理框架
华为根据数据特性及治理方法的不同对数据进行了分类定义：
(1) 内部数据和外部数据
(2) 结构化数据和非结构化数据。结构化数据又进一步划分为基础数据、主数据、事务数据、报告数据、观测数据和规则数据。
(3) 元数据
华为数据分类管理框架如图所示：
转自大鱼的数据人生公众号，作者歪老师
原文链接：https://mp.weixin.qq.com/s/iAbzMo-cueIErJc_bTHKnQ
contents
目录
数据中台的基础设施-元数据管理方案
01
数据中台的基础设施-元数据管理方案
03
03
关于元数据和元数据管理，这是我的见过最全的解读！
03
《XX集团元数据管理办法》
无论结构化数据，还是非结构化数据，或者内部数据还是外部数据，最终都会通过元数据治理落地。
华为将元数据治理贯穿整个数据价值流，覆盖从数据产生、汇聚、加工到消费的全生命周期。
相较于结构化数据，非结构化元数据管理除了需要管理文件对象的标题、格式、Owner等基本特征和定义外，还需对数据内容的客观理解进行管理，如标签、相似性检索、相似性连接等，以便于用户搜索和消费使用。因此，非结构化数据的治理核心是对其基本特征与内容进行提取，并通过元数据落地来开展的。
非结构化数据的管理模型如图所示：
二、 元数据治理面临的挑战
华为在进行元数据治理以前，遇到的元数据问题主要表现为数据找不到、读不懂、不可信，数据分析师们往往会陷入数据沼泽中，例如以下常见的场景：
- 某子公司需要从发货数据里对设备保修和维保进行区分，用来不对过保设备进行服务场景分析。为此，数据分析师需面对几十个IT系统，不知道该从哪里拿到合适的数据。
- 因盘点内部要货的研发领料情况，需要从IT系统中获取研发内部的要货数据，面对复杂的数据存储结构（涉及超过40个物理表和超过1000个字段）、物理层和业务层脱离的情况，业务部门的数据分析师无法读懂物理层数据，只能提出需求向IT系统求助。
- 某子公司存货和收入管理需要做繁重的数据收集与获取工作，运行一次计划耗时超过20个小时。同时，由于销售、供应、交付各领域计划的语言不通，还需要数据分析师进行大量人工转换与人工校验。
以上场景频繁出现在公司日常运营的各个环节，极大地阻碍了公司数字化转型的进行，其根本原因就在于：
1) 业务元数据与技术元数据未打通，导致业务读不懂IT系统中的数据。
2) 缺乏面向普通业务人员的准确、高效的数据搜索工具，业务人员无法快速获取可信数据。
元数据管理的痛点如图所示：
为解决以上痛点，华为建立了公司级的元数据管理机制：
- 制定了统一的元数据管理方法、机制和平台，拉通业务语言和机器语言。
- 确保数据“入湖有依据，出湖可检索”成为华为元数据管理的使命与目标。
- 基于高质量的元数据，通过数据地图就能在企业内部实现方便的数据搜索。
元数据通常分为业务、技术和操作三类：
1) 业务元数据：用户访问数据时了解业务含义的途径，包括资产目录、Owner、数据密级等。
2) 技术元数据：实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL规则、集成关系等。
3) 操作元数据：数据处理日志及运营情况数据，包括调度频度、访问记录等。
在企业的数字化运营中，元数据作用于整个价值流，在从数据源到数据消费的五个环节中都能充分体现元数据管理的价值：
2、针对找数据及获取数据难的痛点，明确业务元数据、技术元数据、操作元数据的设计原则。
1）业务元数据设计原则
● 一个主题域分组下有多个主题域，一个主题域下有多个业务对象，一个业务对象下有多个逻辑实体，一个逻辑实体下有多个属性，一个属性有一个数据标准。● 每个数据标准可被一个或多个属性引用，每个属性归属于一个逻辑实体，每个逻辑实体归属于一个业务对象，每个业务对象归属于一个主题域，每个主题域归属于一个主题域分组。
2）技术元数据设计原则
3）操作元数据设计原则● 物理表设计须满足三范式，如为了降低系统的总体资源消耗，提高查询效率，可反范式设计。● 物理表、视图和字段的设计须基于用途进行分类。● 承载业务用途的物理表、虚拟表、视图必须与逻辑实体一一对应，承载业务用途的字段必须与属性一一对应。● 系统间的数据传递须优先采用数据服务。
日志目的不同的进行分类设计，日志目的相同的进行相同设计（非自研场景按软件包适配）。
（1) 数据消费侧：元数据能支持企业指标、报表的动态构建。
（2) 数据服务侧：元数据支持数据服务的统一管理和运营，并实现利用元数据驱动IT敏捷开发。
（3) 数据主题侧：元数据统一管理分析模型，敏捷响应井喷式增长的数据分析需求，支持数据增值、数据变现。
（4) 数据湖侧：元数据能实现暗数据的透明化，增强数据活性，并能解决数据治理与IT落地脱节的问题。
（5) 数据源侧：元数据支撑业务管理规则有效落地，保障数据内容合格、合规。
三、 元数据管理架构及策略
元数据管理架构包括产生元数据、采集元数据、注册元数据和运维元数据：
1) 产生元数据：制定元数据管理相关流程与规范的落地方案，在IT产品开发过程中实现业务元数据与技术元数据的连接。
2) 采集元数据：通过统一的元模型从各类IT系统中自动采集元数据。
3) 注册元数据：基于增量与存量两种场景，制定元数据注册方法，完成底座元数据注册工作。
4) 运维元数据：打造公司元数据中心，管理元数据产生、采集、注册的全过程，实现元数据运维。
5) 元数据管理方案：通过制定元数据标准、规范、平台与管控机制，建立企业级元数据管理体系，并推动其在公司各领域落地，支撑数据底座建设与数字化运营。
华为元数据管理整体方案如图所示：
（一） 产生元数据
1、明确业务元数据、技术元数据和操作元数据之间的关系，定义华为公司元数据模型，如图所示：
2）数据资产编码原则
数据资产编码（DAN）是通过一组数字、符号等组成的字符串去唯一标识华为公司内部每一个数据资产，基于此唯一标识，保证各业务领域对同一数据资产的理解和使用一致，它的设计遵循以下原则：
● 统一性原则：华为公司内部只能使用一套数据资产编码，以方便不同业务部门之间的沟通和IT应用之间的数据交换。● 唯一性原则：每一个数据资产只能用唯一的数据资产编码进行标识，不同数据资产的编码不允许重复，同一个编码也只能对应到一个数据资产上。● 可读性原则：数据资产编码作为数据资产分类、检索的关键词和索引，需要具备一定的可读性，让用户通过编码就能初步判断其对应的数据资产类型。● 扩展性原则：数据资产的编码要从数据管理角度适当考虑未来几年的业务发展趋势，其编码长度要能适当扩展，同时不影响整个编码体系。
3）业务元数据资产编码规则
业务元数据资产编码规则主要包含三个部分：第一部分为主题域分组的编码规则，主题域分组的编码由公司统一分配；第二部分为主题域、业务对象、逻辑实体、属性的编码规则，这部分主要由数据治理平台按照编码规则自动生成；第三部分主要为业务元数据包含的子类对应的数据资产类型代码。
（二） 采集元数据
元数据采集是指从生产系统、IT设计平台等数据源获取元数据，对元数据进行转换，然后写入元数据中心的过程。
元数据的来源可分为如表所示的六类：
3、规范数据资产管理，设计数据资产编码规范
1）数据资产编码规范
华为数据资产编码的主要包括业务元数据和技术元数据两大类，其中业务元数据包含主题域分组、主题域、业务对象、逻辑实体、属性、数据标准；技术元数据包含物理数据库、Schema、表、字段。
具体的定义与描述如表所示：
1）准备度评估项包括如下检查要点
● IT系统名称必须是公司标准名称；● 数据资产目录是否经过评审并正式发布；● 数据Owner是否确定数据密级；● 物理表/虚拟表/视图名。
2）元数据连接需遵从以下规范
● 逻辑实体和物理表/虚拟表/视图一对一连接规范：在业务元数据与技术元数据连接的过程中，必须遵从逻辑实体和物理表/虚拟表/视图一对一的连接原则，如果出现一对多、多对一或多对多的情况，各领域需根据实际场景，参照元数据连接的设计模式进行调整。● 业务属性与字段一对一连接规范：除了逻辑实体与物理表/虚拟表/视图要求一一对应外，属性和非系统字段（具备业务含义）也要求遵从一对一的连接原则，如出现属性与字段匹配不上的情况，可参考元数据关联的设计模式进行调整。
（3）元数据注册方法
元数据注册分为增量元数据注册和存量元数据注册两种场景。
增量场景相对容易，在IT系统的设计与开发过程中，落实元数据的相关规范，确保系统上线时即完成业务元数据与技术元数据连接，通过元数据采集器实现元数据自动注册。
针对存量场景，华为设计了元数据注册的四大模式。在符合元数据设计规范的前提下，进行业务元数据与技术元数据的连接及注册。
模式一：一对一模式
适用场景：
适用于数据已发布信息架构和数据标准且物理落地，架构、标准与物理落地能一一对应的场景。
解决方案：
● 将逻辑实体和物理表一对一连接。● 逻辑实体属性和物理表字段一对一连接。
应用实例：
1）选择适配器
适配器是指针对不同的元数据来源，采用相应的采集方式获取元数据的程序，元数据的来源种类繁多，因而须选择相对应的适配器及元模型。
2）配置数据源
配置数据源是采集元数据的关键，在确定数据源所选择的适配器类型、适配器版本、元模型的基础上，配置数据源的名称、连接参数和描述。
3）配置采集任务
采集任务为自动调度的工作单元，为元数据的采集提供自动化的、周期性的、定时的触发机制。
（三） 注册元数据
大多数企业的数字化建设都存在增量和存量两种场景，如何同时有效地管理这两种场景下的元数据就成了问题的关键。华为通过标准的元数据注册规范和统一的元数据注册方法，实现了两种场景下业务元数据和技术元数据的高效连接，使业务人员能看懂数据、理解数据，并通过数据底座实现数据的共享与消费。
（1）元数据注册原则
元数据注册的原则包括如下三点：
● 数据Owner负责，是谁的数据就由谁负责业务元数据和技术元数据连接关系的建设和注册发布；● 按需注册，各领域数据管理部根据数据搜索、共享的需求，推进元数据注册；● 注册的元数据的信息安全密级为内部公开。
（2）元数据注册规范
通过“元数据注册三步法”完成元数据注册，如图所示：
模式二：主从模式
适用场景：
适用于主表和从表结构一致，但数据内容基于某种维度分别存储在不同物理表中的场景。例如，按时间或项目归档，或按区域进行分布式存储。
解决方案：
● 识别主物理表和从属物理表。● 以主物理表为核心，纵向UNION所有从属物理表，并固化为视图。● 将视图、逻辑实体、字段和业务属性一对一连接。
应用实例：
模式四：父子模式
适用场景：
适用于多个逻辑实体业务属性完全相同，按不同场景区分逻辑实体名称，但落地在同一张物理表的场景。
解决方案：
● 识别一张物理表和对应的多个逻辑实体。
● 将物理表按场景拆分和多个逻辑实体一对一连接。
● 将物理表字段和多个逻辑实体属性一对一连接。
应用实例：
模式三：主扩模式
适用场景：
适用于逻辑实体的大部分业务属性在主物理表，少数属性在其他物理表中的场景。
解决方案：
● 识别主物理表和扩展物理表。● 以主物理表为核心，横向JOIN所有扩展物理表，完成扩展属性与主表的映射，并固化为视图。● 将视图、逻辑实体、字段和业务属性一对一连接。
应用实例：
具体应用实例如图所示
完成元数据注册后，通过元数据中心自动发布。
（四） 运维元数据
运维元数据是为了通过对元数据进行分析，发现数据注册、设计、使用的现状及问题，确保元数据的完整、准确。
通过数据资产分析，了解各区域/领域的数据注册情况，进而发现数据在各信息系统使用过程中存在的问题。
通过业务元数据与技术元数据的关联分析，反向校验架构设计与落地的实施情况，检查公司数据管理政策的执行情况。
主要分为如下四个场景：
● 场景一：基于数据更新发现，数据源上游创建，下游更新；● 场景二：通过数据调用次数发现，某数据源上游调用次数<下游调用次数；● 场景三：虽制定了架构标准，但不知落地情况，比如某个属性建立了数据标准，但是却找不到对应落地的物理表字段；● 场景四：通过物理表的字段分析，发现很多字段缺少数据标准。
四、 元数据与一体化建模管理
华为公司过去长期存在信息架构与IT开发实施“两张皮”的现象，数据人员和IT开发实施人员缺乏统一和协同，数据架构遵从无法进行实质、有效管理，信息架构资产和产品实现的物理表割裂、不匹配，同时各种数据模型资产缺失。
针对应用系统设计应遵从信息架构设计的政策要求，在相关项目、产品的流程中，缺乏显性化的且有实操指导的角色和活动。
信息架构设计大多集中在变革项目层的设计输出和领域层的例行刷新，未与系统落地有效拉通。
IT产品聚焦在版本交付，产品级的数据模型与数据字典缺少有效看护和及时维护。
为了解决这个问题，华为推行了一体化模型设计，不仅在工具上实现了一体化设计和开发，而且在机制上形成了信息架构设计与IT开发实施的有效协同。
通过一体化设计不仅确保了元数据验证、发布和注册的一致性，而且实现了产品数据模型管理和资产可视
同时，由于促成了产品元数据的持续运营，进而能够持续对物理模型进行规范，如整改、清理各类作废表等。
五、 元数据与数据湖管理
（一） 统一的元数据语义层管理数据湖
华为数据湖是逻辑上对内外部的结构化、非结构化的原始数据的逻辑汇聚。
数据入湖要遵从6项入湖标准，基于6项标准保证入湖的质量，同时面向不同的消费场景提供两种入湖方式，满足数据消费的要求。经过近两年的数据湖建设，目前已经完成1.2万个逻辑数据实体、28万个业务属性的入湖，同时数据入湖在华为公司也形成了标准的流程规范，每个数据资产都要入湖成为数据工作的重要标准。
华为数据湖不是一个单一的物理存储，而是根据数据类型、业务区域等由多个不同的物理存储构成，并通过统一的元数据语义层进行定义、拉通和管理。
基于良好的一体化建模架构，不仅可以打通设计和物理实现，而且能够对设计、发布、管理运营等完整生命周期进行融合管理，包括：
● 产品逻辑模型和物理模型一体化设计，元数据管理和数据模型管理融合；● 构建数据标准池，实体属性只能从数据标准池选择；● 产品元数据和数据库自动比对和验证；● 产品元数据发布认证和信息资产打通；● 基于交易侧产品元数据自助入湖。
（二） 元数据与数据入湖
数据入湖是数据消费的基础，需要严格满足入湖的6项标准，包括明确数据Owner、发布数据标准、定义数据密级、明确数据源、数据质量评估、元数据注册。通过这6项标准保证入湖的数据都有明确的业务责任人，各项数据都可理解，同时都能在相应的信息安全保障下进行消费。
是逻辑上各种原始数据的集合，除了“原始”这一特征外，还具有“海量”和“多样”（包含结构化、非结构化数据）的特征。数据湖保留数据的原格式，原则上不对数据进行清洗、加工，但对于数据资产多源异构的场景需要整合处理，并进行数据资产注册。数据入湖必须要遵循6项标准，共同满足数据联接和用户数据消费需求。
1、 结构化数据入湖
结构化数据是指由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。
触发结构化数据入湖的场景有两种：
第一，企业数据管理组织基于业务需求主动规划和统筹；第二，响应数据消费方的需求。
结构化数据入湖过程包括：数据入湖需求分析及管理、检查数据入湖条件和评估入湖标准、实施数据入湖、注册元数据。
(1) 数据入湖需求分析及管理
对于规划驱动入湖场景而言，由对应的数据代表基于数据湖的建设规划，输出入湖规划清单，清单包含主题域分组、主题域、业务对象、逻辑实体、业务属性、源系统物理表和物理字段等信息。
对于需求驱动入湖场景而言，由数据消费方的业务代表提出入湖需求，并提供数据需求的业务元数据和技术元数据的信息，包括业务对象、逻辑实体、业务属性对应界面的截图。
(2) 评估入湖标准
入湖标准包括以下几点。
● 明确数据Owner：为保证入湖数据的管理责任清晰，在数据入湖前应明确数据Owner。● 发布数据标准：入湖数据应有数据标准，数据标准定义了数据属性的业务含义、业务规则等，是正确理解和使用数据的重要依据，也是业务元数据的重要组成部分。
(3) 注册元数据
元数据是公司的重要资产，是数据共享和消费的前提，为数据导航和数据地图建设提供关键输入。对元数据进行有效注册是实现上述目的的前提。
虚拟表部署完成后或IT实施完成后，由数据代表检查并注册元数据，元数据注册应遵循企业元数据注册规范。
2、 非结构化数据入湖
(1) 非结构化数据管理的范围
非结构化数据包括无格式的文本、各类格式的文档、图像、音频、视频等多样异构的格式文件。相较于结构化数据，非结构化数据更难标准化和理解，因而非结构化数据的管理不仅包括文件本身，而且包括对文件的描述属性，也就是非结构化的元数据信息。
这些元数据信息包括文件对象的标题、格式、Owner等基本特征，还包括对数据内容的客观理解信息，如标签、相似性检索、相似性连接等。这些元数据信息便于用户对非结构化数据进行搜索和消费。
非结构化数据的元数据实体如图所示：
都柏林核心元数据是一个致力于规范Web资源体系结构的国际性元数据解决方案，它定义了一个所有Web资源都应遵循的通用核心标准。
基本特征类属性由公司进行统一管理，内容增强类属性由承担数据分析工作的项目组自行设计，但其分析结果都应由公司元数据管理平台自动采集后进行统一存储。
(2) 非结构化数据入湖的4种方式
非结构化数据入湖包括基本特征元数据入湖、文件解析内容入湖、文件关系入湖和原始文件入湖4种方式，其中基本特征元数据入湖是必选内容，后面三项内容可以根据分析诉求选择性入湖和延后入湖。
1）基本特征元数据入湖
主要通过从源端集成的文档本身的基本信息入湖。入湖的过程中，数据内容仍存储在源系统，数据湖中仅存储非结构化数据的基本特征元数据。基本特征元数据入湖需同时满足如下条件。
● 已经设计了包含基本特征元数据的索引表。● 已经设计了信息架构，如业务对象和逻辑实体。● 已经定义了索引表中每笔记录对应文件的Owner、标准、密级，认证了数据源并满足质量要求。
参考都柏林核心元数据，非结构化数据的基本特征类属性元数据规范如表所示。
● 已经确定文件对应的Owner、密级和使用的范围。● 已经获取了文件的基本特征元数据。● 已经确定了关系实体的存储位置，并保证至少一年内不会迁移。
4）原始文件入湖
根据消费应用案例从源端把原始文件搬入湖。数据湖中存储原始文件并进行全生命周期管理。原始文件入湖需同时满足如下条件。
● 已经确定原始文件对应的Owner、密级和使用的范围。● 已经获取了基本特征元数据。● 已经确定了存储位置，并保证至少一年内不会迁移
六、 元数据与数据服务管理
针对数据需求，规范数据服务识别过程，列出数据服务识别过程需要了解的关键内容，明确数据服务的实现方式和准入条件，提高数据服务的可复用性，减少重复建设，如图所示。
2）文件解析内容入湖
对数据源的文件内容进行文本解析、拆分后入湖。入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储解析后的内容增强元数据。内容解析入湖需同时满足如下条件。
● 已经确定解析后的内容对应的Owner、密级和使用的范围。● 已经获取了解析前对应原始文件的基本特征元数据。● 已经确定了内容解析后的存储位置，并保证至少一年内不会迁移。
3）文件关系入湖
根据知识图谱等应用案例在源端提取的文件上下文关系入湖。入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储文件的关系等内容增强元数据。文件关系入湖需同时满足如下条件：
（二） 设计质量度量与元数据为确保设计质量标准稳定，从信息架构的四个角度（数据资产目录、数据标准、数据模型、数据分布）进行综合评估，其范围覆盖度量期间内已通过IA-SAG评审发布的所有数据资产。当实际业务有例外场景时，可向IA-SAG专业评审团申请仲裁，若评审通过，则可采用白名单的方式进行管理。（1）数据资产目录1）业务对象需有明确、唯一的数据Owner，并对该业务对象全流程端到端质量负责，如是否有定义数据质量目标、是否有数据质量工作规划等。2）业务对象的元数据质量，如数据分类是否完整、业务定义是否准确、数据管家是否有效等。3）资产目录完整性。（2）数据标准1）数据标准元数据质量，如数据标准是否唯一、业务用途及定义是否准确、各责任主体是否有效等。2）所有业务对象应准确关联数据标准。
3）数据标准在IT系统及其对应的业务流程中应得到应用和遵从
1）分析数据服务需求：通过数据需求调研与需求交接，判断数据服务类型（面向系统或面向消费）、数据内容（指标/维度/范围/报表项）、数据源与时效性要求。
2）识别可重用性：结合数据需求分析，通过数据服务中心匹配已有的数据服务，判断以哪种方式（新建服务、直接复用、服务变更）满足业务需求。对于已有数据服务，必须使用服务化方式满足需求，减少数据“搬家”。
3）判断准入条件：判断服务设计条件是否已具备，包括数据Owner是否明确、元数据是否定义、业务元数据和技术元数据是否建立联接、数据是否已入湖等。
七、 元数据与构建数据地图
在解决数据的“可供应性”之后，企业应该帮助业务更便捷、更准确地找到它们所需要的数据，这就需要打造一个能够满足用户体验的“数据地图”。
（一） 数据地图的核心价值
数据供应者与消费者之间往往存在一种矛盾：供应者做了大量的数据治理工作、提供了大量的数据，但数据消费者却仍然不满意，他们始终认为在使用数据之前存在两个重大困难。
1）找数难
企业的数据分散存储在上千个数据库、上百万张物理表中，已纳入架构、经过质量、安全有效管理的数据资产也会超过上万个，并且还在持续增长中
。例如，用户需要从发货数据里对设备保修和维保进行区分，以便为判断哪类设备已过保（无法继续服务）提供准确依据，但生成和关联的交易系统有几十个，用户不知道应该从哪里获取这类数据，也不清楚获取的数据是否正确。
2）读不懂
企业往往会面对数据库物理层和业务层脱离的现状，数据的最终消费用户无法直接读懂物理层数据，无法确认数据是否能满足需求，只能寻求IT人员支持，经过大量转换和人工校验，才最终确认可消费的数据，而熟悉物理层结构的IT人员，并不是数据的最终消费者。例如，当需要盘点研发内部要货情况的时候，就需要从供应链系统获取研发内部的要货数据，但业务用户不了解该系统复杂的数据存储结构（涉及超过40个表、1000余个字段），也不清楚每个字段名称下所包含的业务的含义和规则。
企业在经营和运营过程中产生了大量数据，但只有让用户“找得到”“读得懂”，能够准确地搜索、便捷地订阅这些数据，数据才能真正发挥价值。数据地图（DMAP）是华为公司面向数据的最终消费用户针对数据“找得到”“读得懂”的需求而设计的，基于元数据应用，以数据搜索为核心，通过可视化方式，综合反映有关数据的来源、数量、质量、分布、标准、流向、关联关系，让用户高效率地找到数据，读懂数据，支撑数据消费。
数据地图作为数据治理成果的集散地，需要提供多种数据，满足多类用户、多样场景的数据消费需求，所以华为公司结合实际业务制定了如图所示的数据地图框架。
1、总则
为了规范和加强集团的元数据管理，提升数据标准化与数据管控能力，持续改善数据质量，制定本办法。
本办法所称元数据，是数据的数据，是数据的业务涵义、技术涵义和加工处理过程的定义，是数据管控的基本手段。元数据可将其按用途的不同分为业务元数据、技术元数据和操作元数据：
1.1 业务元数据主要描述数据业务涵义及应用场景，包括业务及业务延伸定义、业务规则定义，以及数据之间关系、数据所属部门等业务相关信息；
1.2 技术元数据主要描述数据的技术涵义，包括数据库的结构、字段长度、汇总算法、数据库操作系统及服务器名称、版本等技术相关信息；
1.3 操作元数据主要描述数据的加工处理过程，包括源系统名称、源系统类型、目标系统名称、目标系统类型、抽取转换频率、转换规则等操作相关信息。本办法所称元数据管理，是指元数据的定义、收集、管理和发布的方法、工具及流程的集合。元数据管理旨在针对数据全生命周期的各个环节，清晰、完整地勾勒出数据资产的血缘关系视图。
3、元数据采集与检核
XX集团元数据管理办法
02
文章转自数据工程师微信公众号
原文链接：https://mp.weixin.qq.com/s/0dOCrTYI6SlogTpku21p2A
2、元数据管理的组织与职责
2.1 决策机构集团数据治理委员会负责元数据管理的决策，具体职责包括：
2.1.1 审批元数据管理相关办法；
2.1.2 对元数据管理工作的重大事项和争议事项进行决策；
2.1.3 定期听取集团数据治理办公室对元数据管理工作的汇报。
2.2 集团数据治理办公室是元数据管理的责任单位，负责元数据管理工作，具体职责包括：
2.2.1 元数据管理办法的制定、解释和监督；
2.2.2 负责组织、推动和协调元数据管理相关工作，包括元数据采集与检核、元数据发布与维护、元数据使用、元数据变更；
2.2.3 及时采集和维护业务元数据和各信息系统的技术和操作元数据；
2.2.4 检核和监控元数据落地和变更情况；
2.2.5 制定元数据管理整改方案，推动元数据管理问题解决；
2.2.6 总结元数据管理工作，并定期向集团数据治理委员会汇报。
2.3 集团各职能部门或由产业、成员企业代行相关职能的单位作为数据的业务主管部门和使用部门，应对其所拥有的业务元数据进行定义与维护，具体职责包括：
2.3.1 协助集团数据治理办公室采集业务元数据；
2.3.2 明确业务规则，制定数据标准，定义业务元数据；
2.3.3 负责本部门业务元数据的日常维护，确保相关信息系统的业务元数据完整和有效；
2.3.4 提出业务元数据变更申请并配合变更工作。
2.4 各产业集团及直管企业应遵循集团元数据管理原则和要求建立产业集团及直管企业自身的元数据管理组织及职能，组织推动产业集团及直管企业元数据管理工作。具体职责为：
2.4.1 根据集团元数据管理工作要求，制定产业集团及直管企业元数据管理工作方案和管理制度；
2.4.2 组织、推动产业集团及直管企业元数据管理工作的具体实施，包括元数据采集与检核、元数据发布与维护、元数据使用、元数据变更等，并建立高效的元数据管理流程，及时、有效地解决产业集团及直管企业元数据管理相关问题；
2.4.3 负责定期（每月）搜集、整理和分析产业集团及直管企业元数据管理的开展情况和具体问题，并反馈至集团数据治理办公室；对于重大元数据问题或事项，应及时向集团数据治理办公室进行沟通和汇报。
3.1 数据需求描述、数据责任归属、数据标准内容、数据质量规则等均属于元数据的范畴，当新建或修改数据需求、数据认责关系、数据标准及数据质量规则时，应及时备案，采集元数据。
3.2 集团数据治理办公室按照“谁主管、谁提供、谁负责”的原则组织进行元数据的采集，相关职能部门应按照元数据采集要求和标准规范提供元数据信息，并对所提供的元数据信息负责。
3.3 元数据采集需合理规划，尽可能采用自动化手段，以严格保证元数据采集的准确性和元数据采集的效率。
3.4 元数据采集应遵循科学的流程方法，依照以下顺序进行展开：
3.4.1 确定元数据采集范围，分业务、分系统建立自上而下的采集目录；
3.4.2 参考开发文档，熟悉源系统基本框架和层次逻辑；
7、其他
6.4 集团数据治理办公室组织落实变更后的元数据发布。变更发布时应主送变更提出部门等相关部门，并及时更新和记录发布版本作为唯一的最新版本，同时要求保留历史版本信息。
7.1 因违反本办法产生的不良后果或造成损失，视情节按照有关规定追究相关人员责任。
7.2 如果元数据管理工作中出现争议或者分歧，由集团数据治理办公室协调解决。对无法解决的重大争议和分歧，则由集团数据治理办公室上报集团数据治理委员会决策。
7.3 本办法由集团数据治理办公室负责制定、解释和修改。
7.4 各产业集团及下属业态公司/成员企业可参照本办法制定本产业集团或本级机构业务数据管理实施细则并严格执行。
7.5 本办法自印发之日起执行。本办法实施前，公司颁布的相关办法与本办法不一致的，以本办法为准。
4、元数据发布与维护
3.4.3 明确相关人员，对业务模块、技术模块和操作模块区分不同联系人，保证工作顺利进行；
3.4.4 理解业务模型，从数据入手，结合数据进行业务模型的理解。
3.5 元数据采集完毕，集团数据治理办公室对采集的元数据进行检核。
3.6 元数据检核主要针对元数据的一致性和元数据关系的健全性进行检核，并对元数据获取数据源及这些数据源之间的关系进行集中登记管理。
4.1元数据检核通过后，由集团数据治理办公室在全集团正式发布检核确认后的元数据。
4.2 集团数据治理办公室负责已发布元数据的日常维护，包括元数据数量和定义的更新、源数据映射关系的管理及元数据版本的管理等。
4.3 集团数据治理办公室应定期从应用系统中抽取元数据，并与元数据库中的对应信息进行比较，保证元数据维护及时、准确地反映了实际情况的变化。如在检查中发现差异，集团数据治理办公室应出具各类元数据的差异报告，并分发给相关职能部门确认，经确认无误后再进行元数据的更新维护。
5、元数据使用
5.1 集团各职能部门均可向集团数据治理办公室提交元数据查询和使用请求，并经集团数据治理办公室审批通过后，方可进行元数据的使用。
5.2 元数据的使用包括元数据查询、元数据报表以及元数据分析，应区分业务用户、技术用户和IT/操作用户的元数据使用范围，明确其访问控制权限。
5.3 数据的业务主管部门应通过元数据的血缘分析对所负责数据的变动情况进行监测，分析数据变化可能对上、下游数据产生的影响，并及时提示相应的职能部门。集团数据治理办公室应履行日常监督并协调解决跨部门的相关工作事项。
6、元数据变更
6.1 集团各职能部门均可发起元数据变更申请，应向集团数据治理办公室提交需要变更的元数据清单以及变更细节。
6.2 集团数据治理办公室接受元数据变更申请，应考量变更的必要性，并与变更影响相关方开展变更影响分析，变更细节确认后方可批准变更。
6.3 元数据变更批准后，集团数据治理办公室应组织元数据采集，进行元数据质量检核，并通过血缘分析和影响分析，确定与此变更相关的数据对象、数据处理模块和数据流程，形成完整的数据流图及元数据变更说明文档，发送至变更元数据上下游环节的各数据使用部门。
关于元数据和元数据管理，这是我的见过最全的解读！
03
文章转自知乎，作者胤子
原文链接：https://zhuanlan.zhihu.com/p/338658341
本文主要从元数据的定义、作用、元数据管理现状、管理标准和元数据管理功能等方面讲述了我对元数据(Metadata)和元数据管理的认知及理解。
元数据管理
一、元数据的定义
按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。
技术元数据
技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息：
数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
业务系统、数据仓库和数据集市的体系结构和模式；
汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；
由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。
业务元数据
业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息。具体包括以下信息：
- 企业概念模型：这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。
- 多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。
- 业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。
二、元数据的作用
与其说数据仓库是软件开发项目，还不如说是系统集成项目，因为它的主要工作是把所需的数据仓库工具集成在一起，完成数据的抽取、转换和加载，OLAP分析和数据挖掘等。如下图所示，它的典型结构由操作环境层、数据仓库层和业务层等组成。
其中，第一层（操作环境层）是指整个企业内有关业务的OLTP系统和一些外部数据源；第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层；第三层是为了完成对业务数据的分析而由各种工具组成的业务层。图中左边的部分是元数据管理，它起到了承上启下的作用，具体体现在以下几个方面：
如图所示，与元数据相关的数据仓库工具大致可分为四类：
1. 数据抽取工具：
把业务系统中的数据抽取、转换、集成到数据仓库中，如Ardent的DataStage、Pentaho的开源ETL产品Kettle、ETI的Extract等。这些工具仅提供了技术元数据，几乎没有提供对业务元数据的支持。
2. 前端展现工具：
包括OLAP分析、报表和商业智能工具等，如Cognos的PowerPlay、Business Objects的BO，以及国内厂商帆软的FineBI／FineReport等。它们通过把关系表映射成与业务相关的事实和维来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。
3. 建模工具：
为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。
4. 元数据存储工具：
元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（Metadata Repository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间。这些工具包括微软的Repository，Ardent的MetaStage和Sybase的WCC等。
1.元数据是进行数据集成所必需的
数据仓库最大的特点就是它的集成性。这一特点不仅体现在它所包含的数据上，还体现在实施数据仓库项目的过程当中。一方面，从各个数据源中抽取的数据要按照一定的模式存入数据仓库中，这些数据源与数据仓库中数据的对应关系及转换规则都要存储在元数据知识库中；另一方面，在数据仓库项目实施过程中，直接建立数据仓库往往费时、费力，因此在实践当中，人们可能会按照统一的数据模型，首先建设数据集市，然后在各个数据集市的基础上再建设数据仓库。不过，当数据集市数量增多时很容易形成“蜘蛛网”现象，而元数据管理是解决“蜘蛛网”的关键。如果在建立数据集市的过程中，注意了元数据管理，在集成到数据仓库中时就会比较顺利；相反，如果在建设数据集市的过程中忽视了元数据管理，那么最后的集成过程就会很困难，甚至不可能实现。
2.元数据定义的语义层可以帮助用户理解数据仓库中的数据
最终用户不可能象数据仓库系统管理员或开发人员那样熟悉数据库技术，因此迫切需要有一个“翻译”，能够使他们清晰地理解数据仓库中数据的含意。元数据可以实现业务模型与数据模型之间的映射，因而可以把数据以用户需要的方式“翻译”出来，从而帮助最终用户理解和使用数据。
3.元数据是保证数据质量的关键
数据仓库或数据集市建立好以后，使用者在使用的时候，常常会产生对数据的怀疑。这些怀疑往往是由于底层的数据对于用户来说是不“透明”的，使用者很自然地对结果产生怀疑。而借助元数据管理系统，最终的使用者对各个数据的来龙去脉以及数据抽取和转换的规则都会很方便地得到，这样他们自然会对数据具有信心；当然也可便捷地发现数据所存在的质量问题。甚至国外有学者还在元数据模型的基础上引入质量维，从更高的角度上来解决这一问题。
4.元数据可以支持需求变化
随着信息技术的发展和企业职能的变化，企业的需求也在不断地改变。如何构造一个随着需求改变而平滑变化的软件系统，是软件工程领域中的一个重要问题。传统的信息系统往往是通过文档来适应需求变化，但是仅仅依靠文档还是远远不够的。成功的元数据管理系统可以把整个业务的工作流、数据流和信息流有效地管理起来，使得系统不依赖特定的开发人员，从而提高系统的可扩展性。
三、元数据管理现状
由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。当前市场上与元数据有关的主要工具见下图：
招生文案
对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后，通过建立标准的元数据交换格式，实现元数据的集成管理。
5.元数据管理工具：
目前国内的元数据管理工具大概有三类。一是像IBM、CA等公司都提供的专门工具，比如IBM收购Ascential得到的MetaStage，CA的DecisionBase都是如此；二是像DAG的MetaCenter，开源产品Pentaho Metadata，它们不依托于某项BI产品，是一种第三方的元数据管理工具；三是像普元、石竹这样的集成商也有自己的元数据管理工具：普元MetaCube、新炬网络元数据管理系统、石竹MetaOne等。
专门的元数据管理工具，对自家产品兼容较好，一旦涉及跨系统管理，就不尽如人意了。从国内的实际应用来看，DAG的MetaCenter这一工具使用最多，目前所看到的在电信、金融领域建设的元数据管理项目基本上都是应用了这一产品。
我从互联网上搜索了几乎所有的元数据厂家：Pentaho开源的MetaData产品，支持源码下载试用，可以进行集成开发；普元MetaCube下载后，配置麻烦，目前为止还没有调通；其他公司产品均不提供下载试用。
四、元数据管理标准
没有规矩不成方圆。元数据管理之所以困难，一个很重要的原因就是缺乏统一的标准。在这种情况下，各公司的元数据管理解决方案各不相同。近几年，随着元数据联盟MDC（Meta Data Coalition）的开放信息模型OIM（Open Information Model）和OMG组织的公共仓库模型CWM（Common Warehouse Model）标准的逐渐完善，以及MDC和OMG组织的合并，为数据仓库厂商提供了统一的标准，从而为元数据管理铺平了道路。
从元数据的发展历史不难看出，元数据管理主要有两种方法：
对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库。
目前OMG家的CWM（Common Warehouse MetaModel）标准已成为元数据管理界的统一标准：
OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型（Common Warehouse Metamodel）的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换。2001年3月，OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的：
UML：它对CWM模型进行建模。
MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。
XMI（XML元数据交换）：它可以使元数据以XML文件流的方式进行交换。
OMG元数据知识库体系结构如下图所示。
指标一致性分析
指标一致性分析是指用图形化的方式来分析比较两个指标的数据流图是否一致，从而了解指标计算过程是否一致。该功能是指标血缘分析的一种具体应用。指标一致性分析可以帮助用户清楚地了解到将要比较的两个指标在经营分析数据流图中各阶段所涉及的数据对象和转换关系是否一致，帮助用户更好地了解指标的来龙去脉，清楚理解分布在不同部门且名称相同的指标之间的差异，从而提高用户对指标值的信任。
3. 辅助应用优化
元数据对数据系统的数据、数据加工过程以及数据间的关系提供了准确的描述，利用血缘分析、影响分析和实体关联分析等元数据分析功能，可以识别与系统应用相关的技术资源，结合应用生命周期管理过程，辅助进行数据系统的应用优化.
4. 辅助安全管理
企业数据平台所存储的数据和提供的各类分析应用，涉及到公司经营方面的各类敏感信息。因此在数据系统建设过程中，须采用全面的安全管理机制和措施来保障系统的数据安全。
数据系统安全管理模块负责数据系统的数据敏感度、客户隐私信息和各环节审计日志记录管理，对数据系统的数据访问和功能使用进行有效监控。为实现数据系统对敏感数据和客户隐私信息的访问控制，进一步实现权限细化，安全管理模块应以元数据为依据，由元数据管理模块提供敏感数据定义和客户隐私信息定义，辅助安全管理模块完成相关安全管控操作。
5. 基于元数据的开发管理
数据系统项目开发的主要环节包括：需求分析、设计、开发、测试和上线。开发管理应用可以提供相应的功能，对以上各环节的工作流程、相关资源、规则约束、输入输出信息等提供管理和支持。
本文主要从元数据的定义、作用、元数据管理现状、管理标准和元数据管理功能等方面讲述了我对元数据(Metadata)和元数据管理的认知及理解。朋友们有什么建议和补充，欢迎留言或私信我。一键三连！
CWM为数据仓库和商业智能（BI）工具之间共享元数据，制定了一整套关于语法和语义的规范。它主要包含以下四个方面的规范：
CWM元模型（Metamodel）：描述数据仓库系统的模型；
CWM XML：CWM元模型的XML表示；
CWM DTD：DW/BI共享元数据的交换格式；
CWM IDL：DW/BI共享元数据的应用程序访问接口（API）。
五、元数据管理功能
1. 数据地图
数据地图展现是以拓扑图的形式对数据系统的各类数据实体、数据处理过程元数据进行分层次的图形化展现，并通过不同层次的图形展现粒度控制，满足开发、运维或者业务上不同应用场景的图形查询和辅助分析需要。
2. 元数据分析
血缘分析
血缘分析（也称血统分析）是指从某一实体出发，往回追溯其处理过程，直到数据系统的数据源接口。对于不同类型的实体，其涉及的转换过程可能有不同类型，如：对于底层仓库实体，涉及的是ETL处理过程；而对于仓库汇总表，可能既涉及ETL处理过程，又涉及仓库汇总处理过程；而对于指标，则除了上面的处理过程，还涉及指标生成的处理过程。数据源接口实体由源系统提供，作为数据系统的数据输入，其它的数据实体都经过了一个或多个不同类型的处理过程。血缘分析正是提供了这样一种功能，可以让使用者根据需要了解不同的处理过程，每个处理过程具体做什么，需要什么样的输入，又产生什么样的输出。
影响分析
影响分析是指从某一实体出发，寻找依赖该实体的处理过程实体或其他实体。如果需要可以采用递归方式寻找所有的依赖过程实体或其他实体。该功能支持当某些实体发生变化或者需要修改时，评估实体影响范围。
实体关联分析
实体关联分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，从而进一步了解该实体的重要程度。本功能可以用来支撑需求变更影响评估的应用。
实体差异分析
实体差异分析是对元数据的不同实体进行检查，用图形和表格的形式展现它们之间的差异，包括名字、属性及数据血缘和对系统其他部分影响的差异等,在数据系统中存在许多类似的实体。这些实体（如数据表）可能只有名字上或者是在属性中存在微小的差异，甚至有部分属性名字都相同，但处于不同的应用中。由于各种原因，这些微小的差异直接影响了数据统计结果，数据系统需要清楚了解这些差异。本功能有助于进一步统一统计口径，评估近似实体的差异
联系电话：1580-136-5057
地址：北京市朝阳区朝外大街甲6号万通中心D座
网址：www.yeepay.com
投稿：kai.zhao@yeepay.com
增值电信业务经营许可证：陕B2-20210327 | 
陕公网安备 61102302611033号