元数据概念以及原理应用全解析

元数据是什么意思？元数据如何理解？元数据的作用是什么？大数据时代，何处安放我们的元数据？本文将围绕这些问题来探讨。

 

元数据概述

 

元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录，为了达到编制目录的目的，必须在描述并收藏数据的内容或特色，进而达成协助数据检索的目的。都柏林核心集（Dublin Core Metadata Initiative，DCMI）是元数据的一种应用，是1995年2月由国际图书馆电脑中心（OCLC）和美国国家超级计算应用中心（National Center for Supercomputing Applications，NCSA）所联合赞助的研讨会，在邀请52位来自图书馆员、电脑专家，共同制定规格，创建一套描述网络上电子文件之特征。

 

元数据定义

 

元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息。

 

元数据（Metadata）是描述其它数据的数据（data about other data），或者说是用于提供某种资源的有关信息的结构数据（structured data）。元数据是描述信息资源或数据等对象的数据，其使用目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。 元数据的基本特点主要有：

 

a）元数据一经建立，便可共享。元数据的结构和完整性依赖于信息资源的价值和使用环境；元数据的开发与利用环境往往是一个变化的分布式环境；任何一种格式都不可能完全满足不同团体的不同需要；

 

b）元数据首先是一种编码体系。元数据是用来描述数字化信息资源，特别是网络信息资源的编码体系，这导致了元数据和传统数据编码体系的根本区别；元数据的最为重要的特征和功能是为数字化信息资源建立一种机器可理解框架。

 

元数据体系构建了电子政务的逻辑框架和基本模型,从而决定了电子政务的功能特征、运行模式和系统运行的总体性能。电子政务的运作都基于元数据来实现。其主要作用有：描述功能、整合功能、控制功能和代理功能。

 

由于元数据也是数据，因此可以用类似数据的方法在数据库中进行存储和获取。如果提供数据元的组织同时提供描述数据元的元数据，将会使数据元的使用变得准确而高效。用户在使用数据时可以首先查看其元数据以便能够获取自己所需的信息。

 

元数据的作用

 

元数据(MetaData)是MDA中非常重要的概念。它通过统一的、平台无关的、规范的方式对数据的模式特征进行描述，通过一个模型结构来表达通用的信息，它集设计模型、开发模型与运行模型为一体。元数据具有如下几个作用。

 

(1) 元数据是独立于平台的，无论使用什么技术平台，元数据本身是不受影响的，这保证了先期工作成果的效用最大化。

 

(2) 元数据是生成平台相关模型的基础，可以使用代码生成器等工具将元数据转换成平台相关代码。

 

(3) 元数据为运行时系统提供了统一的可读的系统模型，系统运行时可以使得实体对象通过运行时元数据模型来得知自身的结构、自身的特征、在系统模型中的位置以及与其他对象之间的关系等。这样就可以从一个新的角度来观察、设计、开发系统。

 

(4) 元数据模型是系统运行不可或缺的部分，如果直接修改平台相关代码而不修改元数据，就会造成系统运行异常，这就强迫保证元数据模型与代码同步，保证了设计模型和实现代码的一致性。

 

(5) 元数据本身就是一个设计模型。系统设计人员可以使用元数据进行系统建模，在某种程度上元数据可以取代UML图等传统的设计模型。设计人员将设计完成的元数 据模型交给开发人员，开发人员使用代码生成器将元数据转换成平台相关代码，然后就可以基于这些平台相关代码进行开发了。元数据起到了设计人员和开发人员沟 通桥梁的作用，设计人员的工作立即就可以转换为可以运行的平台相关代码。

 

元数据设计的基本原则

 

除了上边提到的运行时的元数据中一定不能包含平台相 关特性之外，在元数据的设计中，“适可而止”也是需要铭记在心的核心原则。对元数据描述的范围要适可而止，不要试图包罗万象。运行时元数据是能够给运行时 的系统提供元数据的信息的，这在一定程度上简化了系统的开发，但是切不可把应该写在代码中或者写到配置文件中的信息写到元数据中。比如在实体对象元数据 中，给字段增加了“allowNull”特性来表示此字段是否允许为空。

 

系统保存实体对象的时候，可以读取此实体对象对应的元数据，进而取得所有字段的是 否为空的特性，从而对数据进行校验。这是对运行时元数据非常合理的运用。但是如果试图把字段为空时提示什么样的信息、字段最大长度是多少、字段是否进行加 密操作等特性加入元数据的话就会使得元数据模型过于庞大，这也违反了“适可而止”这一基本原则。如果元数据直接驱动系统的运行过程，并且有取代程序代码的 趋势的话，就说明设计人员对元数据概念理解错误了，用元数据驱动系统运行虽然减少了代码的编写，但是这些本不应该放在元数据中的特性是不完备的，一旦需要 扩展就会遇到难以逾越的鸿沟。

 

由于客户需求的复杂性，模型结构不能表达出所有业务的处理过程，仍然存在需要利用编程语言才能完成的业务功能。元数据模型解决大多数通用的问题，而对于具有差异性的问题还是要通过编码来完成的，不应该让运行时元数据承担过多的运行时语义。

 

元数据（MetaData）如何理解

 

元数据是用来描述数据的数据（Data that describes other data）。单单这样说，不太好理解，我来举个例子。

 

下面是契诃夫的小说《套中人》中的一段，描写一个叫做瓦莲卡的女子：

 

（她）年纪已经不轻，三十岁上下，个子高挑，身材匀称，黑黑的眉毛，红红的脸蛋－－一句话，不是姑娘，而是果冻，她那样活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑，动不动就发出一连串响亮的笑声：哈，哈，哈！

 

这段话里提供了这样几个信息：年龄（三十岁上下）、身高（个子高挑）、相貌（身材匀称，黑黑的眉毛，红红的脸蛋）、性格（活跃，吵吵嚷嚷，不停地哼着小俄罗斯的抒情歌曲，高声大笑）。有了这些信息，我们就可以大致想像出瓦莲卡是个什么样的人。推而广之，只要提供这几类的信息，我们也可以推测出其他人的样子。

 

这个例子中的"年龄"、"身高"、"相貌"、"性格"，就是元数据，因为它们是用来描述具体数据/信息的数据/信息。

 

当然，这几个元数据用来刻画个人状况还不够精确。我们每个人从小到大，都填过《个人情况登记表》之类的东西吧，其中包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等......这一套元数据才算比较完备。

 

在日常生活中，元数据无所不在。有一类事物，就可以定义一套元数据。

 

喜欢拍摄数码照片的朋友应该知道，每张数码照片都包含EXIF信息。它就是一种用来描述数码图片的元数据。按照Exif 2.1标准，其中主要包含这样一些信息：

 

Image Description 图像描述、来源. 指生成图像的工具

 

Artist 作者 有些相机可以输入使用者的名字

 

Make 生产者 指产品生产厂家

 

Model 型号 指设备型号

 

Orientation方向 有的相机支持，有的不支持

 

XResolution/YResolution X/Y方向分辨率 本栏目已有专门条目解释此问题。

 

ResolutionUnit分辨率单位 一般为PPI

 

Software软件 显示固件Firmware版本

 

DateTime日期和时间

 

YCbCrPositioning 色相定位

 

再举一个例子。在电影数据库IMDB上可以查到每一部电影的信息。IMDB本身也定义了一套元数据，用来描述每一部电影。下面是它的一级元数据，每一级下面又列出了二级元数据，总共加起来，可以从100多个方面刻画一部电影：

 

Cast and Crew（演职人员）、Company Credits（相关公司）、Basic Data（基本情况）、Plot & Quotes（情节和引语）、Fun Stuff（趣味信息）、Links to Other Sites（外部链接）、Box Office and Business（票房和商业开发）、Technical Info（技术信息）、Literature（书面内容）、Other Data（其他信息）。

 

元数据最大的好处是，它使信息的描述和分类可以实现格式化，从而为机器处理创造了可能。

 

 

MP3音乐元数据

 

你大概经常听到元数据（metadata）这一概念。它指的是存在于计算机文件中的一种“隐藏”数据，这些数据会用一些特定的识别信息来给某一文件加上“标签”。例如，你可能在媒体讨论中听过关于元数据在通话数字录音中的运用。元数据的格式根据文件类型而不同。本文关注的重点是音乐文件元数据。

 

音乐元数据，也被称作MP3文件的ID3标签，就是歌曲的识别信息，如

 

作曲人

表演者

歌曲名称

专辑名

发行年份

音轨编号

流派

专辑封面

歌词

制作人

其他

 

当你上传音乐至iTunes时，元数据会显示相应信息，而非只有可怕的“未知艺术家”及“曲目1”。元数据跟MP3的文件名毫无关系，它需要音乐播放器或特定编辑程序进行识别或更改。其重要性有以下几点：

 

1. 使你自己的名字出现在主要音乐数据库中，比如Rovi/Allmusic（译者注：关于音乐的元数据数据库）以及CDDB/Gracenote（译者注：音乐网络数据库）。这很重要，因为任何一个音乐专业人士都会使用这些数据库，检索作品、核实创作身份及演职人员。

 

2. 如果你打算将自己的音乐应用于影视作品，那么对版权进行跟踪是非常重要的，而元数据的作用也就体现于此。当作品的元数据被正确地收录在发行商的数据库内，版权费就可以付到你手里。有时你可能会发wav文件给出版商，但要知道，这种时候，mp3格式更常用，如MusicXRay和TAXI（译者注：两者均为音乐人与行业专业人士进行直接互动的音乐平台）这样的音乐网站就更倾向于接受mp3文件。

 

3. 如果你要将自己的作品提交给某位乐评人或当地/国际的广播电台，那么无论你选择通过公关公司、还是自己直接联系，你的电子资料包中都应该包括有携带了正确元数据（包括专辑信息）的mp3格式歌曲。

 

一旦你的mp3文件被正确标记，歌曲就可以上传到Allmusic或CDDB等音乐数据库，并与你的名字直接关联。

 

音乐元数据与MP3 音乐元数据可与音乐文件相关联，方式有以下两种：

 

它可以直接包含于文件本身（mp3 或WMA文件）；

 

它可以存在于CD（wav文件）中那些与歌曲相关联的分离文件里。

 

MP3文件较小，音频质量不如wav文件。CD制作主要使用的是wav文件。CD的元数据所在位置取决于制作者。除非你是工程师，不然基本上你不会去创建或编辑CD光盘中wav文件的相应元数据。（如果你用iTunes或其他软件把CD拷贝到电脑里，软件在将其转化为MP3文件的时候会自动复制wav文件元数据至相应位置）

 

但由于MP3文件较小，常应用于向乐评人、电台或比赛提交作品，故本文涉及的是如何增加或修改mp3文件的元数据，而非wav文件。

 

专辑封面专辑封面小贴士：专辑封面应为正方形的图片，格式为jpeg，分辨率至少为300 x 300。还有一些常见的分辨率为340 x 340、375 x 375，甚至600 x 600。在编辑元数据之前，要确保封面大小已调好。在向乐评人或电台提交作品前，请确认好他们对封面的尺寸要求。

 

使用Windows Explorer、iTunes或GooglePlay来编辑元数据如果你用的是PC电脑，可以使用Windows Explorer来编辑ID3元数据。

 

很多人在PC或Mac电脑里使用iTunes。

 

元数据编码语言与制作方式

 

1 元数据编码语言

 

元数据编码语言（Metadata Encoding Languages）指对元数据元素和结构进行定义和描述的具体语法和语义规则，常称为定义描述语言（DDL）。

 

在元数据发展初期人们常使用自定义的记录语言（例如MARC）或数据库记录结构（如ROADS等），但随着元数据格式的增多和互操作的要求，人们开始采用一些标准化的DDL来描述元数据，例如SGML和XML，其中以XML最有潜力。

 

2 元数据制作方式

 

（1）专门编制模块（例如对MARC、GILS、FGDC等）

 

（2）数据处理时自动编制（例如对Dublin Core等）

 

（3）数据物理处理时自动编制（例如数字图像扫描时的某些元数据参数）

 

（4）共享元数据（例如OCLC/CORC、IMESH）

 

 

元数据互操作性

 

1 元数据互操作性问题

 

由于不同的领域（甚至同一领域）往往存在多个元数据格式，当在用不同元数据格式描述的资源体系之间进行检索、资源描述和资源利用时，就存在元数据的互操作性问题（Interoperability）：

 

多个不同元数据格式的释读、转换和由多个元数据格式描述的数字化信息资源体系之间的透明检索。

 

2 元数据格式映射

 

利用特定转换程序对不同元数据元格式进行转换，称为元数据映射（Metadata Mapping/Crosswalking）。

 

已有大量的转换程序存在，供若干流行元数据格式之间的转化，例如

 

Dublin Core与USMARC； Dublin Core与EAD

 

Dublin Core与GILS；　GILS与MARC TEI

 

Header与MARC FGDC与MARC

 

也可利用一种中介格式对同一格式框架下的多种元数据格式进行转换，例如UNIverse项目利用GRS格式进行各种MARC格式和其它记录格式的转换。格式映射转换准确、转换效率较高。不过，这种方法在面对多种元数据格式并存的开放式环境中的应用效率明显受到限制。

 

3 标准描述框架

 

解决元数据互操作性的另一种思路是建立一个标准的资源描述框架，用这个框架来描述所有元数据格式，那么只要一个系统能够解析这个标准描述框架，就能解读相应的Metadata格式． 实际上，XML和RDF从不同角度起着类似的作用。

 

XML通过其标准的DTD定义方式，允许所有能够解读XML语句的系统辨识用XML_DTD定义的Metadata格式，从而解决对不同格式的释读问题。

 

RDF定义了由Resources、Properties和Statements等三种对象组成的基本模型，其中Resources和Properties关系类似于E-R模型，而Statements则对该关系进行具体描述。

 

RDF通过这个抽象的数据模型为定义和使用元数据建立一个框架，元数据元素可看成其描述的资源的属性。

 

进一步地，RDF定义了标准Schema，规定了声明资源类型、声明相关属性及其语义的机制，以及定义属性与其它资源间关系的方法。另外，RDF还规定了利用XML Namespace方法调用已有定义规范的机制。

 

 

大数据时代 何处安放我们的元数据？

 

我们需要收集，归档，研究的数据量是非常惊人的，但是如果我们能巧妙利用元数据，就能快速找到我们所需要的数据文件。不过，单独存储，研究元数据本身就是一个“大数据”问题，其中一个很重要的方面就是我们要把元数据存储到哪里？

 

目前，我们已经被“疯狂”的大数据包围了，整个世界都在适应大数据，我们要了解如何使用大数据，如何为大数据设计相应的处理系统，尽管如此，大数据仍然是一片深不可测的海洋。以我们的生活为例，在我们周围到处都有摄像头——商店外面，商店里面，十字路口，直升飞机上，银行，还有人们的手机上。还有大量的传感器——在街道上，在汽车里，在公园里，在桥上。还有一些特殊行业用的传感器，比如说电力行业，油气行业，医院，网络服务，网页，天气，海洋，军队，等等。它们无时无刻不在收集数据。而所有这些数据都有一个共同的地方——它们都需要元数据。

 

元数据是关于数据的数据。举个例子，元数据可以包括传感器位置信息（GPS坐标），特定时间的记录信息，传感器感应的方向，传感器的固件以及传感器的型号等等。

 

在对数据进行后期处理时，你可以用新得到的元数据信息给文件标上“标签“。比如说照相机，可以用时间来作为元数据标签，记录有趣的事情（或许会和事件本身一起被记录下来）。还有一些元数据标签可以是其它相关的信息资源，比如说其它的照相机型号或天气数据。

 

从中我们可以看出，元数据的使用依赖于其质量。如果元数据不精确，那使用相关的原始数据时就会出现问题，甚至会造成分析失败。有一些元数据是人为制造的，不能自动生成，所以会有一定的错误率。

 

认识到什么样的元数据对特定数据文件很重要，了解如何运用它们分析数据，这是非常重要的问题，而且这不仅仅涉及到技术解决方案，还有可能涉及到社会学和心理学的解决方案。

 

但是一个看起来很简单的问题却对元数据的使用造成重大影响，那就是——我们要把元数据存储在什么地方？

 

何处安放你的数据？

 

在遇到这个问题时，我曾想过两个方法。第一个是把元数据放到所有数据的中心位置。第二个方法是把元数据和它本身的数据放在一起。

 

许多研究和归档系统都采用第一种方法。它非常简单，就是收集特定文件的元数据并存储起来。这种方法广泛用于数据库中，你可以按照自己的需求搜索数据库，寻找含有你感兴趣信息的文件（在这里我们假设元数据是正确的，否则那就是另外一回事了）。

 

搜索的结果往往是找到文件的位置（文件全名以及文件访问路径），接着你就可以把文件复制到某些处于活动状态的存储设备中再进行进一步的分析。

 

集中元数据这种方法面临的问题是元数据和文件之间的映射。举个例子，当各种文件的元数据升级时，你就需要一种更新机制去升级集中元数据的服务器。理想状态是，升级速度非常快，否则，搜索数据就会过期。但是你怎么定义“快”呢？这取决于你的用户和用户模式。

 

这种更新机制有一个潜在的问题。如果数据库和文件不同步怎么办？比方说，当一个文件被移动，它在数据库中的全路径不再有效时怎么办？

 

答案很明显，数据库也会失效，至少包含那个文件的数据库会失效。不过令人感到欣慰的是，更新机制会告诉数据库文件已经移动，数据库会采取相应的措施，或者为新的位置创建元数据，或者升级现有的元数据对应文件新的位置。在一些案例中，升级窗口还会影响升级数据库。

 

还有一点需要注意，就是数据库本身的数据完整性。你需要利用备份，复制或其它相似的功能来进行数据保护。不要忘了数据库主要功能是从中读取数据，这就意味着你需要注意数据库的大小，注意读取错误。一些厂商会从消费级SATA硬盘中建立索引，当你读取100GB的数据时，你就有可能遇到读取错误。如果你借助RAID控制器建立存储，你就有可能重建，而在重建过程中，你还有可能遇到新的问题。

 

第二种方法，把元数据和数据存储在一起。这种方法很可取，因为这样你就只需担心一个文件系统的数据完整性了。如果文件被移动，元数据也随之移动。你可以随时把元数据加入到文件中，因为它就和文件在一起。

 

理想的状态是，如果我们有好的工具来和文件一起复制，移动元数据，那我们就可以轻松地复制或移动数据文件。比如说，你把文件复制到某些活动状态存储中，元数据就要和其一起移动。这还意味着你可以升级这些文件的元数据，然后把它们复制回去，把升级后的元数据和文件放在一起。

 

我们可以借助扩展属性（扩展文件属性）来达到这一目的。许多文件系统都支持扩展属性，为用户提供多种选择，使用户可以通过扩展文件属性把元数据添加到文件中，当然，它们也提供多种文件读取方式。一些文件系统会对扩展属性强加限制，比如说加入数量的限制，但并不是所有的文件系统都这样。不管怎么说，把元数据和数据存储在一起是一个值得考虑的方法。

 

但是凡事有利就有弊，把元数据和数据存储在一起也有许多缺点。首先就是用户如何有效率地搜索元数据？

 

搜索的主要方式是扫描文件系统的树形结构，找到每个文件的元数据然后返回信息。但是这种方式要受到文件数量及文件树形结构的影响，搜索可能会花大量的时间，也许会浪费大量的时间做无用功。

 

如果你想寻找文件，那你就需要搜索所有文件的元数据。不幸的是，目前几乎没有令人满意的工具或技术把文件（包括元数据）复制到其它存储（或活动状态的存储设备）中。举个例子，NFS不支持扩展文件属性的传输，用户就不能通过它复制文件或从归档转移到活动位置。有复制文件和元数据的方式，但是你需要花大量的精力确保能达到你预期的效果。

 

更好的方法

 

我个人认为第二种方法会好一些，因为元数据总是和数据在一起，这样用户就可以随时访问元数据。在第一种把元数据集中起来的方法中，除了要保护数据之外，你不得不使用额外的资源来保护数据库，保证其精确性。考虑到那难以置信的数据量，再加上需要保护的新的归档，我现在觉得这两种方法都不够完美。

 

既然这样，那何不把这两种方法结合起来！

 

我仍然觉得元数据应该和数据存储在一起，最主要的原因就是元数据相对于数据而言，本身就是相同的东西，把它们分开没有多大的意义。

 

不过，扫描含有上亿个文件的树形结构也是不现实的。所以，我们需要专为搜索设计的框架，在其中建立一个集中元数据索引，不过所有元数据的功能仍在于文件本身。

 

如果我们创建了一个归档并把所有的数据都放入其中，那我们就可以抓取元数据并建立一个集中索引。当文件移动到归档中时，我们可以把元数据集中在一个文件中。

 

令人欣慰的是，归档本身的机制可以发现归档中文件的改变，获取元数据并升级集中索引。但是，若是归档有REST接口，那就没有好的方式去“升级”文件。如果你从一个归档中提取了一个文件并做了更改，大多数情况下，你都需要把整个文件再放回到归档中，因为对于归档来说，这是一个“新”文件。有一些归档允许用户升级文件，但是这种机制用起来并不容易，相比之下，提取文件，做更改，再放回去则是非常简单。在这种情况下，提取操作要获取元数据，这使得这一步骤变得简单。

 

对于所有元数据来说，发挥作用的是文件，元数据只是附加其上（我个人认为使用的是扩展文件属性）。如果集中索引因为某些原因失效了，你要花一些时间扫描文件系统来“重新收集”元数据，但是你并没有从根本上失去你的索引。

 

总结

 

人们曾经认为把元数据存储在什么地方这个问题非常简单，根本用不着进行长时间的讨论。直到有一天人们突然发现，如今的世界已经天翻地覆，大数据呈爆炸式增长，文件数量上亿，这时候考虑元数据放到哪里就变得非常重要，处理好这个问题，对于数据的实际使用有重大意义。

 

把所有元数据放到集中索引是不切实际的，因为这样你就必须进行大量的数据保护，不仅要保护数据，还要保护集中索引。仅仅移动文件位置而不升级索引会对搜索带来极大的影响。

 

同样的，借助扩展文件属性把元数据和数据放在一起也不可取，因为每次数据搜索都意味着元数据要通过树形结构被搜集起来再搜索。虽然把元数据和数据放在一起非常自然，但是这种存储方式往往会浪费大量的搜索时间。

 

我认为最好的解决方案是把这两种方式结合在一起。把元数据放在数据中，当数据被移动到归档中时，你就可以把元数据提取出来，同时建立一个集中索引，用这个索引来进行数据搜索。

 

借助一个简单的REST接口，就可以很轻松地升级索引。但是，如果索引丢失或崩溃了，那就需要再次扫描归档的树形结构来重新收集元数据了。

 

这篇文章的目的是能引发人们对元数据存储在何地以及如何搜索它们这个问题的思考，肯定会有人对我的观点提出质疑。如果有可能的话，请你们写下自己的解决方案，一定会有很多人从你们的分享中受益匪浅的！

 

通过上面的介绍，大家可能对元数据有了一定的了解，我们将持续更新关于元数据的专业知识观点，更多数据类及大数据的资讯内容可以关注CPDA数据分析师官网。