[發明專利]處理HDFS元數據的方法及系統

無效

• 申請號: 201210209078.5
• 申請日: 2012-06-21
• 公開（公告）號: CN102737130A
• 公開（公告）日: 2012-10-17
• 發明（設計）人: 武良軍;袁曉鵬
• 申請（專利權）人: 廣州從興電子開發有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京集佳知識產權代理有限公司 11227
• 代理人: 王寶筠

技術領域

本發明涉及數據庫技術領域，具體涉及一種處理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的刪除基礎上增加內存記錄的刪除。