某大數(shù)據(jù)項(xiàng)目批處理集群hbase出現(xiàn)查詢超時(shí)，應(yīng)客戶和應(yīng)用側(cè)要求，重啟了hbase服務(wù)。重啟hbase后，在加載region的時(shí)候速度較慢，導(dǎo)致日志中心業(yè)務(wù)無法正常寫入、數(shù)據(jù)匯聚業(yè)務(wù)無法正常讀取。

由于應(yīng)用側(cè)反饋無法正常查詢hbase表，因此和客戶及應(yīng)用側(cè)協(xié)商確認(rèn)后，針對(duì)hbase修改hbase.hstore.compaction.max=30參數(shù)，然后重啟hbase集群。

重啟后發(fā)現(xiàn)hbase加載region很慢，登入hbase集群后從后臺(tái)查看hbase表發(fā)現(xiàn)很多表region未上線，后臺(tái)查詢hbase表失敗。

查看hmaster ui界面發(fā)現(xiàn)很多region處于regions in transition狀態(tài)。且重啟前region數(shù)正常有7.5w左右，而目前加載的只有2w7左右。

排查hmaster日志，發(fā)現(xiàn)hbase正在做major compact和balance，且compact持續(xù)了很久，日志中顯示region注冊(cè)時(shí)，從hdfs上獲取block失敗，導(dǎo)致大量的skip信息。

恢復(fù)配置，重新重啟hbase集群，發(fā)現(xiàn)重啟仍然很慢。

全部停止hbase集群，只啟動(dòng)hbase master節(jié)點(diǎn)上的的hmaster服務(wù)，然后重啟regionserver，發(fā)現(xiàn)重啟仍然很慢，查看日志，發(fā)現(xiàn)master初始化超時(shí)失敗：

hbase.master.namespace.init.timeout=36000000

hbase.master.initializationmonitor.timeout=48000000

參數(shù)調(diào)整完畢后，重新啟動(dòng)整個(gè)hbase（只啟動(dòng)226節(jié)點(diǎn)的hmaster），等待region加載上線。

后臺(tái)測(cè)試hbase，新建表和讀寫都正常，日志中心業(yè)務(wù)恢復(fù)正常，但針對(duì)部分歷史大數(shù)據(jù)量的表讀寫仍然失敗。

查看region，仍有處于RIT狀態(tài)的：

針對(duì)部分上線困難的region使用assign regionname命令手動(dòng)上線：

經(jīng)過處理后，region全部加載完成，沒有發(fā)現(xiàn)處于RIT狀態(tài)的region，hbase及其業(yè)務(wù)全部恢復(fù)正常。

1. hbase重啟時(shí)，由于hfile文件較多，導(dǎo)致調(diào)整hbase.hstore.compaction參數(shù)后，產(chǎn)生大量的compaction.

2. hbase重啟時(shí)，hbase在做region rebalance和split，進(jìn)一步加劇了集群的負(fù)擔(dān)，最終導(dǎo)致重啟緩慢。

1. hbase集群region數(shù)較多，平均每個(gè)regionserver節(jié)點(diǎn)已經(jīng)超過350個(gè)region。

2. hbase balance策略需要調(diào)整，rebalance一段時(shí)間后，又會(huì)分部不均。

1. 制定hbase定期巡檢計(jì)劃，完善現(xiàn)有監(jiān)控指標(biāo)，實(shí)時(shí)掌握hbase集群健康情況。

2. 隨著hbase接入應(yīng)用和數(shù)據(jù)的增加，定期和應(yīng)用廠商反饋各方對(duì)hbase的使用情況，并要求應(yīng)用定期對(duì)過期表進(jìn)行清理。

3. 常用hbase表建議應(yīng)用使用天表。

4. 改進(jìn)hbase rebalance策略，確保regionserver上region均衡分部。

結(jié)合此次故障暴露出的問題，我們總結(jié)了Hbase模型設(shè)計(jì)方面的一些規(guī)范和建議：

• HBase在新建一個(gè)表時(shí)如果不指定預(yù)分配Region，則默認(rèn)為該表只分配一個(gè)Region。在數(shù)據(jù)加載時(shí)，所有數(shù)據(jù)都會(huì)加載到該Region，導(dǎo)致單節(jié)點(diǎn)負(fù)載過高，加載性能降低，從而影響入庫(kù)性能。因此需要在建表時(shí)預(yù)先為該表在所有節(jié)點(diǎn)上分配多個(gè)Region，從而將所有節(jié)點(diǎn)高效利用起來。

• 預(yù)建Region的個(gè)數(shù)需要根據(jù)話單文件大小和節(jié)點(diǎn)個(gè)數(shù)來確定。由于每個(gè)Region大小超過一定數(shù)值后，HBase會(huì)自動(dòng)進(jìn)行Region分裂，導(dǎo)致Region不均勻，使得各臺(tái)節(jié)點(diǎn)的壓力不均，影響HBase的性能，因此預(yù)建Region的基本原則是盡量避免Region的自動(dòng)分裂。

• 根據(jù)最佳實(shí)踐經(jīng)驗(yàn)，每個(gè)RegionServer上的Region個(gè)數(shù)為100左右的情況下HBase性能最好。因此每張表預(yù)建的Region數(shù)目應(yīng)當(dāng)小于等于100*RegionServer個(gè)數(shù)/表的個(gè)數(shù)。同時(shí)每個(gè)Region的文件大小(hbase.hregion.max.filesize)推薦配置為10GB，并在每天晚上空閑時(shí)對(duì)表做major_compact處理，以提高HBase的查詢性能。

• 訪問模式是HBase設(shè)計(jì)的主要部分，弄清應(yīng)用將如何訪問數(shù)據(jù)，識(shí)別被訪問的數(shù)據(jù)類型。大多數(shù)應(yīng)用可以分成讀操作密集或?qū)懖僮髅芗瘍煞N，以及讀寫均密集型，需要針對(duì)不同的訪問模型來設(shè)計(jì)不同的rowkey。

• 使用salted或promoted字段行鍵可以在寫的分布和順序讀取得較好的平衡，如果你只做隨機(jī)讀，使用隨機(jī)key是最合理的?？梢员苊鈘egion的熱點(diǎn)問題。

END

更多精彩干貨分享

點(diǎn)擊下方名片關(guān)注

IT那活兒