[发明专利]处理HDFS元数据的方法及系统

说明书

技术领域

本发明涉及数据库技术领域，具体涉及一种处理HDFS元数据的方法及系统。

背景技术

HDFS（Hadoop Distributed File System）是指HADOOP分布式文件系统，其具有高容错性的特点，设计用来部署在低廉的硬件上，它提供高吞吐量来访问应用程序的数据，适合那些有着超大数据集的应用程序，可以实现流的形式访问文件系统中的数据。

名称节点NameNode是HDFS组成架构当中的元数据存储构件。在当前的HDFS架构当中，名称节点NameNode是一个非常重要的组件，负责文件元数据的管理，诸如文件命名空间、文件块等信息。同时负责协调各个节点间的管理，如节点的有效性检查、文件块的冗余复制，文件的创建、删除等行为。不过HDFS目前架构中NameNode不支持集群部署，不提供先行扩展能力，基于单机有内存容量限制，HDFS管理的文件数量规模有上限的，这些大大限制了HDFS作为MapReduce（概念化简）数据载体的应用场景。

现有技术中，HDFS目前通过Secondary NameNode（辅助名称节点）来提供灾备方案，通过定时同步文件系统信息至Secondary NameNode来实现。NameNode将对文件系统的改动追加保存到本地文件系统上的一个日志文件（edits）。当一个NameNode启动时，它首先从一个映像文件（fsimage）中读取HDFS的状态，接着应用日志文件中的edits操作。然后它将新的HDFS状态写入（fsimage）中，并使用一个空的edits文件开始正常操作。因为NameNode只有在启动阶段才合并fsimage和edits，所以时间长后日志文件可能会变得非常庞大，特别是对大型的集群更是如此。日志文件太大的另一个副作用是下一次NameNode启动会花很长时间。另外Secondary NameNode定期合并fsimage和edits日志，将edits日志文件大小控制在一个限度下。因为内存需求和NameNode在一个数量级上，所以通常secondary NameNode和NameNode运行在不同的机器上。在HDFS架构当中Secondary NameNode在逻辑上并不是作为NameNode的备份来部署的，它是作为一个日志合并的进程来运行的，在实际的部署当中，Secondary NameNode通常又可以通过文件拷贝的方式实现灾备的能力，因此Secondary NameNode本身是一个非专业的灾备方案。

因此，本发明的发明人发现：现有技术NameNode不能实现对海量文件的支持，不支持集群，限制了支持文件数量规模的增长的能力，而Secondar NameNode的灾备方案并不是一个实时、有效的灾备方案，其对元数据的同步是采用异步模式，并且是基于文件拷贝的方式，因此存在数据丢失的潜在危险，数据安全性较低。

发明内容

本发明提供一种处理HDFS元数据的方法及系统，能够提高数据处理能力及数据安全性。

一种处理HDFS元数据的方法，其包括：

建立基于数据库Cassandra的内存集群；

将分布式文件系统HDFS元数据存储到Cassandra集群中的分布式数据库；

对存储到Cassandra集群中的分布式数据库的HDFS元数据进行处理操作。

所述将HDFS元数据存储到Cassandra集群中的分布式数据库包括：

将HDFS元数据通过冗余复制存储到Cassandra集群中的分布式数据库。

所述将HDFS元数据通过冗余复制存储到Cassandra集群中的分布式数据库包括：

将每份HDFS元数据在Cassandra集群的内存中的N个节点形成冗余，所述N大于1。

所述建立基于Cassandra的内存集群包括：

采用P2P分布式技术建立基于Cassandra的内存集群，结合一致性哈希算法将所述内存集群形成一个环状。

所述对存储到Cassandra集群中的分布式数据库的HDFS元数据进行处理操作包括：

对存储到Cassandra集群中的分布式数据库的HDFS元数据进行至少以下一项操作：查询、插入、删除。

所述删除包括：修改Cassandra在内存中的数据删除策略，在Cassandra的Tomb Mark的删除基础上增加内存记录的删除。