基于HBase的海量微博數(shù)據(jù)高效存儲解析
通過分析HBase的特點(diǎn)，提出了一種基于HBase的海量微博數(shù)據(jù)高效存儲方案。該方案通過建立合適的數(shù)據(jù)存儲模型、預(yù)建Region，提出行關(guān)鍵字生成規(guī)則和跳過壞記錄的方法，使得數(shù)據(jù)能夠利用MapReduce模型高效且不間斷地導(dǎo)入HBase數(shù)據(jù)庫。實(shí)驗(yàn)結(jié)果表明，該方法能夠提高海量數(shù)據(jù)導(dǎo)入HBase的效率。
隨著網(wǎng)絡(luò)技術(shù)的快速發(fā)展，互聯(lián)網(wǎng)用戶激增，同時產(chǎn)生了海量的互聯(lián)網(wǎng)數(shù)據(jù)。微博的使用人群數(shù)量基數(shù)大，狀態(tài)信息更新頻繁，信息傳播迅速，這為研究網(wǎng)絡(luò)用戶行為與心理提供了充足的資源，也帶來了挑戰(zhàn)。
面對如此海量的微博數(shù)據(jù)，如何將其高效的存儲與管理，已經(jīng)成為一個迫切需要解決的問題。云計算技術(shù)的出現(xiàn)，為解決這一問題提供了新的途徑和思路。目前谷歌、亞馬遜、微軟、IBM等知名企業(yè)紛紛推出云計算解決方案。Apache的Hadoop[1]是一個開源的云計算平臺，其核心是HDFS、 MapReduce和Hbase。Hbase是一個開源的、面向列的分布式數(shù)據(jù)庫，它是基于HDFS的，可以利用集群處理大數(shù)據(jù)。
目前已有105萬個新浪微博用戶以JSON[2]格式保存的文本數(shù)據(jù)，數(shù)據(jù)容量為8.9 TB。如此大量的數(shù)據(jù)使用單臺計算機(jī)進(jìn)行結(jié)構(gòu)化存儲和處理是極其耗費(fèi)時間的。本文主要研究基于MapReduce模型解析JSON格式的微博數(shù)據(jù)，并將其高效地導(dǎo)入Hbase數(shù)據(jù)庫，為海量數(shù)據(jù)的高效存儲提供一種解決方案。
1 HBase概述和MapReduce模型
HBase[3]是一個基于HDFS的、開源的、面向列的分布式數(shù)據(jù)庫。HBase是基于列簇存儲的，不同的列簇對應(yīng)HDFS上的不同的目錄文件，此目錄文件中存儲的是HBase底層存儲文件(HFile文件)，當(dāng)目錄中HFile文件數(shù)量過多時，HBase會進(jìn)行compact操作，合并HFile文件。HBase的每個表都有一個或幾個列簇，每個列簇可以包含任意數(shù)量的列，且每行的列不必相同。HBase表中的每一行由行關(guān)鍵字、時間戳和列簇組成。
HBase有多種數(shù)據(jù)導(dǎo)入方式，最直接的方法是在MapReduce任務(wù)中用TableOutputFormat導(dǎo)入或者直接使用正常的客戶端API導(dǎo)入。但是這些都不是***效的方法。BulkLoad可以通過MapReduce任務(wù)直接生成HFile文件，然后導(dǎo)入HBase的表中，適合大數(shù)據(jù)的快速導(dǎo)入。因此在本文中主要針對BulkLoad方法進(jìn)行改進(jìn)。
MapReduce[4]是一個處理數(shù)據(jù)的編程模型。它有兩個重要的函數(shù)：Map和Reduce。這兩個函數(shù)是順序執(zhí)行的，Map執(zhí)行完畢后，開始執(zhí)行reduce。Map負(fù)責(zé)分解任務(wù)，Reduce負(fù)責(zé)把各Map任務(wù)的結(jié)果匯總。
2 微博數(shù)據(jù)高效存儲方案
2.1 微博數(shù)據(jù)的存儲模型
HBase數(shù)據(jù)庫存儲微博用戶的信息以及微博內(nèi)容信息，數(shù)據(jù)庫表設(shè)計如表1和表2所示。HBase有多種數(shù)據(jù)導(dǎo)入方式，最直接的方法是在 MapReduce任務(wù)中用TableQutputFormat導(dǎo)入或者直接使用正常的客戶端API導(dǎo)入。但這些都不是***效的方法。 basic_info列簇存儲微博用戶的基本信息，statuses_id列簇存儲微博的id，即表2中的行關(guān)鍵字，列名“statuses_id”指的是微博的id，用列名存儲用戶發(fā)布的所有微博信息，”user_id”也是如此。sina_relationship列簇用于存儲微博用戶關(guān)系。在表2 中，basic_info列簇用于存儲常用的微博內(nèi)容的基本信息，other_info列簇用于存儲不常用的微博內(nèi)容的信息，這樣劃分是考慮到HBase 是按列簇存儲的，避免造成I/O浪費(fèi)。text_info列簇存儲的是微博的文本內(nèi)容。
微博內(nèi)容信息表中的basic_info：user_id和微博用戶信息表中的statuses_id：“statuses_id”形成二級索引，用于關(guān)聯(lián)兩個表。
2.2 微博數(shù)據(jù)存儲的優(yōu)化
2.2.1 預(yù)創(chuàng)建Region
HBase在建表時，默認(rèn)只有一個Region。當(dāng)使用BulkLoad[5]導(dǎo)入數(shù)據(jù)時，當(dāng)數(shù)據(jù)達(dá)到一定的規(guī)模(默認(rèn)是256 MB，設(shè)置為200 GB)時，Region會被分割，這將嚴(yán)重影響導(dǎo)入性能。
因此可以預(yù)創(chuàng)建一定數(shù)量的空Region，至于Region的數(shù)量可以參考數(shù)據(jù)量、Region設(shè)定的容量和RegionServer的數(shù)量來決定。 Region的數(shù)量***是RegionServer的整數(shù)倍，這有利于HBase使用MapReduce進(jìn)行數(shù)據(jù)處理。數(shù)據(jù)量除以預(yù)創(chuàng)建Region的數(shù)量應(yīng)當(dāng)小于Region的設(shè)定容量，這可以避免在數(shù)據(jù)導(dǎo)入時，Region進(jìn)行split操作。
運(yùn)行MapReduce程序生成的每個 HFile文件中的行關(guān)鍵字不屬于獨(dú)立的Region時，導(dǎo)入時會發(fā)生文件分割。通過實(shí)驗(yàn)得知，將總大小為115 GB的HFile文件導(dǎo)入到有32個Region的表中，耗時130 min，而且由于分割HFile文件的過程中會生成較多的臨時文件，需要較大的額外存儲空間。
為了解決這一問題，需要使得生成的每個HFile文件屬于單個Region，因此需要制定行關(guān)鍵字生成規(guī)則。
2.2.2 行關(guān)鍵字生成規(guī)則
HBase按照行關(guān)鍵字的字典序來存儲數(shù)據(jù)。Hbase提供了多種數(shù)據(jù)查詢方式：根據(jù)行關(guān)鍵字調(diào)用get接口查詢，調(diào)用scan查詢，全表掃描等。
為了提高數(shù)據(jù)導(dǎo)入效率和查詢效率，提出了行關(guān)鍵字的生成規(guī)則。為了滿足HFile文件所屬Region的唯一性，需要行關(guān)鍵字有Region識別的功能，因此行關(guān)鍵字中需要包含Region識別字段。為了保證查詢效率，對于微博內(nèi)容信息表，需要將同一個微博用戶的微博在HBase中連續(xù)存儲，這就要求行關(guān)鍵字中包含用戶信息字段，以保證將所需微博聚集在一起。為了保證行關(guān)鍵字的唯一性，行關(guān)鍵字需要包含微博內(nèi)容的關(guān)鍵字。式(1)是微博內(nèi)容信息表的行關(guān)鍵字生成規(guī)則。式(2)是微博用戶信息表的行關(guān)鍵字生成規(guī)則。
行關(guān)鍵字=Region識別字段+微博用戶ID+微博內(nèi)容ID(1)
行關(guān)鍵字=Region識別字段+微博用戶ID(2)
2.2.3 跳過壞記錄
由于下載的微博數(shù)據(jù)是JSON格式的，因此首先需要對微博數(shù)據(jù)進(jìn)行解析，然后導(dǎo)入HBase數(shù)據(jù)庫。由于數(shù)據(jù)量大，因此需要使用MapReduce編程模型來解析數(shù)據(jù)。
MapReduce需要所有的Map任務(wù)都結(jié)束后，才能進(jìn)行接下來的工作。如果有一個Map任務(wù)執(zhí)行多次(默認(rèn)是4次)均失敗，則整個 MapReduce任務(wù)失敗，從而造成了時間和資源的浪費(fèi)。例如，下載的微博數(shù)據(jù)中有損壞的，也有JSON格式不完整的，還有文件過大導(dǎo)致內(nèi)存溢出的等，這都會導(dǎo)致MapReduce任務(wù)失敗。
MapReduce有Skipipng mode，設(shè)置開啟后，可以跳過壞記錄，但是這種模式會大大影響效率，而且對于內(nèi)存溢出錯誤無法處理，也不能對跳過壞記錄的文件進(jìn)行標(biāo)記。
為了能夠跳過程序運(yùn)行過程中的錯誤，并將壞記錄所在文件保存到指定文件目錄中，提出重寫RecordReader的方法，稱之為SK-bad。由于將整個文件作為數(shù)據(jù)分片，可以在RecordReader中獲得數(shù)據(jù)分片的文件名。然后獲得任務(wù)ID，分析任務(wù)ID得出任務(wù)的執(zhí)行次數(shù)，當(dāng)執(zhí)行次數(shù)達(dá)到一定數(shù)值時(此數(shù)值需要自己指定，且要小于任務(wù)失敗***重復(fù)執(zhí)行次數(shù)，否則不會起作用)，將此文件移動到指定文件目錄，與此同時將此記錄標(biāo)記為已處理，從而能夠保證跳過任何原因引起的壞記錄。核心程序代碼如下。
- public class WholdeFileRecordReader
- extends RecordReader{
- ……
- 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){|
- ……
- }
- ……
- }
- }
#p#
3 實(shí)驗(yàn)
3.1 實(shí)驗(yàn)環(huán)境
利用6臺計算機(jī)作為宿主機(jī)，其中有4臺Dell OptiPlex 990，配置均為：CPU為Intel酷睿i3 2120，內(nèi)存12 GB，千兆以太網(wǎng)卡。一臺Dell T3500，配置為：CPU為Xeon W3565，內(nèi)存24 GB，千兆以太網(wǎng)卡。一臺浪潮NP3060，配置為：CPU為Xeon E5506，內(nèi)存16 GB，集成雙千兆網(wǎng)卡。每臺宿主機(jī)均安裝Xen虛擬機(jī)，每臺Dell OptiPlex 990虛擬出3臺虛擬機(jī)。Dell T3500虛擬出6臺虛擬機(jī)，浪潮NP3060虛擬出4臺虛擬機(jī)?？偣灿?2臺虛擬機(jī)，每臺虛擬機(jī)的操作系統(tǒng)均為64 bit Centos 6.2。
每臺虛擬機(jī)安裝Hadoop 1.0.4和HBase 0.94.5，其中一臺作為Master運(yùn)行NameNode，JobTracker和Hmaster，一臺運(yùn)行SecondNamenode，其余20 臺為Slaves運(yùn)行DataNode，TaskTracker和RegionServer。
解析JSON數(shù)據(jù)使用的是第三方工具包Jackson[6]。
實(shí)驗(yàn)使用的數(shù)據(jù)是以文本文件保存的JSON格式的微博數(shù)據(jù)，每個文件大小在100 MB~180 MB之間，含有105萬用戶的信息?？偟臄?shù)據(jù)容量為8.9 TB。
3.2 實(shí)驗(yàn)結(jié)果及分析
使用10 000個微博數(shù)據(jù)文件，每2 000個文件作為一次測試中MapReduce任務(wù)的輸入，共5次測試。用于測試MapReduce任務(wù)在使用SK-bad方法時任務(wù)失敗次數(shù)，同時測試 MapReduce任務(wù)在未使用SK-bad方法時的失敗次數(shù)和開啟Skipping mode時的失敗次數(shù)來進(jìn)行比較。引起的原因有數(shù)據(jù)過大導(dǎo)致內(nèi)存溢出、文件不完整、錯誤的JSON格式和文件校驗(yàn)碼錯誤等。實(shí)驗(yàn)結(jié)果如表3所示，對于讀取文件的過程中發(fā)生的錯誤，Skipping mode無法處理，5次測試的結(jié)果表明SK-bad方法能夠保證MapReduce任務(wù)的順利執(zhí)行。
接下來的測試均使用SK-bad方法，Region***容量設(shè)置為200 GB，預(yù)創(chuàng)建Region數(shù)量為120個。分別測試在未預(yù)創(chuàng)建Region且不使用行關(guān)鍵字生成規(guī)則的情況下(情況一)，預(yù)創(chuàng)建Region且不使用行關(guān)鍵字生成規(guī)則的情況下(情況二)和預(yù)創(chuàng)建Region且使用行關(guān)鍵字生成規(guī)則情況下(情況三)的存儲性能。
實(shí)驗(yàn)結(jié)果如圖1所示，存儲9 000個用戶的數(shù)據(jù)時，在情況一下，由于數(shù)據(jù)量較小，Region不會split，所以存儲性能與情況三下的存儲性能相近。在情況二下，MapReduce任務(wù)所生成的HFile文件不屬于單個Region，且Region數(shù)量較多，因此HFile會進(jìn)行多次split操作，這嚴(yán)重影響了存儲性能。在存儲30 000個用戶的數(shù)據(jù)時影響性能的因素與存儲9 000個用戶的數(shù)據(jù)時相似;在存儲60 000個用戶的數(shù)據(jù)時，對于情況一，由于數(shù)據(jù)量較大會使Region做split操作，這嚴(yán)重影響存儲性能;在存儲90 000個用戶的數(shù)據(jù)時影響性能的因素與存儲60 000個用戶的數(shù)據(jù)時相似;在存儲120 000個用戶的數(shù)據(jù)時，在情況一下，由于數(shù)據(jù)量較大會使Region再次做split操作，使得Region數(shù)量增多，這更加影響存儲性能，并且隨著用戶數(shù)據(jù)的增多，Region數(shù)量也會增加，存儲性能會隨之降低。在情況三下，由于Region不需要做split操作，且生成的每個HFile屬于唯一的 Region，因此隨著數(shù)據(jù)量的增長，存儲時間接近線性增長。
在預(yù)創(chuàng)建Region且使用行關(guān)鍵字生成規(guī)則的情況下，存儲所有8.9 TB共1 068 090個微博用戶的數(shù)據(jù)，耗時65 h 34 min。
本文通過分析HBase和MapReduce模型，提出了一種通過預(yù)創(chuàng)建Region、行關(guān)鍵字生成規(guī)則，利用MapReduce模型將微博數(shù)據(jù)高效導(dǎo)入HBase數(shù)據(jù)庫的方案，并提出了能夠處理各種運(yùn)行錯誤的SK-bad方法。
未來要做的工作是優(yōu)化MapReduce對HBase的訪問效率，利用HBase數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行網(wǎng)絡(luò)用戶行為分析方面的研究。
參考文獻(xiàn)
[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].電子學(xué)報，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.
