元数据作为大数据背景下被炒热的一个概念，受到越来越多的公司重视，大家都知道它与数据治理有关。但是，到底什么是元数据？你所说的元数据与别人说的元数据是不是一回事？元数据到底在大数据背景下起什么作用？这些问题在网络上搜寻了诸多资料都没有得到理想、完整、权威的答案，也难怪在讨论元数据这一概念时，经常是双方“鸡同鸭讲”。没有相同的语境，就像我们说“小鸡”这个概念一样，对于养鸡场和男生，是完全不同的两种内涵，不统一语境就无法交流。
本系列文章中，通过三个角度即 “特征描述元数据”、“语义结构元数据” 和 “数据仓库元数据” 尝试说清元数据的内涵。可能各位看官无法接受这种划分方法，因为你可能看了很多资料，将元数据分类为结构元数据、保存元数据、技术元数据、管理元数据、业务元数据等等，这个暂且不论，如果看官在看完本系列文章后，认为从“特征描述元数据”、“语义结构元数据”和“数据仓库元数据”三个角度体现的元数据内涵无法囊括你认可的元数据内涵，您不妨留言讨论，共同进步，因为元数据这个概念本身就是多面向的。
特征描述元数据的起源
讨论特征描述元数据的起源，其实就是在讨论元数据的起源。因为元数据这一术语从诞生之初，就是用来进行特征描述的。而且直至目前，很多领域还直接把特征描述元数据简称为“元数据”，尽管在领域内部不会造成问题，但是从全局看，是导致“元数据”内涵混乱的一个直接原因。
一、特征描述元数据是对某个对象的关键特征及生产上下文进行描述形成的信息，形态是一组有特定含义的“值”
图书馆是“元数据”这一术语的诞生地，方便图书的归档和检索是元数据的最初作用。图书作为被管理对象，可被提炼的特征很多，如书名、作者、年代、类型、语种、摘要等，从越多的角度描述一本图书，后期图书管理就越便捷。此场景下，对一本图书而言，这种被提炼出来的描述性信息，如（小鸡历险记，张三，1980，儿童读物，中文，小鸡从养鸡场逃出后周游世界的故事），就是这本书的“元数据（特征描述元数据）”。当然，如果单独拿出“小鸡历险记”这一个字段值，说它是这本书的“元数据（特征描述元数据）”，某些情况下也是可以的。这些图书的“元数据（特征描述元数据）”被记录在“元卡”或者存储在计算机里，极大方便了图书管理和检索工作。
其他很多行业也参考了图书馆元数据（特征描述元数据），设计了自身的元数据，如博物馆行业，对藏品编号、名称、年代、发掘地址、发掘时间等的描述，也可称为藏品的特征描述元数据。
特征描述元数据本质上也是一种数据。那么对于（小鸡历险记，张三，1980，儿童读物，中文，小鸡从养鸡场逃出后周游世界的故事）而言，何种情况下应该被认为是数据，又是何种情况下应该被认为是特征描述元数据呢？这个问题的答案是相对的，如在管理和检索书籍时，这个数据起到了辅助作用，我们可以认为它是“元数据（特征描述元数据）”。而在另外一些场合，如我们利用这些描述性信息进行藏书统计时，这些信息成为了算法操作的直接对象，已经不需明确指向一本图书实体，此时应该被认为是“数据”。两者叫法既统一又对立，差别非常微妙，需要根据实际应用在交流双方之间达成一致。
这里有一点要注意，就是元数据元素和元数据元素的值，如上面的例子中，“书名”这两个字本身代表了元数据元素，“小鸡历险记”是其对应的元数据元素的值。对于“书名”这个元数据元素，它的名字、含义、取值类型、取值范围等，一起规范了这个元数据元素的定义，形成了一个存放值的容器，存放“小鸡历险记”这个值。其他元数据元素与元数据元素的值的关系也是如此。
二、并不是所有的对象特征描述信息都应该被称为特征描述元数据，需要考虑习惯和使用场景
既然认为“特征描述元数据是对某个对象的关键特征及生产上下文进行描述形成的信息”，那“对某个对象的关键特征及生产上下文进行描述形成的信息就是特征描述元数据”这个陈述对不对呢？也就是A->B，是否一定可以B->A，笔者认为答案是否定的。
举个例子，人是一个对象，其关键特征的信息可以是（张三，1980.05.05，男，178，70，410101xxxxxxxxxxxx），分别是姓名、出生日期、性别、身高、体重、身份证号。当（张三，1980.05.05，男，178，70，410101xxxxxxxxxxxx）这个特征信息出现在简历、病历档案这样的文档中时，这些信息主要是用于描述这个人的特征的，这个时候我认为称之为人员元数据是恰当的，而当（张三，1980.05.05，男，178，70，410101xxxxxxxxxxxx）这条数据出现在了一张人员统计报表中，只是作为其中一行数据的时候，这个时候它的作用就不是去描述这个实体对象张三了，而是作为了一条被统计的数据在被使用，这个时候称之为人员数据会比较恰当。
再举个例子，其实上面已经提到过，对于图书的特征描述元数据（小鸡历险记，张三，1980，儿童读物，中文，小鸡从养鸡场逃出后周游世界的故事），当我们利用类似的信息进行图书馆藏书统计时，它也应该认为是“数据”，而非“元数据（特征描述元数据）”，这是使用场景导致的。
如果不考虑使用习惯和使用场景，非要把上面的信息称为“元数据”，就是放纵了“元数据”这一概念的使用，会形成很多匪夷所思的陈述，如，本来已经深入人心的“数据挖掘”、“数据融合”这些概念，就会变成“元数据挖掘”、“元数据融合”，让人无所适从。
“元数据是描述数据的数据”？
很多文献，甚至国家标准，都把元数据定义为“描述数据的数据”，而且不加任何解释，也给元数据相关的交流带来困惑。本节结合特征描述元数据，分析一下这种定义的来龙去脉以及潜在的危害。
一、特征描述元数据是描述“对象”关键特征的数据，“对象”不一定都是数据
在上一章节中，我们使用图书为例对特征描述元数据做了解释。图书是一个对象，所以我们说“特征描述元数据是对某个对象的关键特征及生产上下文进行描述形成的信息”。看官可能会说，图书也是一种数据，因此“元数据是描述数据的数据”这句话没错。好的，我承认数据可以记录在纸上，但记录在纸上的东西一定应被当作“数据”么？此外，如果看官的话没错，那么博物馆的藏品“元数据（特征描述元数据）”又怎么解释？难道这些实体化的藏品，你也要看作是“数据”？
所以，就定义本身来说，“元数据是描述数据的数据”是不准确的，至少是涵盖不全面的。那看官可能又会说：如果这样的话，我们将元数据的定义改为“元数据是描述对象的数据”岂不完美？好的，这里又带来一个问题，我们在上一章节中已经解释过，世间万物皆是对象，有些对对象的描述可以被称为“元数据（特征描述元数据）”，而其他大部分，考虑使用习惯和场景，称为“数据”更为合适。因此，“元数据是描述对象的数据”这个定义也并不完美，会造成“元数据”这个术语使用的泛滥。
二、“元数据是描述数据的数据”是信息化背景下对元数据认知的进化，同时也是一种限定
上面的分析并不是说”元数据是描述数据的数据“这个定义不能使用，而是说一定要在特定背景下去使用，不要让其应用领域扩大化。之所以出现这个定义，是因为随着网络技术发展，需要对各类数字化、电子化数据资源进行特征描述，于是借用了图书馆“元数据”这个术语，并形成“元数据是描述数据的数据”这个定义。这里有一点需要注意，这个定义是在特定应用背景下产生的，而且一旦产生，就不再适合反向去解释图书、藏品等元数据内涵，否则就会带来“万事万物皆数据”这种认识。
举个真实的例子，某国家推荐标准《xx平台资源核心元数据》，对“元数据”的定义是“描述数据的数据”，而实际是对大型仪器设备名称、管理单位、管理人、价格、采购日期等特征的描述，定义和描述实质明显不统一。询问过标准的作者，回答说：当然可以把大型仪器设备看作是“数据”。如果这样解释，的确可以把“描述仪器设备的数据”与“描述数据的数据”一致起来，但是明显地不符合常理。
情报元数据
“元数据”被一般人所知，可能更多的是在“棱镜门”事件发生之后。美国政府窃取公民私人通信被曝光，如手机通话、电子邮件等，引起百姓极大愤慨和担忧，后又辩称没有窃听“数据”，拿的只是“元数据”。对于技术小白来说，这是个很好的托词，既然没有拿“数据”，那一切都可以接受了，也为法律解释提供了缓冲，法官们也不用再想尽一切办法给政府解套，于是一切恢复正常。
那么对于情报行业来讲，什么是元数据呢？这要从情报的获取方法来进行研究。
假如一名黑客，可以使用一种无线设备截获身边一定范围内的手机通话信息。若A主叫B的通信被截获，此时落地的数据有两个：一个是通信的话音数据，如mp3文件，截获并录取这个mp3文件就是黑客使用的无线设备的主要功能；另一个是围绕这个话音产生的附属文件，如txt文件，记录此通话如（A方号码、B方号码、通话时长、A方基站号、B方基站号、截获时间、设备接收频率、设备天线类型等）等信息。上述信息可以有多种方法收集，如果黑客使用的设备比较智能，这些信息在录取话音形成mp3时就可以自动落盘存储，如果设备比较老旧，可能需要黑客根据设备设定或显示的各种参数进行手工录入。这样的例子还有很多，如电子邮件、卫星通信等都存在这种场景。
A和B的通话被黑客存成了两个文件，一个是通话的语音，即mp3，一个是围绕这个mp3的特征、接收设备参数等形成的附属文件，内容依照上文格式为（135xxxxxxxx，137xxxxxxxx，500，00001，00002，202005201345，940M，1）。美国政府声称“不窃听公民的数据，只是获取了公民通信的元数据”，意思就是我不去听（或者根本不落盘）mp3文件，我只是通过存储和分析txt文件的内容了解你何时给谁打了电话、通话时间、通话时的地理位置等等。关于美国政府是否窃听了公民隐私、以及这些txt蕴含的信息是否有价值，这里不讨论，聪明的看官一定自己有判断。这里需要讨论的是，txt中的信息是对mp3及其生产上下文的描述，那txt文件中的信息是不是mp3数据的元数据？
从“元数据是描述数据的数据”这个定义来看，txt信息描述了mp3文件的各种特征，确实是其特征描述元数据，美国政府的说法没有问题。但是，这些txt文件一旦收集到一定规模，完全可以脱离其对应的mp3文件独立使用，支撑开展诸如通联关系分析、通信地理热点分析、通信时间热点分析等应用，那这时它是数据呢？还是元数据呢？
这就回到了上一章节中的问题，一份记录到底应被称为“数据”还是“元数据”是需要看实际应用场景的。假如黑客站在mp3数据采集的角度来讲，txt的内容的确是“元数据”，但如果站在数据融合、数据挖掘角度来讲，txt记录的内容应该是“数据”而非元数据。如果黑客不懂得变换立场，在任何场合下都说“txt记录的是元数据，mp3才是数据”，就会造成“元数据挖掘”、“元数据融合”等奇葩定义，也会给交流的对象造成极大的困惑。
综上，由于某些业务的特殊性，“元数据”和“数据”是截然不同的两个概念，但若脱离业务场景，在其他业务中使用此“元数据”发挥价值，此时“元数据”是否还应被称为“元数据”？应该具体情况具体分析，而不应该固执己见，不懂变通。否则，情报领域的元数据的内涵，在其他领域可能根本不存在，因为两个领域对“数据”的理解就是根本不同的。
特征描述元数据的数据标准
特征描述元数据也是一种数据，既然是数据，就要有数据标准，当然你也可以说叫“特征描述元数据标准”。但是看官发现没有，一会儿是“数据标准”，一会儿是“特征描述元数据标准”，甚至还可以进一步简化为“元数据标准”，明明指向同一个东西，却有N多种不同的名字，不掉坑里才怪。为了精准阐述本节内容，这里使用繁琐但精准的定义——特征描述元数据数据标准，附带使用“元数据元素”、“元数据元素的值”等定义，而且在本节最后会再回来讨论命名的问题。
一、特征描述元数据数据标准是对元数据元素名称、内涵、类型、值域的定义，同时还包括在使用元数据元素构成元数据对象时应用的规则
很绕吧，我们通过具体的例子来阐述。一个图书管理员面对一本书，要描述它的哪些关键特征生成其特征描述元数据？这些关键特征的内涵是什么？每个特征用哪个元数据元素表示？元数据元素的取值类型是什么？取值范围是什么？等等。
经过拍脑袋，图书管理员干了以下几件事情回答上面的问题：
1. 使用（书名，作者、年代、类型、语种、摘要）6个元数据元素来描述图书，并且作为中文名称。 2. 对每个元数据元素，定义英文名称。 3. 对书名，作者、年代、类型、语种、摘要这些特征的内涵进行解释。 4. 对书名，作者、年代、类型、语种、摘要的取值类型和取值范围进行约定。 5. 对书名，作者、年代、类型、语种、摘要，规定了哪些元数据元素在描述一本书时是必须赋值的，哪些是可选赋值的。
至此，在这个图书馆里，上面5条信息构成了“图书特征描述元数据数据标准”，前4条是对元数据元素的描述，第5项是对构成规则的描述。
“特征描述元数据数据标准”的作用在于规范元数据元素的赋值，如标准规定“语种”这个元数据元素赋值必须采用中文，如果一本汉语图书，“语种”赋值为“Chinese”显然违反标准，需要纠正。
二、特征描述元数据数据标准必须有扩展机制，以适应各类对象的不同描述需求
图书馆除了管理实体图书，还要管理电子图书，此时发现使用“图书特征描述元数据数据标准”定义的6个元数据元素不足以完全描述电子图书的特性，于是进行了一些扩展：
1. 在（书名，作者、年代、类型、语种、摘要）基础上，添加了“格式”元数据元素。 2. 定义了“格式”元数据元素，包括英文名、内涵、类型、取值范围等。 3. 规定在描述电子书时，“格式”元数据元素必须赋值。
这样，上面3条信息构成了“电子图书特征描述扩展元数据数据标准”，与其父标准“图书特征描述元数据数据标准”两者联合使用，就可以生成完整的电子图书特征描述元数据。
三、网络化、电子化的数据，其特征描述元数据数据标准已经事实存在
脱离开图书馆的场景，把眼界放宽。在前面章节中，我们提到过在现实中特征描述元数据多是描述网络化、电子化的数据，也因此有了“元数据是描述数据的数据”这个定义。那么对于这类数据，我们是否需要设计其“特征描述元数据数据标准”呢？显然不用。《都柏林核心元数据元素集》定义了15个元数据元素，能够较为全面地描述网络化、电子化资源，生成特征描述元数据。但《都柏林核心元数据元素集》并不强制要求用户必须使用全部15个元素，用户可以选择一个子集、或对元数据元素的定义稍加修改，形成自己行业内部使用的“xx特征描述元数据数据标准”，也鼓励用户在“xx特征描述元数据数据标准”基础上，针对特定数据资源类型，形成特色扩展元数据数据标准。
《都柏林核心元数据元素集》15个元素包括：
Title : 资源的名字 Creator : 一个主要负责创建资源内容的实体 Subject : 资源内容的主题 Description: 资源内容的描述 Publisher : 一个负责使得资源内容可用的实体 Contributor: 一个负责为资源内容作出贡献的实体(如作者) Date : 在资源生命周期中某时间关联的日期 Type : 资源内容的类型 Format : 资源的物理形式或数据形式 Identifier : 一个在给定上下文中明确标识资源的标识符 Source : 一个对作为目前资源的来源的资源引用 Language : 资源内容采用的语言 Relation : 一个对相关资源的引用 Coverage : 资源内容所在的范围或区域 Rights : 关于资源的权限信息
四、“特征描述元数据数据标准”这个名称可以简化，但一定确保不要形成歧义
“图书特征描述元数据数据标准”比较绕口，可以简化为《图书特征描述元数据标准》《图书元数据标准》《图书核心元数据标准》等，对应的“电子图书特征描述扩展元数据数据标准”可以简化为《电子图书扩展元数据标准》。这种简化对图书馆来说没有问题，但是对于其他一些行业应用，就会因为对“元数据”这三个字存在不同的内涵理解带来交流障碍。
此外，个人认为《都柏林核心元数据元素集》这个名字也起得不好，理由也是没有明确“元数据”三个字的内涵，在某些场合下会造成误解，如果修改为《都柏林特征描述核心元数据元素集》可能更妥。当然，这种“不好”也是有原因的，在本系列文章前面章节开头就说过，“元数据”最初就是用来进行特征描述的，因此很多业务都直接把“特征描述元数据”直接称呼为“元数据”，在坚守历史传承的同时并没有考虑当今又出现了其他元数据类型。
五、既可以说“特征描述元数据数据标准”定义了“元数据元素”，也可以说定义了“数据元素”
特征描述元数据也是一种数据，所以站在不同的立场上，使用“元数据元素”或者“数据元素”都可以用来描述标准的内涵，指向相同，但一定不要造成歧义。
“描述数据的数据”中被描述“数据”的粒度
“元数据是描述数据的数据”，那么被描述的数据是一个什么样的粒度？以结构化表为例，这个“数据”可以代表这个表的全部内容，即“数据集”，也可以仅代表某一行数据，即“数据对象”，甚至仅仅代表一个列值，即“数据项”。从元数据内涵的起源来看，它描述的是一本“书”，那“书”到底对应的是数据集、数据对象还是数据项呢？其实都是可能的。这也为特征描述元数据的理解带来了另一种必须讨论的上下文。
特征描述元数据的核心功能就是对“数据集”或“数据对象”建立描述，以区分其他“数据集”或“数据对象”，支持数据管理、检索等工作。
数据集粒度较大，数据集与数据集之间的区别依靠《都柏林核心元数据元素集》及相应扩展基本就能表达清楚，但数据对象的粒度很小，两个数据对象之间可能只有些许差别，此时单独依靠《都柏林核心元数据元素集》建立的描述可能完全相同。
举个例子：
+------------+------------+--------+ | 姓名 | 诊疗日期 | 疾病 | +------------+------------+--------+ | 张三 | 2012.05.06 | 感冒 | | 王五 | 2012.05.06 | 感冒 | | 张三 | 2012.05.20 | 结膜炎 | | 李四 | 2012.06.03 | 过敏 | | 张三 | 2012.08.06 | 肠胃炎 | +------------+------------+--------+
上述是一张简单的表，记录一段时间内某诊所的诊疗信息，此表信息需要上报。如果要求以数据集为单位上报，依照《都柏林核心元数据元素集》为该数据集建立了特征描述元数据。如果另外一个诊所也需要上报它自己的诊疗信息，《都柏林核心元数据元素集》能够保证两个诊所上报的特征描述元数据是不同的，如两个数据集可以通过“Creator”和“Publisher”区分。此时，元数据元素与表的数据元素“姓名、诊疗日期、疾病”没有一点关系。
但如果要求把数据集拆开，一条条上报，同时针对每一个数据对象都建立特征描述元数据，此时就存在一个问题，如何通过特征描述元数据区分“张三”的三条诊疗记录？这种细粒度的“数据”，只有细粒度的区别，此时单纯依靠《都柏林核心元数据元素集》就不行了，必须选择数据对象的某个“数据元素”作为特征描述元数据元素，作为《都柏林核心元数据元素集》的扩展一起为“数据对象”建立特征描述元数据，如此处可以选择“诊疗日期”作为资源描述元数据的一部分，以区分“张三”的三条不同的“数据”。此时，元数据元素与表的数据元素就存在的紧耦合的关系。极限情况下，数据对象的全部列名都作为特征描述元数据元素理论上也是可能的。
如果使用特征描述元数据进行数据检索，针对“数据对象”的特征描述元数据由于包含了数据对象的列值，搜索更为准确，但针对每一行数据都生成对应特征描述元数据工作量大；针对“数据集”的特征描述元数据不包括数据对象的列值，搜索比较模糊，但生成量小。至于究竟应该是针对数据集还是数据对象建立资源描述元数据，一定依赖于具体应用场景和相应规定。
还有一点需要强调，使用数据对象的数据元素作为其特征描述元数据的组成部分，一定是因为“先有”了数据元素定义，然后“再把”某个“数据元素”引用过来作为特征描述元数据的组成部分，而不能反其道行之，将资源描述元数据的数据元素定义与数据元素的定义等同。
语义结构元数据
数据是需要进行语义解释的。如数据对象（张三，1，1980.10.02，2008.05.04），大家可能可以一眼看出“张三”代表的是一个人的名字，而对后面三个值则是不明就里，尽管你可能知道最后两个值是一个日期，但到底代表什么含义呢？这就是语义结构元数据的作用：促进数据的互识别互理解。
一、语义结构元数据的形态是对数据元素和数据结构的定义
针对（张三，1，1980.10.02，2008.05.04）这个数据对象，如果其有意义，则每一个数据项必须有其内涵和格式，因此必须存在数据元素定义，如（姓名，性别，出生日期，结婚日期），有了这个数据元素定义，大家马上就能了解数据的含义。定义数据元素需要包含的不仅是名字的定义，还包括内涵（因为有些情况下给出名字你可能还是不知道什么意思）、类型、值域等等。如对“姓名”这个数据元素，定义包括5个方面：
数据元素名：姓名 数据元素英文名：name 内涵：户口本登记的表示一个人的名称，包括“姓”和“名”两个部分。 类型：字符串 取值范围：至少两个汉字，最多16个汉字。 ......//此处省略对性别、出生日期、结婚日期这些数据元素的定义
上面的这些定义，可以抽象地认为也是一种“数据”，而且是“描述数据语义和结构的数据”，当然可以被称为是一种元数据，即“语义结构元数据”。
二、特征描述元数据也有对应的语义结构元数据
- 特征描述元数据的形态是“值”的组合，如（小鸡历险记，张三，1980，儿童读物，中文，小鸡从养鸡场逃出后周游世界的故事）是特征描述元数据，当然也可以被看做数据。
- 语义结构元数据的形态是对数据“值”对应的数据元素以及数据结构的定义，如对（小鸡历险记，张三，1980，儿童读物，中文，小鸡从养鸡场逃出后周游世界的故事），定义：
数据元素名：书名 数据元素英文名：book_name 内涵：书籍的印刷名称 类型：字符串 取值范围：至少1个汉字，最多256个汉字 ......//此处省略对作者、年代、类型、语种、摘要这些数据元素的定义
- “特征描述元数据数据标准”实际上就是“特征描述元数据”的“语义结构元数据”，也即被描述对象（如图书）的“元元数据”——元数据的元数据。这里，从左起第一个“元”，代表的是语义结构元数据，第二个“元”代表的是特征描述元数据。尽管使用“元元数据”在此处能够说明问题，但一般不建议这么使用，因为在其他场景里，两个“元”放在一起很可能是另外一种含义。
三、语义结构元数据标准的含义是双重的
语义结构元数据标准包括两个方面的含义：
- 关于语义结构元数据的类型、组成、描述方法等方面的规范
通过前面的介绍，看官可能觉得语义结构元数据就是对数据元素和数据结构的定义，这种理解非常浅显易懂。但实际上，语义结构元数据包含的具体元数据类型众多，如量纲元数据、术语元数据、指标元数据、对象类元数据、属性元数据、值域元数据、数据元概念元数据、数据元元数据等，各种不同类型的元数据组合使用才能形成对数据元素和数据结构科学完整的定义。此外，对于每一种语义结构元数据，还要明确从哪些角度去定义它，正如我们前面对数据元素的定义包括名称、英文名、内涵、类型、值域等，每一种语义结构元数据都需要明确的定义步骤和规则。
- 从针对同一对象的不同的语义结构元数据定义中，优选出应被全局遵守的语义结构元数据
语义结构元数据反映的是各个行业对自身数据涉及对象的认识。A行业的业务与卫星有关，因此在生产与卫星相关的数据时，必须就相关数据项名称、内涵、量纲、值域等做出规定；B行业的业务也与卫星相关，也有自身的相关数据项名称、内涵、量纲、值域规定。两个行业均遵循ISO/IEC 11179规范定义了自己的语义结构元数据，形成行业自有的、各异的语义结构元数据集合。
当我将A、B两个行业的数据进行融合时，由于两个行业语义结构元数据不同，不可避免要对A或B、甚至A和B的数据进行转换，变成标准化的格式，这种标准化全局格式就是语义结构元数据标准。比如对于卫星的频率这个量纲元数据，A行业使用KHz，B行业使用MHz，如果最终经过专家评审，认为KHz更具全局代表性，那自然KHz就成为卫星频率量纲元数据标准。
四、不加限定的去谈“元数据”，容易造成歧义
到目前为止，本系列文章介绍了“特征描述元数据”和“语义结构元数据”两类元数据，两类元数据本质不同，因此可以介绍一下“元数据”这三个字可能会带来的歧义。
本系列文章在前面章节中都提到过，“元数据”是从“特征描述元数据”起源的，因此，很多技术人员一提到“元数据”，都会想当然认为是特征描述元数据，虽然有理，但有害，“元数据”当然还可以是“语义结构元数据”。因此，如果不加限定去谈“元数据”，极易造成误解。如一份假想的《医疗元数据标准》，从题目来看，搞不清楚这里的“元数据”到底是什么含义，因此可以进行如下两种解读：
第一种解读：某地要针对医院、诊所中存储的诊疗信息构建一个大数据平台，通过共享交换医疗数据，提升整体医疗信息化水平，因此，这里的“元数据”指的是“特征描述元数据”，即当医院、诊所向大数据平台发布数据集时，需要使用元数据标准描述这个数据集，为后期其他机构检索、查询这个数据集提供便利。
第二种解读：由于各个医院、诊所诊疗信息系统均为前期独立建设，数据标准严重不统一，导致数据互识别互理解困难，因此，这里的“元数据”指的是“语义结构元数据”，即需要通过建立全局统一的数据元素、量纲、值域等标准，促进各医院、诊所诊疗信息系统提供的数据规范化、标准化。
这种歧义在不去看《医疗元数据标准》内容的情况下，是无法分辨清楚的，而现实中这种情况普遍存在。很有可能《医疗元数据标准》的内涵是第一种解读，因为标准的制定者认为“元数据”想当然应该是“特征描述元数据”，标准的读者也应该具备与制定者相同的语境。在日常的口头交流中，这种情景更是比比皆是，导致“鸡同鸭讲”。更严重的情况，因为没有深入了解两类元数据的差别（甚至不知道应该要区分不同种类元数据的内涵），出现将“特征描述元数据标准”与“语义结构元数据标准”搅和在一个标准文档中进行定义的情况。
如果精准描述该标准，第一种解读应修改为《医疗发现元数据标准》，第二种修改为《医疗语义结构元数据标准》，很容易解决。发现元数据是特征描述元数据的一种应用形式，主要用在数据集注册和检索领域，为共享数据发布获取提供支持。
数据仓库元数据
一、数据仓库
数据仓库历史非常悠久，在云计算、大数据等概念出现之前，数据仓库相关技术就已经较为成熟了。这里首先对数据仓库概念进行一个解释，为了尽快进入状态，这个解释不追求精准，只追求一个一般概念上的理解。
数据库与数据仓库相对应，前者用于业务处理，后者用于统计分析；前者的受益对象为客户和一线工作人员，后者的受益对象是各级决策者；前者主要操作是增删查改，后者修改删除较少；前者的实时性能高、后者的吞吐率高；前者数据量较小；后者数据量较大。两者采用的产品，虽然实质上差别巨大，但是这里可以简单认为都是关系型数据库。
举个例子，医院的病历数据库存放病人诊疗数据、财务数据库存放病人消费数据，方便医院医生、工作人员围绕病人开展各项工作。由于必须保证两个业务系统的性能，两个数据库中数据量不能过多，因此我们认为两个数据库都只存储近1年来的病人数据。那1年前的病人数据难道就彻底删除了么？确实，1年前的病人数据的确在到期时从两个业务系统的数据库中自动删除，但实际上相关数据早就在某个时刻被同步放入了医院的数据仓库之中，长久保存。如业务系统数据库与数据仓库的同步时刻为每天23:59:59，同步策略为新增同步，即仅将当天业务系统数据库中新生成的数据同步进数据仓库。
说到这里，看官们千万不要认为数据仓库的功能就是为前台业务系统提供备份存储。数据仓库的主要功能是为生成各类统计分析指标提供“原材料”，而从业务系统中同步来的数据就是生成“原材料”的“矿石”。
数据仓库在设计阶段就要结合后期需求明确“原材料”的数据模型。为了后期能够便利地生成各种统计指标，“原材料”数据模型的设计原则和方法与业务系统数据库完全不同，如可能无须坚持范式、数据允许存在大量冗余等。来自业务系统的数据经过各种处理、蹂躏、复制，虽然可能导致诸多冗余，但是从各个角度呈现出全新的面貌，有利于快速、准确、全面地对统计指标生成提供数据支持。如医院的两个业务系统可能只包含10张表，但是在数据仓库里，可能对应1000张表，这些表和表之间存储的数据在很大程度上可能存在重复，但是正是这种重复为相关统计指标的计算带来了便利，是“空间换时间”的一种体现。
如，医院想统计30年来20种主要疾病的平均住院时间、平均治疗花费、住院时间与治疗花费的关系，这是一项计算量极大的工作。如果没有数据仓库，诊疗和消费数据都记录在业务系统数据库中。在业务系统数据库上进行统计分析需要查询大量数据，时间很长、负载很高，会直接影响业务系统的正常运行。此时，数据仓库的作用就凸显出来。医院数据仓库通过同步获得两个业务数据库的“矿石”后，当然可以不经加工直接使用“矿石”开展统计分析，此时已不会影响业务系统正常运行。但是这些“矿石”的数据模型仍然是原有业务系统设计的，因为坚持了相关范式，设计目标是追求某些操作的精简和高效，但在这种数据模型下进行统计分析相关操作，速度、效率却非常低。因此，必须打散“矿石”的原有数据模型，将“矿石”经过各种处理和变换存入新设计的数据仓库表中，完成从“矿石”到“原材料”的转化。“原材料”按照新的数据模型组织，对各类统计指标生成非常友好，会极大方便各种统计指标周期性生成和类型扩展。
二、数据仓库元数据
由上文可见，“原材料”数据是数据仓库的核心要素，但这些“原材料”数据并不是凭空产生，而是需要从具体业务系统中同步数据、经过诸多处理环节一步步生成，直至最后删除。这个过程需要其他诸多要素支持，如同步策略、处理规则、数据模型、脚本定义、指标定义、质量要求等等。数据是“核心要素”，其他要素描述的都是“核心要素”某些方面的特征或需求，是“描述数据的数据”，因此在数据仓库中被统称为“元数据”，即数据仓库元数据。
三、数据仓库元数据与特征描述、语义格式元数据的关系
特征描述元数据是“值”的组合，如果因某种需求进入数据仓库，一定是被当作普通数据对待。如图书描述元数据进入数据仓库一定是要开展与图书相关的统计，此时就是一份普通的数据，与其他数据没有差别。
语义格式元数据描述数据的内涵和组成，对理解数据仓库数据的语义和结构关系密切，是数据仓库元数据的重要种类。如上图中左下角和右上角两类数据仓库元数据，本质上都是语义结构元数据。
四、数据仓库元数据的分类
上图对数据仓库元数据类型有一个列举，这些的数据仓库元数据能否进一步进行归纳，划分成若干种类呢？数据仓库元数据分类方法非常多，不同人有不同的认识，存在不同的角度，因此形成了各种各样、千奇百怪的分类方法，甚至无法理清背后的思维脉络。因此，我们只能跟随数据仓库“大神”们的思路，遵循他们制定的经典、有代表性的分类方案。Ralph Kimball就是一位举世公认的数据仓库领域“大神”，他将元数据划分为三个类别：业务元数据，技术元数据和过程处理元数据。内涵如下：
- 业务元数据：业务元数据主要描述数据背后的业务含义，包括业务术语、业务规则、业务逻辑等。它帮助业务人员理解数据仓库中的数据，并指导他们进行数据分析和决策。业务元数据还包括主题定义、业务描述、标准指标和标准维度等，这些信息对于确保数据的一致性和可比性至关重要。
- 技术元数据：技术元数据存放关于数据仓库系统技术细节的数据，用于开发和管理数据仓库。它包括数据结构、数据处理流程、数据存储方式等信息。技术元数据还记录了数据仓库的物理结构、逻辑结构和访问方式等，这些信息对于数据仓库的开发和维护人员来说非常重要。
- 过程处理元数据：是ETL处理过程中的一些统计数据，通常包括有多少条记录被加载，多少条记录被拒绝接受等数据。
这里需要注意一个问题，上述分类是针对数据仓库元数据的，内涵也是结合数据仓库建设需求给出，目标性很强、适用领域非常确定。而在现实中，“元数据”的使用范围早已超出数据仓库范畴，在更为广泛的数据治理、数据管理领域被大量使用，甚至呈现被“过度使用、过度消费”的情况，再使用上述分类方法对所有的元数据进行分类，既不合理，又不实用。本系列文章在前言部分提到过各种各样的元数据分类方法，不同人有不同的认知，正是由于这种误用导致。
实际上，脱离开数据仓库，就大数据管理、治理而言，如何进行元数据分类、各类元数据到底是什么内涵、什么形态，完全是“千人千面”，依赖数据管理治理的目标、对象、方法，根本不存在一套统一权威的答案。我们需要做的就是，根据数据治理管理需求创建自己的元数据，给它一种名称，并向别人解释清楚自己的元数据到底是什么功能，而不应该尝试寻求一种“放之四海皆准”的分类原则和命名方法。当然，对于一些数据治理管理过程中较为常用、通用的元数据我们可以进行某种程度的全局规范，但这种元数据类型实在少之又少，资源发现元数据、ISO/IEC 11179元数据就是两个典型代表。而作为聆听者、学习者，在涉及到元数据时，一定也要“小心赔上小心”，搞清楚它的使用上下文和内涵解释，这个非常非常非常重要。
元数据在数据仓库中的作用
- 描述和定义
元数据记录了数据仓库中模型的定义、各层级间的映射关系、数据状态以及ETL（Extract, Transform, Load）作业的任务状态。这些信息对于理解数据仓库的结构、数据流向和数据处理过程至关重要。
元数据还定义了要进入数据仓库中的数据和从数据仓库中产生的数据，包括数据的来源、格式、转换规则等。
- 数据管理和维护
元数据支持系统对数据仓库中的数据进行管理和维护，包括数据的存储、访问、更新和删除等操作。通过元数据，系统可以确保数据的一致性和完整性。
元数据还记录了数据仓库中数据的抽取、转换和加载过程，这有助于跟踪数据的来源和变化，以及进行数据的审计和验证。
- 提高数据质量
元数据定义了数据的业务规则和质量标准，系统可以根据这些规则和标准来检测数据的质量问题，如数据缺失、格式错误、逻辑错误等。
通过元数据，系统还可以对数据进行清洗和转换，以提高数据的准确性和可用性。
元数据管理在数据仓库中的重要性
- 提升数据价值
通过元数据管理，数据仓库能够更有效地组织和利用数据资源，提高数据的可用性和价值。元数据为数据分析和决策提供了基础支持，使得业务人员能够更快地找到所需的数据并进行深入分析。
- 降低维护成本
元数据管理有助于减少数据仓库的维护成本。通过自动化的元数据管理工具，可以实现对数据仓库的实时监控和动态调整，减少人工干预和错误。同时，元数据管理还可以提高数据仓库的可扩展性和灵活性，使得系统能够更好地适应业务需求的变化。
- 增强安全性
元数据管理还涉及数据仓库的安全性方面。通过元数据定义的安全策略和权限设置，可以确保数据仓库中的数据不被未授权访问或篡改。这对于保护企业的敏感数据和商业机密具有重要意义。
参考资料
原创文章，转载请注明出处：http://www.opcoder.cn/article/82/