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日志：
點擊“壓縮”進入：
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：
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結果”：
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
<span ";"="">-
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’
來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/29754888/viewspace-1593148/