前言
元数据为描述数据的数据，我这里举一个简单日常生活中的实例。打开手机相册，点开图片可以看到图片的名称，存储路径，分辨率，这些都是这张图片的元数据：描述图片数据的数据。整理阅读了收集的学界业界资料、自己的前两篇笔记，我认为当前我的焦点应该放在企业数据治理这一侧注重实践，而不是学界的图书情报专业理论来挖掘新的研究热点和研究方向。所以说这篇笔记的内容不会聚焦在元数据的定义上（比如图书情报专业，和数据仓库中关于元数据的理论），而是聚焦在企业侧元数据管理和数据治理中元数据的地位与作用上。
这次的笔记从从阿里、网易、华为三家的资料出发。阿里的《大数据大创新：阿里巴巴云上数据中台之道》，网易在极客时间的《数据中台实战课》，华为的《华为数据之道》。本想以华为的理论框架为骨干进行关联，后来发现三家的元数据理论在前因后果上都有蛮大出入的，还是分为三家不同的视角分别介绍最后再在华为的理论里进行收敛。虽然有种种的不同，但是三家的元数据理论从本质和目的来说都是相同的，这里姑且就将这三种理论类比为三相电流。阿里另外有一本《大数据之路》，在技术方面有比较清楚的解释，也有人写了博客，推荐阅读。《大数据之路》这本书中的内容就不包含在本篇文章中了。
阿里
阿里的元数据理念是：元数据是数据资产管理的核心层。
阿里将数据资产管理产品架构抽象为三层：
- 用户访问端与操作端
- 技术端与后台运营端
- 元数据中心
元数据中心位于最底层，是对上层进行支撑的核心层。另外两层不是元数据理论的重点这里就不作展开了。在介绍元数据中心前，这里先介绍一下阿里的数据治理体系中，和元数据相关的理论。需要注意的是阿里在理论中的一些地方没有给出实例，所以我也不做过多的解读，而是在后文别家理论给出的实例的地方再进行比较解读。
OneData体系方法论
OneData，OneEntity，OneService 是阿里2016年推出数据中台、数据治理概念的核心方法论。阿里对 OneData 的中文定义是“统一数据建设与数据资产化管理能力”，作为体系方法论在2012年6月被提出，在2014年进入了阿里高层的视线。 OneData 体系简单来说就是让数据只被加工一次从而做到统一建设与管理，由此让数据成为资本而非成本。顺带一提 OneEntity 体系致力于统一实体，让数据融通而非以数据孤独形式存在；OneService 体系致力于统一数据服务，实现数据复用而非复刻。
OneData 体系方法论包括数据标准化、技术内核工具化、元数据驱动智能化3个方面。
数据标准化
从源头实施数据标准化，而非在数据研发之后，基于数据指标梳理的数据字典实施数据标准化。只有每一个数据是唯一的，数据模型才能稳定可靠，数据服务才能靠谱可信。
技术内核产品化
所有的规范标准需要有一个全流程的工具作为保障才能实现真正意义上的全链路畅通。技术内核全面工具化非常重要，
元数据驱动智能化
在源头对每个元数据进行了规范定义，尽可能实现数据的原子化和结构化，并将其全部存在元数据中心里。这些元数据对于计算、调度、存储意义非凡，有望实现数据业务的半自动化和智能化。
数据资产管理
OneData 的核心目标是让数据由成本成为资本，核心手段是让数据只被加工一次。阿里在实现 OneData体系中经理了“存储治理”，“资源治理”，“数据资产管理”三个阶段。前两个阶段和元数据理论关联并不大就不展开介绍了，大致就是以成本管理为出发点，对存储资源和计算资源进行优化，提升资源利用率。元数据管理是实现数据资产管理的重要前提，对于“数据资产管理”阶段，阿里确定了三个重要方向“资产分析”，“资产治理”，“资产应用”进行研究，将流程、经验、标准和规范产品化，最终构建了阿里内部统一使用的数据资产管理平台。这三个方向和元数据理论是弱相关，但是和数据治理的整体目标强相关，所以我这里就简单过一下这三个方向。
资产分析
资产分析帮助用户找到需要的数据，辅助用户完成数据分析生成易懂易读的报告。重点能力是可视化能力，需要做到：
- 资产盘点和评估可视化
- 资产盘点与评估能力构建与开放
- 资产探查和使用高效便捷
资产治理
资产治理包含对数据资产进行现状分析，问题诊断，治理优化，效果反馈的能力和工具。重点能力是智能化，需要做到：
- 治理工具的自动化、智能化
- 治理闭环体系能力完善与开放
- 治理领域的丰富与拓展
资产应用
资产应用的重点在全链路：
- 数据全链路的追踪与溯源
- 全链路保障、监管工具化、产品化
资产应用全链路体系，即“数据血缘”的概念，从数据获取到数据处理再到数据应用让用户清楚地指导各种保障措施和问题所在，以及为何资产应用能够稳定、健康地运行。
对于大多数业务人员而言，数据资产管理的最终目的是将数据与业务结合应用，产生价值回报。不同职责的人员对数据的需求都不同。
对于 CEO 或者业务负责人而言，他们想知道到底有多少数据资产，分布状况如何，ROI(投资回报率)如何，如果当前业务缺乏一些数据，那么该从何处获得这些数据。
对于一线业务人员而言，他们不在乎一共由多少张数据表，只想看会员数据或者某个行业的数据，想要的是可以清晰查看及快速使用数据资产。
对业务负责人及 CTO、CFO 而言，他们关系的是数据资产是否被合理应用到合适的地方，哪些地方应该用数据而没有用数据，哪些地方用数据时所付出的代价太大，即准确评估及合理应用数据资产。
对一线技术人员、技术负责人(特别是 CTO)而言，他们关心的是“是否能用数据治理数据”，即如何用大数据实现智能诊断与高效治理数据资产。
基于这些需求分析，阿里提出了公司统一的数据资产管理产品。产品架构就是这一节开头说到的“用户访问端与操作端”，“技术端与后台运营端”，及底层支撑“元数据中心”。
元数据中心
阿里的元数据中心是自动化、智能化数据资产管理产品的核心部件。“自动化、智能化”体现在低人力的去人工化，实现“自动化、智能化”的重要元素是元数据的丰富程度。阿里的元数据中心包括：
- 数据元数据
- 规范元数据
- 服务元数据
数据元数据是关于数据的详情、计算、存储等情况的元数据；规范元数据是关于数据建设过程中各种指标、模型相关的元数据；服务元数据是关于数据在表或者API等方式提供服务时的各类元数据。
阿里理论总结
在阿里的《大数据大创新：阿里巴巴云上数据中台之道》这本介绍阿里数据中台和数据治理体系的书中，关于元数据的篇幅其实很小也并没有专门的章节段落。我自己整理出的逻辑关系是：
- OneData 是阿里数据中台数据治理概念的核心三驾马车之一。
- OneData 的方法论包括元数据驱动智能化。
- OneData 的核心目标是让数据由成本成为资本。
- 进行数据资产管理是让数据成为资本的最后一步。
- 元数据中心是进行数据资产管理的关键。
也就是说元数据管理是做好数据资产管理的关键；数据资产管理是做好数据治理的关键。不过阿里在书中只是反复阐述了元数据管理的重要性，并没有说元数据具体要如何进行管理。考虑到阿里是国内首家提出数据中台和数据治理概念的大厂，他们的确也没必要把每一步都介绍到那么细节。这一节介绍了阿里数据治理观念中元数据的位置，希望可以为后文中后来居上推出理论体系的厂家做一个引子。同时阿里的这本书我阅读的次数还少，一些关键点可能需要我多读几遍结合实践才能领会到。
网易
网易的元数据理念是：元数据是数据中台的核心组成部分。
极客时间网易的《数据中台实战课》中，理论部分沿用了阿里的体系方法论。作者认为对于阿里三驾马车的体系，经过这么多年很多公司都进行了实践，但很难找出一个准确的定义去描述这些方法论。作者自己的理解是，OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。我觉的这一段很好地补充解释了阿里在书中的描述。
数据中台，数据治理，元数据
数据中台的核心组成部分是数据治理模块。数据治理模块对应的方法论就是 OneData 体系，以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理。
数据治理理论的落地，数据中台的构建需要确保全局指标的业务口径一致。指标的业务口径可以理解为，一个数字是通过哪种途径记录计算获得的。比如说上海今天的气温是27度，就需要明确这个气温是指上海市区区域的平均温度，还是指上海所有气温采集点采集到的平均温度。如果要实现数据只加工一次，就需要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典。而这项工作的前提是要搞清楚这些指标的业务口径、数据来源和计算逻辑。这三项都是元数据。
作者把元数据划为三类：数据字典、数据血缘和数据特征。我这里直接引用作者原文的例子来介绍这三类元数据：
随后还对实现元数据中心功能的产品有所介绍。其实阿里和华为都对自己的平台和产品有所介绍推荐。这里提两个开源的产品，Metacat 和 Apache Atlas，前者擅长管理数据字典后者擅长管理数据血缘。在这篇笔记中就不展开介绍了。这里给一张网易元数据中心的架构图。
作者随后提到了数据治理模块以元数据中心作为基础，提供包括数据地图、数仓设计、数据质量、成本优化以及指标管理的功能及产品。其实就是调用了元数据的数据字典、数据血缘和数据特征来实现对应的指标、模型、质量、成本、安全等治理功能。这里就只简单介绍一下数据地图，因为数据地图可以看作是元数据中心的界面。其他不一一介绍了推荐去极客时间阅读作者的原文。
数据地图
数据地图解决了“不知道有哪些数据？”“到哪里找数据？”“如何准确的理解数据”的问题，是基于元数据中心构建的一站式企业数据资产目录。数据开发、分析师、数据运营、算法工程师可以在数据地图上完成数据的检索，同时数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。当使用者定位到某一个表打开时，会进入详情页，详情页中会展示表的基础信息，字段信息、分区信息、产出信息以及数据血缘。数据血缘可以帮助使用者了解这个表的来源和去向，这个表可能影响的下游应用和报表，这个表的数据来源。数据地图对于提高数据发现的效率，实现非技术人员自助取数有重要作用。当数据开发、分析师、数据运营找到自己需要的表时，在数据地图上可以直接发起申请对该表的权限申请。
网易理论总结
网易在极客时间的《数据中台实战课》中，我整理出的逻辑关系如下：
- 数据中台的核心是数据治理
- 数据治理的中心是元数据
- 元数据通过数据字典、数据血缘和数据特征来实现数据治理的各种功能
网易对于元数据的解析，相比阿里更深入了一步，定义元数据核心的三个部分“数据字典”，“数据血缘”和“数据特征”。随后又阐述了如何通过这三个部分实现数据治理的功能（这部分内容在本篇笔记中没有展开）。数据地图作为元数据中心的界面，解决了“不知道有哪些数据？”“到哪里找数据？”“如何准确的理解数据”的问题，提高数据发现的效率，实现非技术人员自助取数。
华为
华为的元数据理念是：作用于数据价值流的元数据管理。
我想以华为的元数据理论作为收敛的原因是，之前的两家都是互联网公司，而华为用他们自己的话说是“非数字原生企业”，其对元数据的理论与规范也更精细，更普适。之所以叫作用于数据价值流的元数据管理，因为无论是结构化数据还是非结构化数据，或者外部数据最终都会通过元数据治理落地。所以元数据治理覆盖从数据产生、汇聚、加工到消费的全生命周期。
元数据分类
在华为的理论中元数据分为三类：
- 业务元数据
- 技术元数据
- 操作元数据
业务元数据指用户访问数据时了解业务含义的途径，包括资产目录、数据拥有者、数据密级等。简而言之就是可以通过业务元数据了解这些数据隶属于哪一项业务。技术元数据指实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL规则，集成关系等。也就是我们在数据库中可以看到的元数据。操作元数据指数据处理日志及运营情况数据，包括调度频度，访问记录等。
这一套划分方法出自2008年 kimball 的数据仓库理论（Kimball, Ralph (2008). The Data Warehouse Lifecycle Toolkit (Second ed.). New York: Wiley. pp. 10, 115–117, 131–132, 140, 154–155. ISBN 978-0-470-14977-5.）。实际上在2004年 kimball 就提出了元数据可以分为业务元数据和技术元数据。kimbll 认为技术元数据相当于内部元数据，因为其回到了元数据的本身在数据库中的定义（表与字段）。而业务元数据相当于外部元数据，因为是数据存储后额外添加的标签。
需要注意的是这套划分方法和网易的划分方法是不同的。网易的“数据字典”中包含了业务元数据和技术元数据的组成部分，而数据特征中三类元数据的内容都有。我的理解是华为/数仓理论的划分方法注重元数据本身的特性（内部元数据和外部元数据），而网易的划分方法注重元数据在数据治理的应用（使用几类元数据实现治理的功能）。
华为认为元数据管理主要面对的问题是数据找不到、读不懂、不可信，普通业务人员无法准确高效地使用数据搜索工具快速获取可信数据。也就是元数据要打破业务和技术之间的语言障碍，帮助非技术业务人员更好理解业务。这个需要解决的问题和网易描述的数据地图解决的问题是一致的。华为在整本书中并未提到数据成本和资本的关系，书中一开始就将数据作为资产进行描述（“只有构筑一套企业级的数据综合治理体系，才能确保关键数据资产有清晰的业务管理责任”）。在我看来大家的切入点不同，进行拔高升华的点也不同（互联网公司注重数据成为资本，华为注重传统企业数字化转型），但是在落地时解决的事情还是相同的（提高数据发现的效率，实现非技术人员自助取数）。
元数据管理架构
华为将元数据管理架构分为产生元数据、采集元数据、注册元数据和运维元数据四块。
产生元数据
产生元数据我的理解是指在一切元数据相关工作正式开始之前，设定好元数据有哪些、物理表如何设计等相关规范。华为定义产生元数据包含明确元数据模型、元数据设计原则和数据资产管理规范。虽然书里并列为了三项，但是我对书中文本的理解元数据模型是包含在数据资产管理规范中的，元数据模型是数据资产编码规范的模型图。
数据资产管理规范
上图是华为元数据模型，下表（图）是华为数据资产编码规范。图和表结合在一起看。
我比较关注的是数据资产编码规范里表被分为了物理表和虚拟表，而元数据模型里只有物理表。那我的理解虚拟表就是 OLAP 中形成的宽表。从元数据模型里可以看到逻辑实体和物理表是对应的，而属性和字段是对应的。这里我觉得主题域，业务对象和逻辑实体的粒度可能不好把握，华为给的实例是：
- 主题域分组：线索到回款
- 主题域：客户合同
- 业务对象：报价单
- 逻辑实体：报价单头，报价单行
- 属性：金额，数量
不过在之后逻辑实体的实例中，华为是将报价单直接作为逻辑实体，而不是报价单头。报价单作为逻辑实体直接和数据库里的物理表对应。我觉得粒度可能要根据公司的情况把控了吧，因为报价单在一些数据库里可能也是分为多张表存储的，这样一来报价单就是业务对象，具体拆分存储的表在业务概念上就成为了逻辑实体。
数据资产编码（DAN）则是通过一组数字、符号等组成的字符串去唯一标识华为内部每一个数据资产，基于此唯一标识，保证各业务领域对同一数据资产的理解和使用一致，它的设计遵循统一性原则、唯一性原则、可读性原则和扩展性原则，这里就不展开介绍了核心就是要保证各业务领域对同一数据资产的理解和使用一致。以上的这些都是数据，或者说主数据的编码规范原则。书中后续还介绍了业务元数据的编码规则，因为没有实例、篇幅很少所以这里也不介绍了。
元数据设计原则
业务元数据设计原则
一个主题域分组下有多个主题域，一个主题域下有多个业务对象，一个业务对象下有多个逻辑实体，一个逻辑实体
下有多个属性，一个属性有一个数据标准。而每个数据标准可被一个或多个属性引用，每个属性归属于一个逻辑实体，每个逻辑实体归属于一个业务对象，每个业务对象归属于一个主题域，每个主题域归属于一个主题域分组。
其实也就是说业务元数据的数据资产子类从主题域分组向下到属性是属于树形结构，每个子节点拥有唯一的父节点。
技术元数据设计原则
物理表设计须满足三范式，如为了降低系统的总体资源消耗，提高查询效率，可反范式设计。物理表、视图和字段的设计须基于用途进行分类。承载业务用途的物理表、虚拟表、视图必须与逻辑实体一一对应，承载业务用途的字段必须与属性一一对应。系统间的数据传递须优先采用数据服务。
就是数据库的设计，并且要面向业务：和业务元数据中的逻辑实体和属性一一对应。
操作元数据设计原则
日志目的不同的进行分类设计，日志目的相同的进行相同设计（非自研场景按软件包适配）。其实我也不太明白日志能有哪些不同的目的，不都是调度频度访问记录吗。
采集元数据
元数据采集是指从生产系统、IT设计平台等数据源获取元数据，对元数据进行转换，然后写入元数据中心的过程。元数据可以分为如下六个来源。
| 元数据来源类型 | 元数据来源 |
|---|---|
| 关系型数据库 | Oracle、SQLServer等 |
| 建模工具 | ERWin、PowerDesigner等 |
| 数据集成工具 | Datastage、PowerCenter 等 |
| BI报表工具 | Cognos、SQLServer Reporting Services等 |
| 调度工具 | Automation |
| 开发语言及脚本 | Perl（日志方式）、SP（注释方式） |
| 其他 | 元数据采集虚拟库等 |
元数据采集的过程被分为三步：选择适配器、配置数据源和配置采集任务。因为没有实例，所以我的理解就是使用工具或者脚本完成获取元数据后转换写入元数据中心。我的理解是从关系型数据库采集到的就肯定是技术元数据，其他类的元数据根据不同的数据来源和场景进行采集。
注册元数据
采集到的元数据要通过注册元数据才能正式使用，注册元数据的核心部分是将采集到的业务元数据和技术元数据进行连接（我理解是按照产生元数据部分中定下的原则规范进行操作）。大多数企业的数字化建设都存在增量和存量两种场景，如何同时有效地管理这两种场景下的元数据就成了问题的关键。华为通过标准的元数据注册规范和统一的元数据注册方法，实现了两种场景下业务元数据和技术元数据的高效连接，使业务人员能看懂数据、理解数据，并通过数据底座（数据中台等工具平台）实现数据的共享与消费。
元数据注册规范
在华为的元数据注册规范下，通过“准备度评估”、“元数据连接”和“注册发布”完成元数据注册。准备度评估检查IT系统名称必须是公司标准名称；数据资产目录是否经过评审并正式发布；数据Owner是否确定数据密级；物理表/虚拟表/视图名。元数据连接遵从逻辑实体和物理表/虚拟表/视图一对一连接规范和业务属性与字段一对一连接规范。在元数据注册方法中会介绍元数据连接的模式。
元数据注册方法
元数据注册分为增量元数据注册和存量元数据注册两种场景。增量场景相对容易，在IT系统的设计与开发过程中，落实
产生元数据环节制定的规范，确保系统上线时即完成业务元数据与技术元数据连接，通过元数据采集工具实现元数据自动注册。
对于存量场景，华为设计了四种元数据注册模式。这里华为终于给出实例了。业务元数据取名采用的是中文对应业务中的逻辑实体，而技术元数据则是英文表名。
模式一：一对一模式
适用于数据已发布信息架构和数据标准且物理落地，架构、标准与物理落地能一一对应的场景。将逻辑实体和物理表一对一连接，逻辑实体属性和物理表字段一对一连接。
模式二：主从模式
适用于主表和从表结构一致，但数据内容基于某种维度别存储在不同物理表中的场景。例如，按时间或项目归档，或
按区域进行分布式存储。
解决方案是首先识别主物理表（实例中的半成品加工计划）和从属物理表（实例中的半成品加工计划历史）。随后以主物理表为核心，纵向UNION所有从属物理表，并固化为视图（可能这就是技术元数据数据资产子类中的虚拟表）。将视图、逻辑实体、字段和业务属性一对一连接。
模式三：主扩模式
适用于逻辑实体的大部分业务属性在主物理表，少数属性在其他物理表中的场景（和主从模式最大的区别在于，主从模式要求主表从表结构一致）。
解决方案是首先识别主物理表（实例中的计划员主表）和拓展物理表（实例中的计划员部门表和分类类型表）。最后以主物理表为核心，横向JOIN所有扩展物理表，完成扩展属性与主表的映射，并固化为视图。将视图、逻辑实体、字段和业务属性一对一连接。
模式四：父子模式
适用于多个逻辑实体业务属性完全相同，按不同场景区分逻辑实体名称，但落地在同一张物理表的场景。也就是逻辑实体和物理表多对一的情况。解决方案是识别一张物理表和对应的多个逻辑实体，将物理表按场景拆分和多个逻辑实体一对一连接后将物理表字段和多个逻辑实体属性一对一连接。
运维元数据
运维元数据以确保元数据的完整、准确为基础目标，旨在校验元数据管理架构设计与落地的实施情况，检查公司数据管理政策的执行情况。主要可以分为四个场景：
- 基于数据更新发现，数据源上游创建，下游更新
- 通过数据调用次数发现，某数据源上游调用次数<下游调用次数
- 虽制定了架构标准，但不知落地情况，比如某个属性建立了数据标准，但是却找不到对应落地的物理表字段
- 通过物理表的字段分析，发现很多字段缺少数据标准
没有实例我对这一块的内容也不是很能理解，等将来有新见解时候再补充吧。
总结
阿里，网易，华为三家编写的数据治理材料各不相同。阿里最先提出系统的概念，理论停留在框架层面指出了元数据的重要性但是没有说明具体如何落地。网易结合实际数据治理功能需求对于元数据分类有自己的定义，并且给出了场景和实例描述的最清晰。同时网易介绍了很多开源软件的实现方法，有机会可以从这个角度切入再来整理一期元数据的内容。华为以非数字原生企业的角度出发，将理论提炼得最精细，美中不足的是给出的实例很少，内容上感觉有些分配不均衡。这个时候就有些怀念学校时期理科的教科书，对于每一个定义都会给出例题和证明过程，同时还有习题举一反三。面对繁杂的理论体系时，我觉得我们在学习及实践数据治理以及元数据管理时，应该把握住核心动机，而不是为了做数据治理而去数据治理。最后我总结一下元数据管理的目标：通过提高数据发现的效率，实现非技术人员自助取数，来让数据成为可以被复用的资产，而不是无法被复用的成本。这也契合了数据治理的目标“managing data as a strategic enterprise asset”，最终的目的是提升企业的经营状况。
Q.E.D.