緣起

隨著hadoop系列的興起，基于HDFS的大規(guī)模KV存儲(chǔ)系統(tǒng)HBase也進(jìn)入“大規(guī)模使用階段”。網(wǎng)上的Hbase資料很多，學(xué)習(xí)成本正在下降。從公開的資料看，國(guó)外facebook、國(guó)內(nèi)taobao均宣稱在線上環(huán)境大規(guī)模使用hbase。一切都讓人很興奮。于是，在項(xiàng)目中引入Hbase做存儲(chǔ)，最終卻選擇放棄。

HBase設(shè)計(jì)：看上去很美

HBase是模仿google bigtable的開源產(chǎn)品，又是hadoop的衍生品，hadoop作為離線計(jì)算系統(tǒng)已經(jīng)得到業(yè)界的普遍認(rèn)可，并經(jīng)過N多公司大規(guī)模使用的驗(yàn)證，自然地認(rèn)為Hbase也將隨之獲得成功。

《HBase: The Definitive Guide》第8章講述hbase的架構(gòu)，從架構(gòu)上看，其架構(gòu)很***：

LSM - 解決磁盤隨機(jī)寫問題(順序?qū)懖攀峭醯?；

HFile - 解決數(shù)據(jù)索引問題(只有索引才能高效讀)；

WAL - 解決數(shù)據(jù)持久化(面對(duì)故障的持久化解決方案)；

zooKeeper - 解決核心數(shù)據(jù)的一致性和集群恢復(fù)；

Replication - 引入類似MySQL的數(shù)據(jù)復(fù)制方案，解決可用性；

此外還有：自動(dòng)分拆Split、自動(dòng)壓縮(compaction,LSM的伴生技術(shù))、自動(dòng)負(fù)載均衡、自動(dòng)region遷移。

看上去如此美好，完全無(wú)需人工干預(yù)，貌似只要將Hbase搭建好，一切問題Hbase都將應(yīng)對(duì)自如。面對(duì)如此***的系統(tǒng)，不動(dòng)心很難。

但是，如此***的系統(tǒng)或許也意味著背后的復(fù)雜性是不容忽略的。hbase的代碼量也不是一星半點(diǎn)的。假如系統(tǒng)工作不正常，誰(shuí)來解決？這是至關(guān)重要的。

性能與測(cè)試

Hbase系統(tǒng)自身提供了性能測(cè)試工具：./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation，該工具提供了隨機(jī)讀寫、多客戶端讀寫等性能測(cè)試功能。根據(jù)工具測(cè)試的結(jié)果看，hbase的性能不算差。

對(duì)于hbase這樣的系統(tǒng)長(zhǎng)期穩(wěn)定運(yùn)行比什么都重要。然而，這或許就不那么"***"。

測(cè)試版本：hbase 0.94.1、 hadoop 1.0.2、 jdk-6u32-linux-x64.bin、snappy-1.0.5.tar.gz

測(cè)試hbase搭建：14臺(tái)存儲(chǔ)機(jī)器+2臺(tái)master、DataNode和regionserver放在一起。

hbase env配置：

View Code   
 
ulimit -n 65536  
 
export HBASE_OPTS="$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode" 
 
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xmx20g -Xms20g -Xmn512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIn  
itiatingOccupancyFraction=60 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.lo  
g" 

hbase-size.xml關(guān)鍵配置(根據(jù)《HBase: The Definitive Guide》第11章優(yōu)化)：

View Code   
 
        <property> 
                <name>hbase.regionserver.handler.count</name> 
                <value>16</value> 
                <description>Count of RPC Listener instances spun up on RegionServers.  
                Same property is used by the Master for count of master handlers.  
                Default is 10.  
                </description> 
        </property> 
 
        <property> 
                <name>hbase.regionserver.global.memstore.upperLimit</name> 
                <value>0.35</value> 
                <description>Maximum size of all memstores in a region server before new  
                updates are blocked and flushes are forced. Defaults to 40% of heap  
                </description> 
        </property> 
        <property> 
                <name>hbase.regionserver.global.memstore.lowerLimit</name> 
                <value>0.3</value> 
                <description>When memstores are being forced to flush to make room in  
                memory, keep flushing until we hit this mark. Defaults to 35% of heap.  
                This value equal to hbase.regionserver.global.memstore.upperLimit causes  
                the minimum possible flushing to occur when updates are blocked due to  
                memstore limiting.  
                </description> 
        </property> 
 
        <property> 
                <name>hfile.block.cache.size</name> 
                <value>0.35</value> 
                <description> 
                Percentage of maximum heap (-Xmx setting) to allocate to block cache  
                used by HFile/StoreFile. Default of 0.25 means allocate 25%.  
                Set to 0 to disable but it's not recommended.  
                </description> 
        </property> 
 
        <property> 
                <name>zookeeper.session.timeout</name> 
                <value>600000</value> 
                <description>ZooKeeper session timeout.  
                HBase passes this to the zk quorum as suggested maximum time for a  
                session (This setting becomes zookeeper's 'maxSessionTimeout').  See  
                http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions  
                "The client sends a requested timeout, the server responds with the  
                timeout that it can give the client. " In milliseconds.  
                </description> 
        </property> 
 
<property> 
    <name>hbase.zookeeper.property.tickTime</name> 
    <value>60000</value> 
</property> 
 
<property> 
    <name>hbase.regionserver.restart.on.zk.expire</name> 
    <value>true</value> 
</property> 
 
  <property> 
    <name>hbase.hregion.majorcompaction</name> 
    <value>0</value> 
    <description>The time (in miliseconds) between 'major' compactions of all  
    HStoreFiles in a region.  Default: 1 day(86400000).  
    Set to 0 to disable automated major compactions.  
    </description> 
  </property> 
 
  <property> 
    <name>hbase.hregion.max.filesize</name> 
    <value>536870912000</value> 
    <description> 
    Maximum HStoreFile size. If any one of a column families' HStoreFiles has  
    grown to exceed this value, the hosting HRegion is split in two.  
    Default: 1G(1073741824).  Set 500G, disable file split!  
    </description> 
  </property> 

測(cè)試一：高并發(fā)讀(4w+/s) + 少量寫(允許分拆、負(fù)載均衡)

癥狀：1-2天后，hbase掛掉(系統(tǒng)性能極差，不到正常的10%)。其實(shí)并非全部掛掉，而是某些regionserver掛了，并在幾個(gè)小時(shí)內(nèi)引發(fā)其他regionserver掛掉。系統(tǒng)無(wú)法恢復(fù)：?jiǎn)为?dú)啟regionserver無(wú)法恢復(fù)正常。重啟后正常。

測(cè)試二：高并發(fā)讀(4w+/s)

癥狀：1-2天后，hbase掛掉(系統(tǒng)性能極差，不到正常的10%)。后發(fā)現(xiàn)是由于zookeeper.session.timeout設(shè)置不正確導(dǎo)致(參見regionserver部分：http://hbase.apache.org/book.html#trouble)。重啟后正常。

測(cè)試三：高并發(fā)讀(4w+/s)

癥狀：1-2天后，hbase掛掉(系統(tǒng)性能極差，不到正常的10%)。從log未看出問題，但regionserver宕機(jī)，且datanode也宕機(jī)。重啟后正常。

測(cè)試四：高并發(fā)讀(4w+/s)+禁止分拆、禁止majorcompaction、禁止負(fù)載均衡(balance_switch命令)

癥狀：1-2天后，hbase掛掉(系統(tǒng)性能極差，不到正常的10%)。從log未看出問題，但regionserver宕機(jī)，且datanode也宕機(jī)。重啟后正常。

測(cè)試期間，還發(fā)現(xiàn)過：無(wú)法獲取".MATE."表的內(nèi)容(想知道regionserver的分布情況)、hbase無(wú)法正確停止、hbase無(wú)法正確啟動(dòng)(日志恢復(fù)失敗，文件錯(cuò)誤，最終手動(dòng)刪除日志重啟)。

其他缺陷

HBase使用JAVA開發(fā)，看上去很美的GC使用中代價(jià)可不小。Hbase為了保證數(shù)據(jù)強(qiáng)一致性，每個(gè)key只能由一個(gè)regionserver提供服務(wù)。在下列情況下，Hbase服務(wù)質(zhì)量都將受損：

1) GC CMS -- CMS回收內(nèi)存極其耗時(shí)，當(dāng)hbase運(yùn)行1-2天后，CMS可能耗時(shí)10分鐘，這期間該regionserver無(wú)法服務(wù)。CMS經(jīng)常被觸發(fā)，這意味著hbase的服務(wù)經(jīng)常會(huì)因?yàn)镚C操作而部分暫停！

2) regionserver宕機(jī) - 為了強(qiáng)一致性，每個(gè)key只由一個(gè)regionserver提供服務(wù)，故當(dāng)regionserver宕機(jī)后，相應(yīng)的region即無(wú)法服務(wù)！

3) major compaction、split不可控 - 大量磁盤操作將極大影響服務(wù)。(levelDB也需要major compaction，只是使用更加可控的方式做壓縮，比如一次只有一個(gè)壓縮任務(wù)。是否影響服務(wù)，待測(cè)試)

4) 數(shù)據(jù)恢復(fù) - 數(shù)據(jù)恢復(fù)期間設(shè)置WAL log的相關(guān)操作，在數(shù)據(jù)恢復(fù)期間regionserver無(wú)法服務(wù)！

結(jié)論

或許通過研究hbase的源碼可讓hbase穩(wěn)定運(yùn)行，但從上述測(cè)試結(jié)果看：1）hbase還無(wú)法穩(wěn)定長(zhǎng)期運(yùn)行；2）hbase系統(tǒng)很脆弱，故障恢復(fù)能力差。基于此，判斷hbase還無(wú)法滿足大規(guī)模線上系統(tǒng)的運(yùn)維標(biāo)準(zhǔn)，只能放棄。考慮到hbase重啟基本可恢復(fù)正常，故hbase還是可作為離線存儲(chǔ)系統(tǒng)使用。

替代方案

面對(duì)大規(guī)模數(shù)據(jù)，基于磁盤的存儲(chǔ)系統(tǒng)是必不可少的。google雖然公開了bigtable的設(shè)計(jì)，但未開源，但google開源了levelDB KV存儲(chǔ)系統(tǒng)庫(kù)(http://code.google.com/p/leveldb/)。levelDB采用C++實(shí)現(xiàn)，1.7版本的代碼量大概2W，實(shí)現(xiàn)了LSM(自動(dòng)壓縮)、LevelFile(基本同HFile)，WAL，提供了簡(jiǎn)單的Put、Get、Delete、Write(批量寫、事務(wù)功能)等接口。levelDB庫(kù)實(shí)現(xiàn)了單機(jī)單庫(kù)的磁盤存儲(chǔ)方案，開發(fā)者可根據(jù)自己需要開發(fā)定制的存儲(chǔ)系統(tǒng)(比如：數(shù)據(jù)Replication、自動(dòng)調(diào)度、自動(dòng)恢復(fù)、負(fù)載均衡等)。

原文鏈接：http://www.cnblogs.com/zhenjing/archive/2012/11/13/hbase_is_OK.html