[發明專利]基于HBase的高效存儲方法及系統

有效

• 申請號: 201410188339.9
• 申請日: 2014-05-06
• 公開（公告）號: CN104008134B
• 公開（公告）日: 2017-02-15
• 發明（設計）人: 向智宇;郝俊瑞;高漢松;郭嘉;許德瑋;王靜
• 申請（專利權）人: 武漢郵電科學研究院
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京捷誠信通專利事務所(普通合伙)11221
• 代理人: 魏殿紳,龐炳良

技術領域

本發明涉及大數據領域，具體是涉及一種基于HBase的高效存儲方法及系統。

背景技術

隨著移動互聯網、智能終端、物聯網、云計算以及智慧城市的普及，人們逐漸進入了“大數據”時代。美國互聯網數據中心指出，互聯網上的數據每年將增長50％，每兩年便將翻一番，而目前世界上90％以上的數據是最近幾年才產生的。除了互聯網上發布的信息，全世界的工業設備、汽車、電表上有著無數的數碼傳感器，隨時測量和傳遞著有關位置、運動、震動、溫度、濕度乃至空氣中化學物質的變化，也產生了海量的數據信息。

大數據是規模非常巨大和復雜的數據集，數據量達到拍字節、艾字節或澤字節的級別后傳統數據庫管理工具處理起來面臨很多問題，如獲取、存儲、檢索和分析等。大數據引發了一些問題，如對數據庫高并發讀寫要求、對海量數據的高效率存儲和訪問需求、對數據庫高可擴展性和高可用性的需求，傳統數據庫以及數據倉庫技術顯得力不從心。

Hadoop是由Apache軟件基金會維護的一個能夠對大量數據進行分布式處理的軟件框架，Hadoop帶來了廉價的處理大數據的能力。Hadoop是一個龐大的生態系統，為處理大數據提供了各種工具和平臺。在Hadoop生態系統中，HBase是一個高可靠性、高性能、面向列、可伸縮的分布式非關系型數據庫系統，可快速在海量數據中定位所需結果。

HBase作為列存儲數據庫，表中的每個列，都歸屬于某個列族，列族是表的結構的一部分，必須在使用表之前定義，而列的數量以及類型則無需定義，因為它不屬于表的結構。一個列族中可以包含多個列，這些列以其所在列族作為前綴命名，格式是<列族>:<列>。HBase中數據的讀寫都是在列族層面進行。

HBase中的用戶數據都以HFile格式存儲在Hadoop文件系統上，HBase專有的存儲格式參見圖1所示，HFile格式中的數據塊是實際存放用戶數據的地方，每個數據塊由一個防止數據損壞的隨機數字開頭，和其后緊接的若干個鍵值對拼接而成，鍵值對是HBase中不可再分的最小數據單元。

參見圖2所示，鍵值對是一個字節數組，包含了很多項，并且有固定的結構，其具體結構組成如下：鍵值對開始是兩個固定長度的數值，分別表示鍵部分的長度和值部分的長度；緊接著是鍵部分，開始是固定2字節長度的數值，表示行鍵的長度；接著是行鍵值；然后是固定1字節長度的數值，表示列族名的長度；然后是列族名和列名；然后是固定8字節長度的時間戳和固定1字節長度的類型，標記該鍵值對是插入操作還是刪除操作；最后是值部分存放該列的值。

從圖2中可以算出每個鍵值對的固定部分有22個字節(假定列族名和列名都是1個字節)，如果按照行鍵值長度一般最少10個字節，那么一個鍵值對最少有32字節以上，而此時該鍵值對中的值部分卻只存儲了一個列的值，也就是說在HFile的存儲中，一行記錄的每個列都會存儲為一個鍵值對。假如一個表中有N個列，N為正整數，那么存儲這個表的一行數據就需要N個這樣的鍵值對，固定消耗大約在(32*N)字節，而這些鍵值對中的鍵部分又基本上是相同的，這就在存儲空間上造成極大的浪費，同時對HBase的吞吐性能也會造成一定影響。

以如下結構化模型定義的表結構為例：

{列1(主鍵)：列1數據類型；列2：列2數據類型；列3：列3數據類型；列4：列4數據類型}

該表有4列，其中第一列是主鍵。

如果使用HBase固有方式存儲該表，定義列族為F1，并將這些列都放在F1中，則例子中結構化表和HBase存儲關系為：

列1對應行鍵；

列2對應<F1:C2>列；

列3對應<F1:C3>列；

列4對應<F1:C4>列；

由此可知，該結構化表的一行記錄在HBase中存儲需要3個鍵值對，其存儲結構參見圖3所示，可以看到，對例子中的一行記錄來說，需要3個鍵值對來存儲，固定長度開銷約為(32*3)字節，當海量記錄存儲時，就會有大量固定長度的存儲開銷，這樣既浪費存儲空間，又影響存儲吞吐性能。

發明內容

本發明的目的是為了克服上述背景技術的不足，提供一種基于HBase的高效存儲方法及系統，能有效節省HBase的存儲空間，提高HBase的吞吐性能。

本發明提供一種基于HBase的高效存儲方法，包括以下步驟：

步驟101、輸入一行待存儲到目標表的用戶數據；