摘 要： 主要介紹了HBase RegionServer與Zookeeper間的交互過程,，闡述RegionServer崩潰后的恢復(fù)機(jī)制,，并在此基礎(chǔ)上提出了幾點(diǎn)優(yōu)化的恢復(fù)措施。優(yōu)化后的恢復(fù)措施大大縮短了RegionServer崩潰后的故障恢復(fù)時(shí)間和業(yè)務(wù)中斷時(shí)間,，從而提高了HBase集群的穩(wěn)定性和可靠性,。
關(guān)鍵詞： HBase；RegionServer,；崩潰,；恢復(fù)
0 引言
隨著互聯(lián)網(wǎng)和通信行業(yè)的迅猛發(fā)展，積聚的各種數(shù)據(jù)呈急劇增長態(tài)勢,。這些海量數(shù)據(jù)既蘊(yùn)含著豐富的信息和資源,，又面臨著信息有效管理和提取的難題。云計(jì)算是分布式處理,、并行處理和網(wǎng)格計(jì)算的發(fā)展,，可以提供近乎無限的廉價(jià)存儲(chǔ)和計(jì)算能力，特別適合于日益暴增的海量數(shù)據(jù)的存儲(chǔ)和處理,。在云計(jì)算領(lǐng)域中,，Hadoop體系獨(dú)樹一幟，其豐富的子系統(tǒng)可以滿足多種領(lǐng)域和行業(yè)的應(yīng)用需求,，而其中的HBase作為一種非結(jié)構(gòu)化數(shù)據(jù)庫,，特別適合于各種非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)的存儲(chǔ)和管理。
HBase是一個(gè)高可靠性,、高性能,、面向列、可伸縮,、實(shí)時(shí)讀寫的分布式存儲(chǔ)數(shù)據(jù)庫系統(tǒng)[1-3],。HBase建立在HDFS分布式文件系統(tǒng)基礎(chǔ)之上，其中的數(shù)據(jù)最終以HFile的格式存儲(chǔ)在HDFS之上,；HBase可以通過內(nèi)嵌的MapReduce組件實(shí)現(xiàn)復(fù)雜任務(wù)的并行和分布處理,，具有很高的性能。
1 HBase體系結(jié)構(gòu)
HBase主要由HMaster和RegionServer兩部分組成,，輔以Zookeeper協(xié)調(diào)集群中各網(wǎng)元之間的數(shù)據(jù)共享和訪問,，其組成框圖如圖1所示[4]。
?。?）Client：訪問HBase的接口,，維護(hù)著一些加快HBase訪問的緩存，比如Region的位置信息等,。
?。?）Master：負(fù)責(zé)Region到RegionServer的分配以及映射關(guān)系維護(hù),；管理集群中的RegionServer及其負(fù)載均衡；維護(hù)數(shù)據(jù)表和其所在Region的元數(shù)據(jù)信息,；處理表級的操作請求等,。
（3）RegionServer：維護(hù)Master分配給它的Region,，處理對這些Region的讀寫請求,；負(fù)責(zé)運(yùn)行過程中過大的Region的Split和Compact操作。
?。?）Zookeeper：保證任何時(shí)候集群中只有一個(gè)激活的Master,；存儲(chǔ)RootRegion和Master的位置；存儲(chǔ)所有RegionServer的位置并實(shí)時(shí)監(jiān)控其狀態(tài),；存儲(chǔ)HBase的其他運(yùn)行所需的信息[5],。
HBase中的數(shù)據(jù)單元通過主鍵、列簇,、列名和版本號唯一確定，所有行按字典順序排列,。HBase中的表在行的方向上分割為多個(gè)Region,，每個(gè)Region只存儲(chǔ)表中某一范圍的數(shù)據(jù)，并且每個(gè)Region只能被一個(gè)RegionServer管理,。Region由一個(gè)或者多個(gè)Store組成,，每個(gè)Store保存一個(gè)列簇；Store又由一個(gè)MemStore和0至多個(gè)storefile組成,，storefile以HFile的格式存儲(chǔ)于HDFS上,。
由此可見，HBase中的表通常被劃分為多個(gè)Region,，而各個(gè)Region可能被不同的RegionServer所管理,。客戶端通過Master和相關(guān)操作獲取目標(biāo)Region的位置后,，最終通過RegionServer完成對用戶表的讀寫請求,。因此，如果某個(gè)RegionServer異常,，客戶端對其所管理的Region的訪問就會(huì)失敗,，造成了業(yè)務(wù)中斷，這在在線系統(tǒng)中是不可接受的,。雖然HBase中實(shí)現(xiàn)了RegionServer異常后的自動(dòng)恢復(fù)機(jī)制,，但是這種機(jī)制的時(shí)延很大，不能滿足實(shí)際應(yīng)用需求,。因此,，本文針對這部分進(jìn)行了研究,，并提出了一種可以快速、高效恢復(fù)業(yè)務(wù)的方法,。
2 HBase集群與Zookeeper交互機(jī)制分析
在HBase的使用過程中,，Zookeeper起著至關(guān)重要的作用。正是Zookeeper的存在,，使得HBase的運(yùn)行更加穩(wěn)定和高效,。
在配置環(huán)境中，Zookeeper集群中的HBase的目錄如圖2所示,。
HBase集群的相關(guān)信息存儲(chǔ)在Zookeeper集群中的hbase目錄（這個(gè)目錄是可以配置的）下,，其中master目錄存儲(chǔ)HMaster的位置等相關(guān)信息，rs目錄存儲(chǔ)所有的RegionServer的位置等相關(guān)信息,。
在HMaster啟動(dòng)時(shí),，會(huì)在Zookeeper集群中創(chuàng)建自己的ZNode臨時(shí)節(jié)點(diǎn)并獲得該節(jié)點(diǎn)的獨(dú)占鎖，該節(jié)點(diǎn)位于Zookeeper集群中的/hbase/master目錄下,。同時(shí)會(huì)在所有的其他目錄上創(chuàng)建監(jiān)聽,，這樣當(dāng)其他節(jié)點(diǎn)的狀態(tài)發(fā)生變化時(shí)，HMaster就可以立即感知從而進(jìn)行相應(yīng)的處理,。
在RegionServer啟動(dòng)時(shí),，會(huì)在Zookeeper集群中創(chuàng)建自己的ZNode臨時(shí)節(jié)點(diǎn)并獲得該節(jié)點(diǎn)的獨(dú)占鎖，這個(gè)節(jié)點(diǎn)位于Zookeeper集群中的/hbase/rs目錄下,。
RegionServer會(huì)通過Socket連接向Zookeeper集群發(fā)起Session會(huì)話,，會(huì)話建立后在Zookeeper集群中創(chuàng)建屬于自己的臨時(shí)節(jié)點(diǎn)ZNode。這個(gè)節(jié)點(diǎn)的狀態(tài)是由Zookeeper集群依據(jù)Session的狀態(tài)來維護(hù)的,。
RegionServer作為客戶端,，向Zookeeper集群的Server端發(fā)起Session會(huì)話請求。Session建立后,，會(huì)以唯一的SessionID作為標(biāo)示,。Client會(huì)定期向Server端發(fā)送Ping消息來表達(dá)該Session的存活狀態(tài)；而Server端收到Ping消息時(shí)會(huì)更新當(dāng)前Session的超時(shí)時(shí)間,。如此,，對于Client而言，只要Ping信息可達(dá)則表明該Session激活,；對于Server而言,，只要Session未超時(shí)則表明該Session激活。
在Server端,，Zookeeper會(huì)啟動(dòng)專門的SessionTrackerImpl線程來處理Session的相關(guān)狀態(tài)遷移問題,，該線程每隔tickTime（Zookeeper配置文件中指定，默認(rèn)為2 s）時(shí)間遍歷一次Session列表,，如果超時(shí)則立即關(guān)閉此Session,，同時(shí)刪除與該Session關(guān)聯(lián)的臨時(shí)節(jié)點(diǎn),，并將該事件通知給注冊了該節(jié)點(diǎn)事件的組件。在HBase集群中,，這就意味著如果RegionServer崩潰,，則Zookeeper需要在Session超時(shí)后才能通知Master，后者才能啟動(dòng)故障恢復(fù),。
而Session的超時(shí)時(shí)間是這樣確定的：HBase默認(rèn)的Timeout為180 s,，在創(chuàng)建Session時(shí)會(huì)將該參數(shù)傳遞給Server端。最終協(xié)商確定的Session的超時(shí)時(shí)間由Zookeeper的配置參數(shù)決定,，處于Zookeeper集群minSessionTimeout和maxSessionTimeout之間,。默認(rèn)的minSessionTimeout=2×tickTime（默認(rèn)2 s）=4 s，maxSessionTimeout=20×tickTime=40 s,。不管Client傳遞的Timeout多大,，最終協(xié)商確定的Session的Timeout時(shí)間都在4~40 s之間，實(shí)現(xiàn)代碼如下,。如果一切按照默認(rèn)配置,，則Session的Timeout為40 s。
int sessionTimeout=connReq.getTimeOut（）,；
int minSessionTimeout=getMinSessionTimeout（）,；
if（sessionTimeout<minSessionTimeout）{
sessionTimeout=minSessionTimeout；
}
int maxSessionTimeout=getMaxSessionTimeout（）,；
if（sessionTimeout>maxSessionTimeout）{
sessionTimeout=maxSessionTimeout；
}
cnxn.setSessionTimeout（sessionTimeout）,；
經(jīng)以上分析,，可以得出以下結(jié)論：Session存活意味著RegionServer存活；Session超時(shí)意味著RegionServer啟動(dòng)時(shí)創(chuàng)建的ZNode節(jié)點(diǎn)被刪除,，也就表明該RegionServer異常,。
3 HBase中RegionServer異常后的恢復(fù)機(jī)制分析
通過以上的分析可以看出，當(dāng)HBase集群中的一個(gè)RegionServer崩潰（如RegionServer進(jìn)程掛掉）后,，此時(shí)該RegionServer和Zookeeper集群的Server間的Socket連接會(huì)斷開,，但是二者之間的Session由于有超時(shí)時(shí)間的存在而不會(huì)立即被刪除，需要等到Session超時(shí)之后才會(huì)被Zookeeper集群刪除,，只有Session超時(shí)了Zookeeper集群才會(huì)刪除該RegionServer啟動(dòng)時(shí)創(chuàng)建的臨時(shí)節(jié)點(diǎn),。只有Zookeeper集群中代表此RegionServer的節(jié)點(diǎn)刪除后，HMaster才可以得知該RegionServer發(fā)生故障,，才能啟動(dòng)故障恢復(fù)流程,。HMaster恢復(fù)故障時(shí)，將故障RegionServer所管理的Region一個(gè)一個(gè)重新分配到集群中,。
由此可得出以下結(jié)論：Session Timeout的存在使得HMaster無法立即發(fā)現(xiàn)故障RegionServer,，從而延遲了故障的恢復(fù)時(shí)間,，間接增加了業(yè)務(wù)中斷的時(shí)間。同時(shí),，HMaster重新分配Region的處理過程效率太低,，尤其是Region數(shù)目很大時(shí)。
4 改進(jìn)的RegionServer異常后的恢復(fù)措施
針對以上場景,，本文進(jìn)行了如下改進(jìn)：
?。?）在RegionServer的啟動(dòng)腳本中加入特殊處理的代碼，在該RegionServer的進(jìn)程結(jié)束前自動(dòng)刪除其在Zookeeper集群中創(chuàng)建的ZNode節(jié)點(diǎn),，這樣HMaster就能立即感知到RegionServer的狀態(tài)異常事件,，盡早地啟動(dòng)異常恢復(fù),，代碼如下,。
cleanZNode（）
{
if[-f $HBASE_ZNODE_FILE]；then
#call ZK to delete the node
ZNODE=`cat $HBASE_ZNODE_FILE`
$bin/hbase zkcli delete $ZNODE>/dev/null 2>&1
rm $HBASE_ZNODE_FILE
fi
}
?。?）在HMaster的恢復(fù)過程中加入特殊處理的代碼,，通過批量處理，將故障RegionServer所管理的Region一次性地分配到集群中,，如同HBase集群啟動(dòng)時(shí)批量分配Region的過程,，提高Region分配的速度。所謂批量分配,，就是先獲取故障RegionServer所管理的Region數(shù)目rn和存活的RegionServer的數(shù)目rs,，按照平均負(fù)載的原則，在每個(gè)存活的RegionServer上分配rn/rs個(gè)Region,。這樣就可以將多個(gè)Region一次分配給一個(gè)RegionServer,；而原來的分配過程則是一次分配一個(gè)Region到一個(gè)RegionServer上，顯然改進(jìn)后的處理效率更高,，尤其是Region數(shù)目較多時(shí)尤為明顯,。
采用以上的處理方式后，HBase集群中當(dāng)一個(gè)或幾個(gè)RegionServer發(fā)生故障后,，業(yè)務(wù)的恢復(fù)速度提升了幾十倍,，從最初的故障恢復(fù)時(shí)間40 s左右到現(xiàn)在的幾秒，實(shí)測數(shù)據(jù)如表1所示,。
5 結(jié)論
本文在論述HBase集群與Zookeeper集群的交互機(jī)制以及RegionServer發(fā)生故障后的異常處理恢復(fù)機(jī)制的基礎(chǔ)上,，提出了提高恢復(fù)效率、降低業(yè)務(wù)中斷時(shí)間的改進(jìn)方案,。該方案對于RegionServer進(jìn)程的異常終止和崩潰有很好的處理效果,，但是對于RegionServer斷電等物理事件導(dǎo)致的異常則無效，這種情況只能依靠Session Timeout后的處理流程。批量恢復(fù)的處理對所有的恢復(fù)過程都是有效的,，雖然其提供的改進(jìn)空間較小,。總體說來,，本文提出的RegionServer崩潰后的改進(jìn)措施在通常情況下能夠較好地改進(jìn)現(xiàn)有HBase集群的性能,，縮短故障恢復(fù)時(shí)間，提高故障恢復(fù)效率,，從而能有效縮短業(yè)務(wù)中斷時(shí)間,。
參考文獻(xiàn)
[1] Apache. HBase-0.96.2 release notes[EB/OL]. [2013-07-21].http：//qnalist.com/q/hbase-user.
[2] Cloudera. HBase-0.94.2-cdh4.2.0 reference guidep[EB/OL].[2013-07-28].http：//newitfarmer.com/category/big_data/cloudera-big_data.
[3] 陸嘉恒. Hadoop實(shí)戰(zhàn)（第二版）[M]. 北京：機(jī)械工業(yè)出版社，2012.
[4] GEORGE L. HBase： the definitive guide[M]. Sebastopol： O′Reilly Media,， 2011.
[5] Apache. ZooKeeper-3.4.5 release notes[EB/OL]. [2012-11-19].http：//zookeeper.apache.org/doc/r.3.4.5.