開源組件Hbase之RIT故障修復(fù)

IT那活兒發(fā)布于2023-01-11 13:20 / 1033人閱讀

為方便大家對故障處理有一個(gè)更好的理解，本文前半章簡單扼要的介紹一下Hbase的相關(guān)信息，后半章是筆者工作中遇到的故障處理分享。

Hbase起源說明

HBase是一個(gè)開源的非關(guān)系型分布式數(shù)據(jù)庫，它參考了谷歌的BigTable建模，實(shí)現(xiàn)的編程語言為Java。它是Apache軟件基金會(huì)的Hadoop項(xiàng)目的一部分，運(yùn)行于HDFS文件系統(tǒng)之上，為Hadoop提供類似于BigTable規(guī)模的服務(wù)。因此，它可以容錯(cuò)地存儲(chǔ)海量稀疏的數(shù)據(jù)。

HBase是一個(gè)高可靠、高性能、面向列、可伸縮的分布式數(shù)據(jù)庫，是谷歌BigTable的開源實(shí)現(xiàn)，主要用來存儲(chǔ)非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。HBase的目標(biāo)是處理非常龐大的表，可以通過水平擴(kuò)展的方式，利用廉價(jià)計(jì)算機(jī)集群處理由超過10億行數(shù)據(jù)和數(shù)百萬列元素組成的數(shù)據(jù)表。

Hadoop生態(tài)為什么需要Hbase

Hadoop可以很好地解決大規(guī)模數(shù)據(jù)的離線批量處理問題，但是受限于HadoopMapReduce編程框架的高延遲數(shù)據(jù)處理機(jī)制，使得Hadoop無法滿足大規(guī)模數(shù)據(jù)實(shí)時(shí)處理應(yīng)用的需求。
HDFS面向批量訪問模式，不是隨機(jī)訪問模式。
傳統(tǒng)的通用關(guān)系型數(shù)據(jù)庫無法應(yīng)對在數(shù)據(jù)規(guī)模劇增時(shí)導(dǎo)致的系統(tǒng)擴(kuò)展性和性能問題（分庫分表也不能很好解決）。
傳統(tǒng)關(guān)系數(shù)據(jù)庫在數(shù)據(jù)結(jié)構(gòu)變化時(shí)一般需要停機(jī)維護(hù)；空列浪費(fèi)存儲(chǔ)空間。

HBase與傳統(tǒng)關(guān)系數(shù)據(jù)庫區(qū)別

1、數(shù)據(jù)類型：關(guān)系數(shù)據(jù)庫采用關(guān)系模型，具有豐富的數(shù)據(jù)類型和存儲(chǔ)方式，HBase則采用了更加簡單的數(shù)據(jù)模型，它把數(shù)據(jù)存儲(chǔ)為未經(jīng)解釋的字符串。
2、數(shù)據(jù)操作：關(guān)系數(shù)據(jù)庫中包含了豐富的操作，其中會(huì)涉及復(fù)雜的多表連接。HBase操作則不存在復(fù)雜的表與表之間的關(guān)系，只有簡單的插入、查詢、刪除、清空等，因?yàn)镠Base在設(shè)計(jì)上就避免了復(fù)雜的表和表之間的關(guān)系。
3、存儲(chǔ)模式：關(guān)系數(shù)據(jù)庫是基于行模式存儲(chǔ)的。HBase是基于列存儲(chǔ)的，每個(gè)列族都由幾個(gè)文件保存，不同列族的文件是分離的。
4、數(shù)據(jù)索引：關(guān)系數(shù)據(jù)庫通常可以針對不同列構(gòu)建復(fù)雜的多個(gè)索引，以提高數(shù)據(jù)訪問性能。HBase只有一個(gè)索引——行鍵，通過巧妙的設(shè)計(jì)，HBase中的所有訪問方法，或者通過行鍵訪問，或者通過行鍵掃描，從而使得整個(gè)系統(tǒng)不會(huì)慢下來。
5、數(shù)據(jù)維護(hù)：在關(guān)系數(shù)據(jù)庫中，更新操作會(huì)用最新的當(dāng)前值去替換記錄中原來的舊值，舊值被覆蓋后就不會(huì)存在。而在HBase中執(zhí)行更新操作時(shí)，并不會(huì)刪除數(shù)據(jù)舊的版本，而是生成一個(gè)新的版本，舊有的版本仍然保留。
6、可伸縮性：關(guān)系數(shù)據(jù)庫很難實(shí)現(xiàn)橫向擴(kuò)展，縱向擴(kuò)展的空間也比較有限。相反，HBase和BigTable這些分布式數(shù)據(jù)庫就是為了實(shí)現(xiàn)靈活的水平擴(kuò)展而開發(fā)的，能夠輕易地通過在集群中增加或者減少硬件數(shù)量來實(shí)現(xiàn)性能的伸縮。

Hbase架構(gòu)原理

HBase的實(shí)現(xiàn)包括三個(gè)主要的功能組件：

1、庫函數(shù)：鏈接到每個(gè)客戶端
2、一個(gè)Master主服務(wù)器
3、許多個(gè)Region服務(wù)器

主服務(wù)器Master負(fù)責(zé)管理和維護(hù)Hbase表的分區(qū)信息，維護(hù)Region服務(wù)器列表，分配Region，負(fù)載均衡。

Region服務(wù)器負(fù)責(zé)存儲(chǔ)和維護(hù)分配給自己的Region，處理來自客戶端的讀寫請求。

客戶端并不是直接從Master主服務(wù)器上讀取數(shù)據(jù)，而是在獲得Region的存儲(chǔ)位置信息后，直接從Region服務(wù)器上讀取數(shù)據(jù)。

客戶端并不依賴Master，而是通過Zookeeper來Region位置信息，大多數(shù)客戶端甚至從來不和Master通信，這種設(shè)計(jì)方式使得Master負(fù)載很小。

上面介紹了Hbase的相關(guān)信息，下面就筆者工作中遇到的一個(gè)關(guān)于region故障進(jìn)行分享。業(yè)務(wù)側(cè)報(bào)障大數(shù)據(jù)平臺(tái)，發(fā)現(xiàn)業(yè)務(wù)系統(tǒng)請求量明顯偏低，查看監(jiān)控發(fā)現(xiàn)Hbase的請求量很低，甚至為0，產(chǎn)生告警，下面開始診斷過程：

軟件版本：

Hbase

組件版本：

Hbase：1.2.1

問題定位

通過查看Hbase監(jiān)控頁面，發(fā)現(xiàn)18號節(jié)點(diǎn)不在服務(wù)中，遠(yuǎn)程連接比較卡頓，通過終端查看HRegionServer進(jìn)程在，查看系統(tǒng)日志：

重啟后，日志變?yōu)檎?/section>

綜上判斷可能是因?yàn)榫W(wǎng)絡(luò)通信原因?qū)е?8號節(jié)點(diǎn)異常。

Hbase日志：顯示18號，region已下線

Hbase監(jiān)控頁面：RIT問題

綜上，可判斷由于18號節(jié)點(diǎn)連接異常，導(dǎo)致當(dāng)前節(jié)點(diǎn)Hbase異常，另外Hbase出現(xiàn)RIT，會(huì)影響Hbase的寫入。

解決過程

嘗試重啟，但請求量仍然很低，后來將18號的Regionserver下線，效果不理想，最后決定做Hbase在線修復(fù)（18號已下線），Hbase狀態(tài)：

步驟：

1. hbase hbck 檢查輸出所以ERROR信息，每個(gè)ERROR都會(huì)說明錯(cuò)誤信息。
2. hbase hbck -fixTableOrphans 先修復(fù)tableinfo缺失問題，根據(jù)內(nèi)存cache或者h(yuǎn)dfs table 目錄結(jié)構(gòu)，重新生成tableinfo文件。
3. hbase hbck -fixHdfsOrphans 修復(fù)regioninfo缺失問題，根據(jù)region目錄下的hfile重新生成regioninfo文件。
4. hbase hbck -fixHdfsOverlaps 修復(fù)region重疊問題，merge重疊的region為一個(gè)region目錄，并從新生成一個(gè)regioninfo。
5. hbase hbck -fixHdfsHoles 修復(fù)region缺失，利用缺失的rowkey范圍邊界，生成新的region目錄以及regioninfo填補(bǔ)這個(gè)空洞。
6. hbase hbck -fixMeta 修復(fù)meta表信息，利用regioninfo信息，重新生成對應(yīng)meta row填寫到meta表中，并為其填寫默認(rèn)的分配regionserver。
7. hbase hbck -fixAssignments 把這些offline的region觸發(fā)上線，當(dāng)region開始重新open 上線的時(shí)候，會(huì)被重新分配到真實(shí)RegionServer上 , 并更新meta表上對應(yīng)的行信息。另外，當(dāng)執(zhí)行完所有修復(fù)步驟后仍然有：ERROR: Empty REGIONINFO_QUALIFIER found in hbase:meta。執(zhí)行：hbase hbck -fixEmptyMetaCells。