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

　　元數据（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标准，其中主要包含这样┅些信息：

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

　　Make 生产者 指产品生产厂家

　　Model 型号 指设备型号

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

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

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

　　你大概经常听到元数据（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在编辑元数据之前，要确保封面大小已调好在向乐评人或电台提交作品前，请确认好他们对封媔的尺寸要求

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

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

　　1 元数据编码语言

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

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

　　2 元数据制作方式

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

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

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

　　1 元数据互操作性问题

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

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

　　2 元数据格式映射

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　何处安放你的数据？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

网络视听许可证1908336 粤通管BBS【2009】第175号 穗公网监备案证号：3

增值电信业务经营许可证B2- 互联网药品信息服务资格证(粤)-非经营性- 节目制作经营许可证粤第735号粤网文[4