摘  要： 通過分析HBase的特點，提出了一種基于HBase的海量微博數據高效存儲方案。該方案通過建立合適的數據存儲模型、預建Region，提出行關鍵字生成規則和跳過壞記錄的方法，使得數據能夠利用MapReduce模型高效且不間斷地導入HBase數據庫。實驗結果表明，該方法能夠提高海量數據導入HBase的效率。

　　關鍵詞： Hadoop；HBase；MapReduce；微博；行關鍵字；跳過壞記錄

　　隨著網絡技術的快速發展，互聯網用戶激增，同時產生了海量的互聯網數據。據不完全統計，截至2012年12月底，新浪微博注冊用戶數已超過5億，每天新浪微博用戶發博量超過1億條。微博的使用人群數量基數大，狀態信息更新頻繁，信息傳播迅速，這為研究網絡用戶行為與心理提供了充足的資源，也帶來了挑戰。

　　面對如此海量的微博數據，如何將其高效的存儲與管理，已經成為一個迫切需要解決的問題。云計算技術的出現，為解決這一問題提供了新的途徑和思路。目前谷歌、亞馬遜、微軟、IBM等知名企業紛紛推出云計算解決方案。Apache的Hadoop[1]是一個開源的云計算平臺，其核心是HDFS、MapReduce和Hbase。Hbase是一個開源的、面向列的分布式數據庫，它是基于HDFS的，可以利用集群處理大數據。

　　目前已有105萬個新浪微博用戶以JSON[2]格式保存的文本數據，數據容量為8.9 TB。如此大量的數據使用單臺計算機進行結構化存儲和處理是極其耗費時間的。本文主要研究基于MapReduce模型解析JSON格式的微博數據，并將其高效地導入Hbase數據庫，為海量數據的高效存儲提供一種解決方案。

　　1 HBase概述和MapReduce模型

　　HBase[3]是一個基于HDFS的、開源的、面向列的分布式數據庫。HBase是基于列簇存儲的，不同的列簇對應HDFS上的不同的目錄文件，此目錄文件中存儲的是HBase底層存儲文件（HFile文件），當目錄中HFile文件數量過多時，HBase會進行compact操作，合并HFile文件。HBase的每個表都有一個或幾個列簇，每個列簇可以包含任意數量的列，且每行的列不必相同。HBase表中的每一行由行關鍵字、時間戳和列簇組成。

　　HBase有多種數據導入方式，最直接的方法是在MapReduce任務中用TableOutputFormat導入或者直接使用正常的客戶端API導入。但是這些都不是最高效的方法。BulkLoad可以通過MapReduce任務直接生成HFile文件，然后導入HBase的表中，適合大數據的快速導入。因此在本文中主要針對BulkLoad方法進行改進。

　　MapReduce[4]是一個處理數據的編程模型。它有兩個重要的函數：Map和Reduce。這兩個函數是順序執行的，Map執行完畢后，開始執行reduce。Map負責分解任務，Reduce負責把各Map任務的結果匯總。

　　2 微博數據高效存儲方案

　　2.1 微博數據的存儲模型

　　HBase數據庫存儲微博用戶的信息以及微博內容信息，數據庫表設計如表1和表2所示。HBase有多種數據導入方式，最直接的方法是在MapReduce任務中用TableQutputFormat導入或者直接使用正常的客戶端API導入。但這些都不是最高效的方法。basic_info列簇存儲微博用戶的基本信息，statuses_id列簇存儲微博的id，即表2中的行關鍵字，列名“statuses_id”指的是微博的id，用列名存儲用戶發布的所有微博信息，”user_id”也是如此。sina_relationship列簇用于存儲微博用戶關系。在表2中，basic_info列簇用于存儲常用的微博內容的基本信息，other_info列簇用于存儲不常用的微博內容的信息，這樣劃分是考慮到HBase是按列簇存儲的，避免造成I/O浪費。text_info列簇存儲的是微博的文本內容。

　　微博內容信息表中的basic_info：user_id和微博用戶信息表中的statuses_id：“statuses_id”形成二級索引，用于關聯兩個表。

　　2.2 微博數據存儲的優化

　　2.2.1 預創建Region

　　HBase在建表時，默認只有一個Region。當使用BulkLoad[5]導入數據時，當數據達到一定的規模（默認是256 MB，設置為200 GB）時，Region會被分割，這將嚴重影響導入性能。

　　因此可以預創建一定數量的空Region，至于Region的數量可以參考數據量、Region設定的容量和RegionServer的數量來決定。Region的數量最好是RegionServer的整數倍，這有利于HBase使用MapReduce進行數據處理。數據量除以預創建Region的數量應當小于Region的設定容量，這可以避免在數據導入時，Region進行split操作。

　　運行MapReduce程序生成的每個HFile文件中的行關鍵字不屬于獨立的Region時，導入時會發生文件分割。通過實驗得知，將總大小為115 GB的HFile文件導入到有32個Region的表中，耗時130 min，而且由于分割HFile文件的過程中會生成較多的臨時文件，需要較大的額外存儲空間。

　　為了解決這一問題，需要使得生成的每個HFile文件屬于單個Region，因此需要制定行關鍵字生成規則。

　　2.2.2 行關鍵字生成規則

　　HBase按照行關鍵字的字典序來存儲數據。Hbase提供了多種數據查詢方式：根據行關鍵字調用get接口查詢，調用scan查詢，全表掃描等。

　　為了提高數據導入效率和查詢效率，提出了行關鍵字的生成規則。為了滿足HFile文件所屬Region的唯一性，需要行關鍵字有Region識別的功能，因此行關鍵字中需要包含Region識別字段。為了保證查詢效率，對于微博內容信息表，需要將同一個微博用戶的微博在HBase中連續存儲，這就要求行關鍵字中包含用戶信息字段，以保證將所需微博聚集在一起。為了保證行關鍵字的唯一性，行關鍵字需要包含微博內容的關鍵字。式（1）是微博內容信息表的行關鍵字生成規則。式（2）是微博用戶信息表的行關鍵字生成規則。

　　行關鍵字=Region識別字段+微博用戶ID+微博內容ID（1）

　　行關鍵字=Region識別字段+微博用戶ID（2）

　　2.2.3 跳過壞記錄

　　由于下載的微博數據是JSON格式的，因此首先需要對微博數據進行解析，然后導入HBase數據庫。由于數據量大，因此需要使用MapReduce編程模型來解析數據。

　　MapReduce需要所有的Map任務都結束后，才能進行接下來的工作。如果有一個Map任務執行多次（默認是4次）均失敗，則整個MapReduce任務失敗，從而造成了時間和資源的浪費。例如，下載的微博數據中有損壞的，也有JSON格式不完整的，還有文件過大導致內存溢出的等，這都會導致MapReduce任務失敗。

　　MapReduce有Skipipng mode，設置開啟后，可以跳過壞記錄，但是這種模式會大大影響效率，而且對于內存溢出錯誤無法處理，也不能對跳過壞記錄的文件進行標記。

　　為了能夠跳過程序運行過程中的錯誤，并將壞記錄所在文件保存到指定文件目錄中，提出重寫RecordReader的方法，稱之為SK-bad。由于將整個文件作為數據分片，可以在RecordReader中獲得數據分片的文件名。然后獲得任務ID，分析任務ID得出任務的執行次數，當執行次數達到一定數值時（此數值需要自己指定，且要小于任務失敗最大重復執行次數，否則不會起作用），將此文件移動到指定文件目錄，與此同時將此記錄標記為已處理，從而能夠保證跳過任何原因引起的壞記錄。核心程序代碼如下。

　　public class WholdeFileRecordReader

　　extends RecordReader<BytesWritable，BvtesWritable>{

　　……

　　public void initialize{InputSplit split，TaskAttempt Context context）}

　　……

　　String[]strtaskid=

　　context.getTaskAttemptid（）.tostring（）.trim（）.split（“_”）

　　String reindex=

　　straskid[strtaskid.length-1]；

　　if（integer.parseitn（reidex）>4）{|

　　……

　　}

　　……

　　}

　　}

　　3 實驗

　　3.1 實驗環境

　　利用6臺計算機作為宿主機，其中有4臺Dell OptiPlex 990，配置均為：CPU為Intel酷睿i3 2120，內存12 GB，千兆以太網卡。一臺Dell T3500，配置為：CPU為Xeon W3565，內存24 GB，千兆以太網卡。一臺浪潮NP3060，配置為：CPU為Xeon E5506，內存16 GB，集成雙千兆網卡。每臺宿主機均安裝Xen虛擬機，每臺Dell OptiPlex 990虛擬出3臺虛擬機。Dell T3500虛擬出6臺虛擬機，浪潮NP3060虛擬出4臺虛擬機。總共有22臺虛擬機，每臺虛擬機的操作系統均為64 bit Centos 6.2。

　　每臺虛擬機安裝Hadoop 1.0.4和HBase 0.94.5，其中一臺作為Master運行NameNode，JobTracker和Hmaster，一臺運行SecondNamenode，其余20臺為Slaves運行DataNode，TaskTracker和RegionServer。

　　解析JSON數據使用的是第三方工具包Jackson[6]。

　　實驗使用的數據是以文本文件保存的JSON格式的微博數據，每個文件大小在100 MB~180 MB之間，含有105萬用戶的信息。總的數據容量為8.9 TB。

　　3.2 實驗結果及分析

　　使用10 000個微博數據文件，每2 000個文件作為一次測試中MapReduce任務的輸入，共5次測試。用于測試MapReduce任務在使用SK-bad方法時任務失敗次數，同時測試MapReduce任務在未使用SK-bad方法時的失敗次數和開啟Skipping mode時的失敗次數來進行比較。引起的原因有數據過大導致內存溢出、文件不完整、錯誤的JSON格式和文件校驗碼錯誤等。實驗結果如表3所示，對于讀取文件的過程中發生的錯誤，Skipping mode無法處理，5次測試的結果表明SK-bad方法能夠保證MapReduce任務的順利執行。

　　接下來的測試均使用SK-bad方法，Region最大容量設置為200 GB，預創建Region數量為120個。分別測試在未預創建Region且不使用行關鍵字生成規則的情況下（情況一），預創建Region且不使用行關鍵字生成規則的情況下（情況二）和預創建Region且使用行關鍵字生成規則情況下（情況三）的存儲性能。

　　實驗結果如圖1所示，存儲9 000個用戶的數據時，在情況一下，由于數據量較小，Region不會split，所以存儲性能與情況三下的存儲性能相近。在情況二下，MapReduce任務所生成的HFile文件不屬于單個Region，且Region數量較多，因此HFile會進行多次split操作，這嚴重影響了存儲性能。在存儲30 000個用戶的數據時影響性能的因素與存儲9 000個用戶的數據時相似；在存儲60 000個用戶的數據時，對于情況一，由于數據量較大會使Region做split操作，這嚴重影響存儲性能；在存儲90 000個用戶的數據時影響性能的因素與存儲60 000個用戶的數據時相似；在存儲120 000個用戶的數據時，在情況一下，由于數據量較大會使Region再次做split操作，使得Region數量增多，這更加影響存儲性能，并且隨著用戶數據的增多，Region數量也會增加，存儲性能會隨之降低。在情況三下，由于Region不需要做split操作，且生成的每個HFile屬于唯一的Region，因此隨著數據量的增長，存儲時間接近線性增長。

　　在預創建Region且使用行關鍵字生成規則的情況下，存儲所有8.9 TB共1 068 090個微博用戶的數據，耗時65 h 34 min。

　　本文通過分析HBase和MapReduce模型，提出了一種通過預創建Region、行關鍵字生成規則，利用MapReduce模型將微博數據高效導入HBase數據庫的方案，并提出了能夠處理各種運行錯誤的SK-bad方法。

　　未來要做的工作是優化MapReduce對HBase的訪問效率，利用HBase數據庫中的數據進行網絡用戶行為分析方面的研究。

　　參考文獻

　　[1] Hadoop[EB/OL]. [2013-07-01]. http：//hadoop.apa-che.org/.

　　[2] Introducing JSON[EB/OL]. [2005]. http：//www.j-son.org/.

　　[3] HBase：Bigtable-like structured storage for Hadoop HDFS[EB/OL].[2012-08-24].http：//wiki.apache.o-rg /hadoop/Hbase/.

　　[4] 李建江，崔健，王聃.MapReduce并行編程模型研究綜述[J].電子學報，2011，39（11）：2635-2642.

　　[5] GEORGE L. HBase： the definitive guide[M]. USA： O′Reilly Media， 2011.

　　[6] Jackson： High-performance JSON processor[EB/OL].[2013-04-30]. http：//jackson.codehaus.org.