[发明专利]一种面向多数据类型访问应用的分布式文件系统

说明书

技术领域

本发明属于计算机存储技术领域，更具体地，涉及一种面向多数据类型访问应用的分布式文件系统。

背景技术

随着信息科技的不断创新，信息化水平不断提高，人们对计算能力、存储能力的需求呈现出爆炸式增长。应用程序需要存储PB、TB级的数据，即使增加更多的计算节点，更多的磁盘和处理器，也不能提供足够快的计算，因为文件存取速度成为主要瓶颈。元数据是用来描述一个文件系统特征的数据，对数据操作起着至关重要的作用，因此元数据的设计就成为关键。

目前对于元数据的研究都集中于怎样组织元数据，使得对元数据定位速度快，最终实现数据的高效存取。其最大的特点在于：对数据的高效访问只适合于某一特定访问类型的数据（例如一次写多次读），一旦数据访问类型混杂，系统存取文件的效率和存储空间利用率都会大大降低。

现有的运用最广泛的分布式文件系统有GFS（Google File System，谷歌文件系统）、HDFS（Hadoop Distributed File System，Hadoop分布式文件系统）等，大多文件系统的元数据设计与GFS类似。

元数据存储在主结点，负责对数据进行统一的管理。元数据保存文件和存储块的命名空间、文件名到存储块的映射关系、存储块到存储结点的映射关系,下图以google文件系统为例（如图1所示）。

应用程序访问文件时，首先向存储元数据的主结点Master发送文件名、文件偏移量。访问请求到达主结点后，先根据文件名和文件偏移量，查找文件到存储块的映射表——哈希表1（hash1）计算出数据所在的文件块的块编号，然后根据文件块号到子结点的映射表——哈希表2（hash2）查找到数据对应存储的某个子结点号的编号。最后主结点将得到的文件块编号和子结点编号发送到应用程序端，应用程序端与相应的子结点建立连接，在子结点中获取数据。

例如，当为一个动漫渲染应用设计底层分布式文件系统时，借鉴GFS文件系统中的元数据设计模型会导致整个系统性能下降。渲染的过程中，读取的文件主要为纹理图片文件，纹理图片一次性写入，永久储存。其他的文件包括深度图、点缓存（烘培）、光子图等信息，这类数据每帧约几百兆，动态生成，渲染完成后删除。对于纹理图片文件，原有的元数据设计模型恰好能满足应用需求，但由于应用中包含大量的动态生成文件，需要实时进行文件的添加、删除，故应用程序的性能不高。

发明内容

针对上述文件系统底层数据访问模式多样化，导致的传统元数据设计模式不能解决的问题，本发明引入面向多数据类型访问应用的分布式文件系统给予解决。

本发明提供了一种面向多数据类型访问应用的分布式文件系统，所述分布式文件系统的主结点中包含有多类元数据，其中：

每类元数据包含有元数据哈希表和相应的元数据控制结构体，每类元数据对应相应的数据类型，所述数据类型是根据数据访问特性进行分类的；每类元数据控制结构体用于针对相应的数据类型进行分类管理；

所述系统在接收到应用程序访问请求时，根据应用程序访问请求所需访问文件的类型确定相应类别的元数据控制结构体，将相应类别的元数据控制结构体的信息返回给应用程序，以使所述应用程序根据所述控制信息，在相应的数据存储结点中行相应的文件操作。

进一步地，所述数据类型包括静态数据、流式数据、动态生成数据、动态增长数据以及日志文件类数据，所述元数据控制结构体的成员变量至少包括元数据类别ID、数据块大小、存储方式、备份块数量以及预取策略。

进一步地，其特征在于，所述数据类型及相应的元数据控制结构体，具体为：

所述静态数据：其特性为一次写入，多次读；其对应元数据控制结构体中成员变量依次为：元数据类别ID为01；数据块大小范围为30M-60M；存储方式为连续存储；备份块数量为2-4个；预取策略为相邻数据预取；

所述流式数据：其特性为数据不断写入，处理完毕后流出系统；其对应元数据控制结构体中成员变量依次为：元数据类别ID为02；数据块大小为大于或等于60M；存储方式为连续存储；备份块数量为1个；预取策略为相邻数据预取；

所述动态生成数据：其特性为数据在系统运行中动态生成；其对应元数据控制结构体中成员变量依次为：元数据类别ID为03；数据块大小为：小于100M的按照自身大小分块，否则按100M分块；存储方式为本地存储；备份块数量为1个；预取策略为本地预取；