1. region情況

需要檢查

1. region的數量（總數和每臺regionserver上的region數）

2. region的大小

如果發現異常可以透過手動merge region和手動分配region來調整

從CDH前臺和master前臺以及regionServer的前臺都可以看到region數量，如master前臺：

在region server前臺可以看到storeFile大小：

2. 快取命中率

快取命中率對hbase的讀有很大的影響，可以觀察這個指標來調整blockcache的大小。

從regionserver web頁面可以看到block cache的情況：

注意：

HBase上Regionserver的記憶體分為兩個部分，一部分作為Memstore，主要用來寫；另外一部分作為BlockCache，主要用於讀。

寫請求會先寫入Memstore，Regionserver會給每個region提供列族數提供一定數量的Memstore，當Memstore滿64MB以後，會啟動 flush重新整理到磁碟。當Memstore的總大小超過限制時（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），會強行啟動flush程式，從最大的Memstore開始flush直到低於限制。
讀請求先到Memstore中查資料，查不到就到BlockCache中查，再查不到就會到磁碟上讀，並把讀的結果放入BlockCache。由於BlockCache採用的是LRU策略，因此BlockCache達到上限(heapsize * hfile.block.cache.size * 0.85)後，會啟動淘汰機制，淘汰掉最老的一批資料。

一個Regionserver上有一個BlockCache和N個Memstore，它們的大小之和不能大於等於heapsize * 0.8，否則HBase不能正常啟動。

預設配置下，BlockCache為0.2，而Memstore為0.4。在注重讀響應時間的應用場景下，可以將 BlockCache設定大些，Memstore設定小些，以加大快取的命中率。

HBase RegionServer包含三個級別的Block優先順序佇列：

Single：如果一個Block第一次被訪問，則放在這一優先順序佇列中；
Multi：如果一個Block被多次訪問，則從Single佇列移到Multi佇列中；
InMemory：如果一個Block是inMemory的，則放到這個佇列中。

以上將Cache分級思想的好處在於：

首先，透過inMemory型別Cache，可以有選擇地將in-memory的column families放到RegionServer記憶體中，例如Meta後設資料資訊；
透過區分Single和Multi型別Cache，可以防止由於Scan操作帶來的Cache頻繁顛簸，將最少使用的Block加入到淘汰演算法中。

預設配置下，對於整個BlockCache的記憶體，又按照以下百分比分配給Single、Multi、InMemory使用：0.25、0.50和0.25。

注意，其中InMemory佇列用於儲存HBase Meta表後設資料資訊，因此如果將資料量很大的使用者表設定為InMemory的話，可能會導致Meta表快取失效，進而對整個叢集的效能產生影響。

3. 讀寫請求數

透過讀寫請求數可以大概看出每臺regionServer的壓力，如果壓力分佈不均勻，應該檢查regionServer上的region以及其它指標

4. 壓縮佇列

壓縮佇列存放的是正在壓縮的storefile，compact操作對hbase的讀寫影響較大

透過cdh的hbase圖表庫可以看到叢集總的壓縮佇列大小：

可以透過CDH的hbase主頁查詢compact日誌：

點選“壓縮”進入：

Hbase運維手冊

5. 重新整理佇列

單個region的memstore寫滿(128M)或regionServer上所有region的memstore大小總合達到門限時會進行flush操作,flush操作會產生新的storeFile

同樣可以透過CDH的hbase前臺檢視flush日誌：

6. rpc呼叫佇列

沒有及時處理的rpc操作會放入rpc操作佇列，從rpc佇列可以看出伺服器處理請求的情況

7. 檔案塊儲存在本地的百分比

datanode和regionserver一般都部署在同一臺機器上，所以region server管理的region會優先儲存在本地，以節省網路開銷。如果block locality較低有可能是剛做過balance或剛重啟，經過compact之後region的資料都會寫到當前機器的datanode，block locality也會慢慢達到接近100：

Hbase運維手冊

8. 記憶體使用情況

記憶體使用情況,主要可以看used Heap和memstore的大小，如果usedHeadp一直超過80-85%以上是比較危險的

memstore很小或很大也不正常

從region Server的前臺可以看到：

9. 檢查資料一致性以及修復方法

資料一致性是指：

1. 每個region都被正確的分配到一臺regionserver上，並且region的位置資訊及狀態都是正確的。

2. 每個table都是完整的，每一個可能的rowkey 都可以對應到唯一的一個region

hbase hbck

注：有時叢集正在啟動或region正在做split操作，會造成資料不一致

hbase hbck -details

加上–details會列出更詳細的檢查資訊，包括所以正在進行的split任務

hbase hbck Table1 Table2

如果只想檢查指定的表，可以在命令後面加上表名，這樣可以節省操作時間

CDH

透過CDH提供的檢查報告也可以看到hbck的結果，日常只需要看CDH hbck的報告即可：

選擇“最近的Hbck結果”：

Hbase運維手冊

1) 區域性的修復

如果出現資料不一致，修復時要最大限度的降低可能出現的風險，使用以下命令對region進行修復風險較低：

hbase hbck -fixAssignments

修復region沒有分配(unassigned)，錯誤分配（incorrectly assigned）以及多次分配（multiply assigned）的問題

hbase hbck -fixMeta

刪除META表裡有記錄但HDFS裡沒有資料記錄的region

            新增HDFS裡有資料但是META表裡沒有記錄的region到META表

hbase hbck -repairHoles

            等價於：hbase hbck -fixAssignments -fixMeta -fixHdfsHoles

-

fixHdfsHoles的作用：

如果rowkey出現空洞，即相鄰的兩個region的rowkey不連續，則使用這個引數會在HDFS裡面建立一個新的region。建立新的region之後要使用-fixMeta和-fixAssignments引數來使用掛載這個region，所以一般和前兩個引數一起使用

2） Region重疊修復

進行以下操作非常危險，因為這些操作會修改檔案系統，需要謹慎操作！

進行以下操作前先使用hbck –details檢視詳細問題，如果需要進行修復先停掉應用，如果執行以下命令時同時有資料操作可能會造成不可期的異常。

hbase hbck -fixHdfsOrphans

將檔案系統中的沒有metadata檔案(.regioninfo)的region目錄加入到hbase中，即建立.regioninfo目錄並將region分配到regionser

hbase hbck -fixHdfsOverlaps

透過兩種方式可以將rowkey有重疊的region合併：

1. merge:將重疊的region合併成一個大的region

2. sideline:將region重疊的部分去掉，並將重疊的資料先寫入到臨時檔案，然後再匯入進來。

如果重疊的資料很大，直接合併成一個大的region會產生大量的split和compact操作，可以透過以下引數控制region過大：

-maxMerge 合併重疊region的最大數量

-sidelineBigOverlaps 假如有大於maxMerge個數的 region重疊, 則採用sideline方式處理與其它region的重疊.

-maxOverlapsToSideline 如果用sideline方式處理重疊region,最多sideline n個region .

hbase hbck -repair

 以下命令的縮寫：

hba          hbase hbck -fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile –sidelineBigOverlaps

           可以指定表名：

hba hbase hbck -repair Table1 Table2

hbase hbck -fixMetaOnly –fixAssignments

如果只有META表的region不一致，則可以使用這個命令修復

hbase hbck –fixVersionFile

Hbase的資料檔案啟動時需要一個version file，如果這個檔案丟失，可以用這個命令來新建一個，但是要保證hbck的版本和Hbase叢集的版本是一樣的

hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

如果ROOT表和META表都出問題了Hbase無法啟動，可以用這個命令來建立新的ROOT和META表。

這個命令的前提是Hbase已經關閉，執行時它會從hbase的home目錄載入hbase的相關資訊（.regioninfo），如果表的資訊是完整的就會建立新的root和meta目錄及資料

hbase hbck –fixSplitParents

當region做split操作的時候，父region會被自動清除掉。但是有時候子region在父region被清除之前又做了split。造成有些延遲離線的父region存在於META表和HDFS中，但是沒有部署，HBASE又不能清除他們。這種情況下可以使用此命令重置這些在META表中的region為線上狀態並且沒有split。然後就可以使用之前的修復命令把這個region修復

10. 手動merge region

進行操作前先將balancer關閉，操作完成後再開啟balancer

經過一段時間的執行之後有可能會產生一些很小的region，需要定期檢查這些region並將它們和相鄰的region合併以減少系統的總region數，減少管理開銷

合併方法：

1. 找到需要合併的region的encoded name

2. 進入hbase shell

3. 執行merge_region ‘region1’,’region2’

手動分配region

如果發現臺regionServer資源佔用特別高，可以檢查這臺regionserver上的region是否存在過多比較大的region,透過hbase shell將部分比較大的region分配給其他不是很忙的regions server：

move 'encodeRegionName', 'ServerName'
# encodeRegionName指的regioName後面的編碼，ServerName指的是master-status的Region Servers列表

例：

move '24d9eef6ba5616b1a60180503e62bae7','DN1,60020,1429840460046'

手動major_compact

進行操作前先將balancer關閉，操作完成後再開啟balancer

選擇一個系統比較空閒的時間手工major_compact，如果hbase更新不是太頻繁，可以一個星期對所有表做一次 major_compact，這個可以在做完一次major_compact後，觀看所有的storefile數量，如果storefile數量增加到 major_compact後的storefile的近二倍時，可以對所有表做一次major_compact，時間比較長，操作儘量避免高鋒期

注：fms現在生產上開啟了自動major_compact，不需要做手動major compact

balance_switch

balance_switch true 開啟balancer

balance_switch flase 關閉balancer

配置master是否執行平衡各個regionserver的region數量，當我們需要維護或者重啟一個regionserver時，會關閉balancer，這樣就使得region在regionserver上的分佈不均，這個時候需要手工的開啟balance。

regionserver重啟

graceful_stop.sh --restart --reload --debug nodename

進行操作前先將balancer關閉，操作完成後再開啟balancer

這個操作是平滑的重啟regionserver程式，對服務不會有影響，他會先將需要重啟的regionserver上面的所有 region遷移到其它的伺服器，然後重啟，最後又會將之前的region遷移回來，但我們修改一個配置時，可以用這種方式重啟每一臺機子，對於hbase regionserver重啟，不要直接kill程式，這樣會造成在zookeeper.session.timeout這個時間長的中斷，也不要透過 bin/hbase-daemon.sh stop regionserver去重啟，如果運氣不太好，-ROOT-或者.META.表在上面的話，所有的請求會全部失敗

regionserver關閉下線

bin/graceful_stop.sh nodename

進行操作前先將balancer關閉，操作完成後再開啟balancer

和上面一樣，系統會在關閉之前遷移所有region，然後stop程式。

flush表

所有memstore重新整理到hdfs，通常如果發現regionserver的記憶體使用過大，造成該機的 regionserver很多執行緒block，可以執行一下flush操作，這個操作會造成hbase的storefile數量劇增，應儘量避免這個操作，還有一種情況，在hbase進行遷移的時候，如果選擇複製檔案方式，可以先停寫入，然後flush所有表，複製檔案

強制split

Hbase 允許客戶端強制執行split,在hbase shell中執行以下命令：

 split 'forced_table', 'b' //其中forced_table 為要split的table , ‘b’ 為split 點

region splits 執行過程：

region server處理寫請求的時候，會先寫入memstore，當memstore 達到一定大小的時候，會寫入磁碟成為一個store file。這個過程叫做 memstore flush。當store files 堆積到一定大小的時候，region server 會執行‘compact’操作，把他們合成一個大的檔案。當每次執行完flush 或者compact操作，都會判斷是否需要split。當發生split的時候，會生成兩個region A 和 region B但是parent region資料file並不會發生複製等操作，而是region A 和region B 會有這些file的引用。這些引用檔案會在下次發生compact操作的時候清理掉，並且當region中有引用檔案的時候是不會再進行split操作的。

這個地方需要注意一下:
(大量的寫入會刷大量的HFile，一個region就會對這大量的hfile進行compact操作。如果這時候觸發了split操作，這個region會成為父region，而兩個子region會保留父region的引用檔案。而在這其間，子region會繼續寫入資料。那麼又可能觸發子region的compact，這裡的關鍵點來了——子region如果做compact的檔案都是新寫入的檔案，而遲遲不去compact父region 引用的檔案，會導致一個問題——就是這個子region無法被split掉了（因為含有父region引用的region是不能被split的）。那麼子region越來越大，由於寫入檔案數量急劇增長，父region的ref檔案總也得不到機會compact，就形成了大region的惡性迴圈情況——由於region太大，compact無法完成，但是由於compact無法完成導致region無法split，無法分攤compact的壓力給其他regionserver。)

雖然split region操作是region server單獨確定的，但是split過程必須和很多其他部件合作。region server 在split開始前和結束前通知master,並且需要更新.META.表，這樣，客戶端就能知道有新的region。在hdfs中重新排列目錄結構和資料檔案。split是一個複雜的操作。在split region的時候會記錄當前執行的狀態，當出錯的時候，會根據狀態進行回滾。下圖表示split中，執行的過程。（紅色線表示region server 或者master的操作，綠色線表示client的操作。）

1.region server 決定split region，第一步，region server在zookeeper中建立在

/hbase/region-in-transition/region-name 目錄下，建立一個znode，狀態為SPLITTING.

2.因為master有對 region-in-transition 的znode做監聽，所以，mater的得知parent region需要split

3.region server 在hdfs的parent region的目錄下建立一個名為“.splits”的子目錄

4.region server 關閉parent region。強制flush快取，並且在本地資料結構中標記region為下線狀態。如果這個時候客戶端剛好請求到parent region，會丟擲NotServingRegionException。這時客戶端會進行補償性重試。

5.region server在.split 目錄下分別為兩個daughter region建立目錄和必要的資料結構。然後建立兩個引用檔案指向parent regions的檔案。

6.region server 在HDFS中，建立真正的region目錄，並且把引用檔案移到對應的目錄下。

7.region server 傳送一個put的請求到.META.表中，並且在.META.表中設定parent region為下線狀態，並且在parent region對應的row中兩個daughter region的資訊。但是這個時候在.META.表中daughter region 還不是獨立的row。這個時候如果client scan .META.表，會發現parent region正在split，但是client還看不到daughter region的資訊。當這個put 成功之後，parent region split會被正在的執行。如果在 RPC 成功之前 region server 就失敗了，master和下次開啟parent region的region server 會清除關於這次split的髒狀態。但是當RPC返回結果給到parent region ，即.META.成功更新之後，，region split的流程還會繼續進行下去。相當於是個補償機制，下次在開啟這個parent region的時候會進行相應的清理操作。

8.region server 開啟兩個daughter region接受寫操作。

9.region server 在.META.表中增加daughters A 和 B region的相關資訊，在這以後，client就能發現這兩個新的regions並且能傳送請求到這兩個新的region了。client本地具體有.META.表的快取，當他們訪問到parent region的時候，發現parent region下線了，就會重新訪問.META.表獲取最新的資訊，並且更新本地快取。

10.region server 更新 znode 的狀態為SPLIT。master就能知道狀態更新了，master的平衡機制會判斷是否需要把daughter regions 分配到其他region server 中。

11.在split之後，meta和HDFS依然會有引用指向parent region. 當compact 操作發生在daughter regions中，會重寫資料file，這個時候引用就會被逐漸的去掉。垃圾回收任務會定時檢測daughter regions是否還有引用指向parent files，如果沒有引用指向parent files的話，parent region 就會被刪除。

0.96版本中去掉了root表，因為覺的目的是根據root表獲取meta地址，過程是透過zookeeper獲取root表地址，在根據root表記錄meta表地址進行訪問，還不如和zookeeper通訊一次。meta表資訊存放在zookeeper的/hbase/meta-region-server檔案中。新版本中還新增了hbase:namespace 名稱空間表，系統表放在hbase空間下，使用者表如果沒有指定名稱空間則放在default空間下。

重新生成META表：
./hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

寬表好處：行數變少，bolck index索引減少。布隆過濾器meta index索引減少。減少空間佔用和記憶體佔用。
寬表劣處： hbase的split是基於行的，會影響split機制：
    HBase的split操作只會在行的邊界上發生，所以更傾向於長窄表：
     寬表情況下，單獨一行大小超過hbase.hregion.max.filesize值，也不會做分割
     相同rowkey下插入很多不同版本的記錄，即使大小超過hbase.hregion.max.filesize值，也不會做分割

窄表好處：將列放入rowkey查詢更加靈活方便。利於split機制
窄表劣處：索引空間佔用比寬表要大。

MR統計行數：

$HBASE_HOME/bin/hbase org.apache.hadoop.hbase.mapreduce.RowCounter ‘tablename’

Hbase運維手冊

相關文章