1 hbase.hregion.max.filesize應(yīng)該設(shè)置多少合適

默認(rèn)值：256M

說(shuō)明：Maximum HStoreFile size. If any one of a column families' HStoreFiles has grown to exceed this value, the hosting HRegion is split in two.

HStoreFile的***值。如果任何一個(gè)Column Family（或者說(shuō)HStore）的HStoreFiles的大小超過(guò)這個(gè)值，那么，其所屬的HRegion就會(huì)Split成兩個(gè)。

調(diào)優(yōu)：

hbase中hfile的默認(rèn)***值(hbase.hregion.max.filesize)是256MB，而google的bigtable論文中對(duì)tablet的***值也推薦為100-200MB，這個(gè)大小有什么秘密呢？

　　眾所周知hbase中數(shù)據(jù)一開(kāi)始會(huì)寫(xiě)入memstore，當(dāng)memstore滿(mǎn)64MB以后，會(huì)flush到disk上而成為storefile。當(dāng)storefile數(shù)量超過(guò)3時(shí)，會(huì)啟動(dòng)compaction過(guò)程將它們合并為一個(gè)storefile。這個(gè)過(guò)程中會(huì)刪除一些timestamp過(guò)期的數(shù)據(jù)，比如update的數(shù)據(jù)。而當(dāng)合并后的storefile大小大于hfile默認(rèn)***值時(shí)，會(huì)觸發(fā)split動(dòng)作，將它切分成兩個(gè)region。

　　lz進(jìn)行了持續(xù)insert壓力測(cè)試，并設(shè)置了不同的hbase.hregion.max.filesize，根據(jù)結(jié)果得到如下結(jié)論：值越小，平均吞吐量越大，但吞吐量越不穩(wěn)定；值越大，平均吞吐量越小，吞吐量不穩(wěn)定的時(shí)間相對(duì)更小。

　　為什么會(huì)這樣呢？推論如下：

    a 當(dāng)hbase.hregion.max.filesize比較小時(shí)，觸發(fā)split的機(jī)率更大，而split的時(shí)候會(huì)將region offline，因此在split結(jié)束的時(shí)間前，訪(fǎng)問(wèn)該region的請(qǐng)求將被block住，客戶(hù)端自我block的時(shí)間默認(rèn)為1s。當(dāng)大量的region同時(shí)發(fā)生split時(shí)，系統(tǒng)的整體訪(fǎng)問(wèn)服務(wù)將大受影響。因此容易出現(xiàn)吞吐量及響應(yīng)時(shí)間的不穩(wěn)定現(xiàn)象

    b 當(dāng)hbase.hregion.max.filesize比較大時(shí)，單個(gè)region中觸發(fā)split的機(jī)率較小，大量region同時(shí)觸發(fā)split的機(jī)率也較小，因此吞吐量較之小hfile尺寸更加穩(wěn)定些。但是由于長(zhǎng)期得不到split，因此同一個(gè)region內(nèi)發(fā)生多次compaction的機(jī)會(huì)增加了。compaction的原理是將原有數(shù)據(jù)讀一遍并重寫(xiě)一遍到hdfs上，然后再刪除原有數(shù)據(jù)。無(wú)疑這種行為會(huì)降低以io為瓶頸的系統(tǒng)的速度，因此平均吞吐量會(huì)受到一些影響而下降。

    綜合以上兩種情況，hbase.hregion.max.filesize不宜過(guò)大或過(guò)小，256MB或許是一個(gè)更理想的經(jīng)驗(yàn)參數(shù)。對(duì)于離線(xiàn)型的應(yīng)用，調(diào)整為128MB會(huì)更加合適一些，而在線(xiàn)應(yīng)用除非對(duì)split機(jī)制進(jìn)行改造，否則不應(yīng)該低于256MB

2 autoflush=false的影響

　　無(wú)論是官方還是很多blog都提倡為了提高h(yuǎn)base的寫(xiě)入速度而在應(yīng)用代碼中設(shè)置autoflush=false，然后lz認(rèn)為在在線(xiàn)應(yīng)用中應(yīng)該謹(jǐn)慎進(jìn)行該設(shè)置。原因如下：

　　a autoflush=false的原理是當(dāng)客戶(hù)端提交delete或put請(qǐng)求時(shí)，將該請(qǐng)求在客戶(hù)端緩存，直到數(shù)據(jù)超過(guò)2M(hbase.client.write.buffer決定)或用戶(hù)執(zhí)行了hbase.flushcommits()時(shí)才向regionserver提交請(qǐng)求。因此即使htable.put()執(zhí)行返回成功，也并非說(shuō)明請(qǐng)求真的成功了。假如還沒(méi)有達(dá)到該緩存而client崩潰，該部分?jǐn)?shù)據(jù)將由于未發(fā)送到regionserver而丟失。這對(duì)于零容忍的在線(xiàn)服務(wù)是不可接受的。

　　b autoflush=true雖然會(huì)讓寫(xiě)入速度下降2-3倍，但是對(duì)于很多在線(xiàn)應(yīng)用來(lái)說(shuō)這都是必須打開(kāi)的，也正是hbase為什么讓它默認(rèn)值為true的原因。當(dāng)該值為true時(shí)，每次請(qǐng)求都會(huì)發(fā)往regionserver,而regionserver接收到請(qǐng)求后***件事就是寫(xiě)hlog，因此對(duì)io的要求是非常高的，為了提高h(yuǎn)base的寫(xiě)入速度，應(yīng)該盡可能高地提高io吞吐量，比如增加磁盤(pán)、使用raid卡、減少replication因子數(shù)等

3 從性能的角度談table中family和qualifier的設(shè)置

　　對(duì)于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)中的一張table，在業(yè)務(wù)轉(zhuǎn)換到hbase上建模時(shí)，從性能的角度應(yīng)該如何設(shè)置family和qualifier呢？

　　最極端的，①每一列都設(shè)置成一個(gè)family，②一個(gè)表僅有一個(gè)family，所有列都是其中的一個(gè)qualifier，那么有什么區(qū)別呢？

　　從讀的方面考慮：

　　family越多，那么獲取每一個(gè)cell數(shù)據(jù)的優(yōu)勢(shì)越明顯，因?yàn)閕o和網(wǎng)絡(luò)都減少了。

　　如果只有一個(gè)family，那么每一次讀都會(huì)讀取當(dāng)前rowkey的所有數(shù)據(jù)，網(wǎng)絡(luò)和io上會(huì)有一些損失。

　　當(dāng)然如果要獲取的是固定的幾列數(shù)據(jù)，那么把這幾列寫(xiě)到一個(gè)family中比分別設(shè)置family要更好，因?yàn)橹恍枰淮握?qǐng)求就能拿回所有數(shù)據(jù)。

　　從寫(xiě)的角度考慮：

　　首先，內(nèi)存方面來(lái)說(shuō)，對(duì)于一個(gè)Region，會(huì)為每一個(gè)表的每一個(gè)Family分配一個(gè)Store，而每一個(gè)Store，都會(huì)分配一個(gè)MemStore，所以更多的family會(huì)消耗更多的內(nèi)存。

　　其次，從flush和compaction方面說(shuō)，目前版本的hbase，在flush和compaction都是以region為單位的，也就是說(shuō)當(dāng)一個(gè)family達(dá)到flush條件時(shí)，該region的所有family所屬的memstore都會(huì)flush一次，即使memstore中只有很少的數(shù)據(jù)也會(huì)觸發(fā)flush而生成小文件。這樣就增加了compaction發(fā)生的機(jī)率，而compaction也是以region為單位的，這樣就很容易發(fā)生compaction風(fēng)暴從而降低系統(tǒng)的整體吞吐量。

　　第三，從split方面考慮，由于hfile是以family為單位的，因此對(duì)于多個(gè)family來(lái)說(shuō)，數(shù)據(jù)被分散到了更多的hfile中，減小了split發(fā)生的機(jī)率。這是把雙刃劍。更少的split會(huì)導(dǎo)致該region的體積比較大，由于balance是以region的數(shù)目而不是大小為單位來(lái)進(jìn)行的，因此可能會(huì)導(dǎo)致balance失效。而從好的方面來(lái)說(shuō)，更少的split會(huì)讓系統(tǒng)提供更加穩(wěn)定的在線(xiàn)服務(wù)。而壞處我們可以通過(guò)在請(qǐng)求的低谷時(shí)間進(jìn)行人工的split和balance來(lái)避免掉。

     因此對(duì)于寫(xiě)比較多的系統(tǒng)，如果是離線(xiàn)應(yīng)該，我們盡量只用一個(gè)family好了，但如果是在線(xiàn)應(yīng)用，那還是應(yīng)該根據(jù)應(yīng)用的情況合理地分配family。

4 hbase.regionserver.handler.count

 RegionServer端開(kāi)啟的RPC監(jiān)聽(tīng)器實(shí)例個(gè)數(shù)，也即RegionServer能夠處理的IO請(qǐng)求線(xiàn)程數(shù)。默認(rèn)是10.

 此參數(shù)與內(nèi)存息息相關(guān)。該值設(shè)置的時(shí)候，以監(jiān)控內(nèi)存為主要參考。

 對(duì)于 單次請(qǐng)求內(nèi)存消耗較高的Big PUT場(chǎng)景（大容量單次PUT或設(shè)置了較大cache的scan，均屬于Big PUT）或ReigonServer的內(nèi)存比較緊張的場(chǎng)景，可以設(shè)置的相對(duì)較小。

 對(duì)于 單次請(qǐng)求內(nèi)存消耗低，TPS（TransactionPerSecond，每秒事務(wù)處理量）要求非常高的場(chǎng)景，可以設(shè)置的相對(duì)大些。

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

【編輯推薦】