問題標題：CTBase manager頁面無法開啟，Hbase不可用

問題描述：hbase shell操作時報錯HMaster正在初始化
ERROR:org.apache.hadoop.hbase.PleaseHoldException:Master is initializing
問題定位：檢視HMaster日誌發現HMaster啟動時等待指派namespace表超時,導致主備HMaster一直在不停切換

Timeout: 300000ms waiting for namespace table to be assigned
以上日誌說明hmaster啟動超時，導致主備hmaster不停切換

解決方案：
將namespace初始化超時時間調大
C50SPC202版本中沒有hbase.master.namespace.init.timeout配置項，需要手動新增
解決問題步驟
1.在/opt/huawei/Bigdata/om-0.1.1/etc/components/FusionInsight_V100R002C50SPC202/HBase/configuration.xml配置檔案中，HMaster標籤下，找到hbase-site.xml,手動新增配置項hbase.master.namespace.init.timeout：
 值設為36000000
2.重啟controller
   sh /opt/huawei/Bigdata/om-0.1.1/sbin/restart-controller.sh
3.在manager web UI同步配置
4.重啟HBase服務
5.HBase恢復正常

問題標題：hbase讀取慢

問題描述：應用部署到生產環境大資料集群后，從hbase讀取資料很慢，耗時18秒左右才能返回資料，導致其他應用訪問超時無法正常使用，目前資料量非常少，不超過500條記錄。
同樣的應用在開發環境部署，訪問hbase耗時最多不超過3秒，基本在可接受範圍內。

Timeout: 300000ms waiting for namespace table to be assigned
以上日誌說明hmaster啟動超時，導致主備hmaster不停切換

解決方案：配置了DNS，客戶端與叢集互動過程中會去DNS伺服器解析叢集ip，存在時延問題
備份客戶端DNS配置檔案並清空
# cp /etc/resolv.conf /etc/resolv.conf-bak
# echo "" > /etc/resolv.conf

無法提交Loader任務

admin和hbase_bk_user使用者都無法提交loader作業，錯誤提示如下：org.apache.hadoop.yarn.exceptions.YarnException: Failed to submit application_1495015772433_0204 to YARN : Failed to submit application application_1495015772433_0204 submitted by user hbase_bk_user reason: No groups found for user hbase_bk_user (caused by: Failed to submit application_1495015772433_0204 to YARN : Failed to submit application application_1495015772433_0204 submitted by user hbase_bk_user reason: No groups found for user hbase_bk_user

其中一個節點的/var目錄已經達到100%，清理空間後即可正常提交作業。

如何配置Hbase快取

1.在使用客戶端讀取HBase的資料時，可以通過在程式碼使用上進行配置和優化，做到提高讀取速度的提高。客戶端預設快取的資料大小，呼叫Scanner.next的時候會先從快取中取資料，如果快取中資料取完後才向regionserver進行scan請求。增大改值可以提高客戶端讀取資料的速度，並且大大降低對regionserver的請求個數。             hbase.client.scanner.max.result.size，client請求rs上每次返回結果的最大大小。可以增大該數值來增加每次請求regionserver上得到資料量，從而降低到regionserver的請求。 2.在RegionServer端可以配置Block的快取區大小，一定程度提高查詢效率。HBase 快取區大小，主要影響查詢效能。根據查詢模式以及查詢記錄分佈情況來決定快取區的大小。

客戶端訪問Phoenix報錯

zookeeper.ClientCnxn: Session establishment complete on server hdgycn02/99.12.166.131:24002, sessionid = 0x1e04533cfe1a6416, negotiated timeout = 90000
2017-05-08 15:32:26,334 ERROR [main-SendThread(hdgycn02:24002)] client.ZooKeeperSaslClient: An error: (java.security.PrivilegedActionException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)]) occurred when evaluating Zookeeper Quorum Member's  received SASL token. This may be caused by Java's being unable to resolve the Zookeeper Quorum Member's hostname correctly. You may want to try to adding '-Dsun.net.spi.nameservice.provider.1=dns,sun' to your client's JVMFLAGS environment. Zookeeper Client will go to AUTH_FAILED state.

叢集上hbase預分region的建議

預設情況下，在建立HBase表的時候會自動建立一個region分割槽，當匯入資料的時候，所有的HBase客戶端都向這一個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的regions，這樣當資料寫入HBase時，會按照region分割槽情況，在叢集內做資料的負載均衡。

Pheonix無法連線Hbase

問題處理步驟描述：
1.發現數據中心叢集pheonix無法訪問hbase表，SYSTEM.CATALOG表無法訪問
2.執行is_enabled SYSTEM.CATALOG,返回false；執行is_disabled SYSTEM.CATALOG,返回false
3.重啟HBase服務，執行is_enabled SYSTEM.CATALOG,返回true;執行is_disabled SYSTEM.CATALOG,返回false；
   檢視HBase原生頁面發現SYSTEM.CATALOG表的一個region為offline狀態
4.執行hdfs fsck hdfs://hacluster/hbase/WALs/hdsjzxdata3g03u08p,21302,1498474722136-splitting/hdsjzxdata3g03u08p%2C21302%2C1498474722136.default.1500233042596
   返回Fsck on path'/hbase/WALs/hdsjzxdata3g03u08p,21302,1498474722136-splitting/hdsjzxdata3g03u08p%2C21302%2C1498474722136.default.1500233042596’ FAILED

1.執行hdfs fsck –openforwrite path –files  -blocks –locations,將檔案‘hdsjzxdata3g03u08p%2C21302%2C1498474722136.default.1500233042596’ mv到了其他目錄
2.倒換主備Hmaster
3.恢復正常  

Hbase表無法匯出

Hbase大表資料匯出指令碼執行失敗，其他HBase小表匯出指令碼可成功執行，指令碼使用export API 匯出表

檢查叢集發現一個regionserver宕機，無法ping通，懷疑匯出指令碼執行失敗是因為宕機伺服器上分配了匯出表region，宕機後region尚未遷移完成導致指令碼執行失敗。   檢視匯出表region分配和狀態，確認各個region狀態良好，證明region遷移完成，重新執行之前失敗的指令碼，執行成功。

告警HDFS不可用，檢視日誌顯示HDFS無法寫入

一句話說明：HDFS啟動失敗原因為Hbase\CTBASE側併發寫入導致HDFS預約空間滿。
技術說明：某個DN1中有n個寫執行緒，那麼針對這n個寫併發需要預約空間 = BlockSize * n 的磁碟空間，現場DataNode節點磁碟空間較少，可用空間剩餘50G，預設最高支援50000/128=390併發；
 
1.       通過NameNode日誌檢查大量的寫檔案報沒空間，但是檢視剩餘實際DataNode空間還有50G可用
2017-07-19 10:51:31,135 | WARN | Thread-7 | DataStreamer Exception | DataStreamer.java:694 org.apache.hadoop.ipc.RemoteException(java.io.IOException): File /hdfsServiceCheck-99-8-58-32-hm3._COPYING_ could only be replicated to 0 nodes instead of minReplication (=1). There are 3 datanode(s) running and no node(s) are excluded in this operation.
2.       檢視namenode  20分鐘的日誌，超過3萬個allocate，說明有高併發寫，且由hbase/ctbase 發起，導致預約的Datanode空間滿，無法分配新空間，觸發下述報錯。
   2017-07-19 09:01:16,892 | INFO  | IPC Server handler 16 on 25000 | BLOCK* allocate blk_1081389716_1099521341712{UCState=UNDER_CONSTRUCTION, truncateBlock=null, primaryNodeIndex=-1, replicas=[ReplicaUC[[DISK]DS-42523040-cac6-4e51-bd03-ac0add9dde12:NORMAL:99.8.58.35:25009|RBW]]} for /hbase/data/default/RT_LA101_BASE/e90229296d66e1fe2132c2417de68eb1/recovered.edits/0000000000000000097.temp | FSNamesystem.java:3496
 3.       判斷為併發過大但blocksize預設128M導致可用的預約空間不足，指導現網調整了HDFS客戶端block大小的引數（即hbase/ctbase 的dfs.blocksize）為16M並重啟，即可規避”預約空間滿”的問題，成功啟動HDFS。
 

叢集資料量過大

年中大資料深度巡檢過程，瞭解到渠道大資料叢集，HBase的資料量達到20.2T，HDFS使用率達到83%，每日增長2%，有接近HDFS最大值90%的風險（HDFS預留10%空間不可用於儲存實際使用者資料）。
    瞭解到渠道大資料叢集，只需要大部分HBase資料保留時間為3個月。並且已經設定了TTL屬性為3個月，也就是說時間戳超過3個月的資料屬於過期資料。其中最大的設定了TTL的大表資料已經達到了6.5T，業務預計實際資料量為3-4T。

 RegionServer的GC_OPTS引數，調整
a) hbase.hstore.compaction.max.size 由 2.5G 變為 不受限制
b) hbase.regionserver.thread.compaction.large 調大2倍,由5調到10
c) hbase.hstore.compaction.kv.max由10 調大到 100
 在業務空閒時期，手動執行major compaction
a) 使用admin使用者登入hbase shell，執行major_comcompact ‘表名’

客戶端無法訪問hbase表

FusionInsight manage頁面hmaster例項的狀態一個為unknown，一個為standby Hbase shell中執行list無法返回列出表清單業務層無法讀取phoenix表

Exception，Abort                                 其他底層依賴服務無異常告警                            在zk客戶端執行deleteall /hbase/region-in-transition                                            修改hbase.master.initializationmonitor.haltontimeout為原值的5倍，修改後為150000000
未改大之前，hmaster反覆重啟                            修改zookeeper.session.timeout為原值的2倍，修改後為90000                                                 重啟hbase                                              重啟之後，HBase服務部分恢復正常，包括hbase shell可以正常寫資料、flush，phoenix讀資料正常。
但是存在421個region長期處於rit狀態                             執行hbase hbck檢查存在大量不一致，執行-fixMeta –fixAssignments –fixReferenceFiles –fixHdfsHoles，rit數量沒有減少。
檢視對應region在主hmaster日誌中的記錄，發現存在Couldn’t reach online server hdsjzxdata3g01u14p,21302,15000999163339以及Skip assigning RS6000_CW:biz_sys_othernew_mi記錄

blu偶發性查詢hbase失敗

異常堆疊中顯示zookeeper客戶端認證失敗，是由於zookeeper票據relogin時失敗，調整應用中的krb5.conf不小於10，增加認證成功率

admin使用者在hbase shell檢視hbase大表數量與在hmaster數量不一致；匯出大表DC_BASE資料報錯沒許可權；admin使用者執行hdfs dfs -ls /hbase返回沒許可權

1 修改了引數
需要調整RegionServer GC_OPTS（以下不是直接替換，而是修改前面一部分）
 -server -Xms20G -Xmx20G -XX:NewSize=2G -XX:MaxNewSize=2G -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=512M -XX:MaxDirectMemorySize=4G                     2  對部分節點恢復id –Gn，重啟sssd
service sssd restart
id -Gn admin

hbase部分region不可用

一個regionserver故障重啟後，region顯示不線上，客戶端請求相關region無返回，old：
-server -Xms512M -Xmx1G -XX:NewSize=64M -XX:MaxNewSize=128M -XX:PermSize=128M -XX:MaxPermSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=128M -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=65 -Xloggc:/var/log/Bigdata/hbase/hm/master-omm-gc.log -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps
new:
-server -Xms4G -Xmx4G -XX:NewSize=256M -XX:MaxNewSize=256M -XX:PermSize=128M -XX:MaxPermSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=2G -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=65 -Xloggc:/var/log/Bigdata/hbase/hm/master-omm-gc.log -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps
old:
-server -Xms4G -Xmx6G -XX:NewSize=256M -XX:MaxNewSize=512M -XX:PermSize=128M -XX:MaxPermSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=512M -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=65 -Xloggc:/var/log/Bigdata/hbase/rs/regionserver-omm-gc.log -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps
new:
-server -Xms20G -Xmx20G -XX:NewSize=2G -XX:MaxNewSize=2G -XX:PermSize=128M -XX:MaxPermSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=4G -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=65 -Xloggc:/var/log/Bigdata/hbase/rs/regionserver-omm-gc.log -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps

批量匯入Hbase資料失敗

檢視Flush佇列和Compaction佇列，佇列數均高達100以上,該問題為開源bug，重啟Hbase服務後解決

hbase與pheonix資料不一致

Phoenix關聯的hbase，出現數據不一致的情況。其中，cust_tag與cust_his都是以create table方式建立，統計結果均有出入。cust_asset以create view建立，統計count一致。                                             cust_tag，hbase裡count記錄是140多萬，在Phoenix統計count只有6萬多； 
cust_his，每天有近千萬資料插入，但在Phoenix按"date"列檢索只查到8.4之前的記錄，8.4之後無記錄

spark導資料進入hbase失敗

檢查應用日誌，報錯無法找到某個region在xxxregionserver，在原生頁面檢視該regionserver，確實看不到那個region，檢視meta表可以找到這個region。Hmaster原生頁面後來出現該region處於RIT狀態，執行hbck，大約10%的region不一致。檢視manager告警，發現日誌中描述報錯region所在regionserver有塊磁碟多次出現慢盤告警，每天可達5次以上。停掉該regionserver，業務恢復。但是meta表和原生頁面的region數量仍然不一致，原生頁面顯示region數量37000左右，meta表裡記錄了39000左右。執行hback -repair相關的表，region數量恢復一致。

增量匯出hbase資料速度非常慢

10.14號將LOG_BASE表的匯出任務遷移到了備叢集，該匯出job ExportUserTable_LOG_BASE_T_VINCIO_LOG每天跑100多次，任務調起時間約為02:00-16:00。檢視兩個EXPORT任務get運算元量，ExportUserTable_PRM_BASE_T_PRMI_TRANSACTION和ExportUserTable_LOG_BASE_T_VINCIO_LOG均為一千萬次左右，而VINCIO_LOG匯出任務每天執行100多次，相當於給叢集增加了100多倍的get讀負荷，造成服務端相應等待。     解決方案：建議PRM_BASE表匯出任務執行時間與LOG_BASE表匯出任務執行時間完全錯開。

巡檢時發現多個regionserver啟動時間不一樣

region server多次觸發重啟，regionserver非同時重啟，不影響業務。檢視重啟時刻的regionserver日誌，該時刻發現大量GC pause記錄，初步定位為GC引數設定問題。需要根據詳細日誌進一步定位。

發現匯出HBase增量資料重複

發現Hbase的region存在重複，部分region的start key相同；部分region的end key相同。執行 hbase hbck -fixHdfsOverlaps -sidelineBigOverlaps -maxMerge 200 -maxOverlapsToSideline -fixAssignments -fixReferenceFiles -fixMeta 表名；hbase hbck -repair 表名後修復

Hbase原生介面建立zk連線數過多

該介面就是每呼叫一次建立一次zk連線，建議慎用該介面/**
* get the regions of a given table.
*
* @param tableName the name of the table
* @return Ordered list of {@link HRegionInfo}.
* @throws IOException
*/
@Override
public List<HRegionInfo> getTableRegions(final TableName tableName)
throws IOException {
ZooKeeperWatcher zookeeper =
 new ZooKeeperWatcher(conf, ZK_IDENTIFIER_PREFIX + connection.toString(),
   new ThrowableAbortable());
List<HRegionInfo> Regions = null;
try {
 Regions = MetaTableAccessor.getTableRegions(zookeeper, connection, tableName, true);
} finally {
 zookeeper.close();
}
return Regions;
} 

反覆嘗試匯出Hbase增量資料失敗

過為空的二級索引，並不能跳過某欄位為空 2.檢視該二級索引對應的主索引存在 3.拼主索引的rowkey，根據日誌中空二級索引rowkey的資訊拼接主/二級索引在大表裡對應的rowkey，在hbase shell裡scan這些rowkey，都無返回的value，至此說明二級索引對應的空欄位在hbase大表裡也為空。原因可能是當日的應用沒有成功寫入這些資料 4.將24小時增量資料匯出任務，按照3小時一個任務分拆稱為8個重新執行，結果2個失敗，6個成功，說明存在較多空欄位  5.安裝hd客戶端並安裝CTBase0.76客戶端，source後重新執行匯出資料指令碼，資料匯出成功  6.建議客戶在程式中加入寫入失敗多次重試機制

HBase scan超時

加filter操作超時，filter過濾條件為某列（時間）在一定的時間範圍之內，報錯找不到租約。。該表大小1.3T，3000多個region。優化方案：1.將掃描操作寫成mapreduce程式，提交到yarn執行；2.給過濾欄位建立二級索引；3.定期執行major compaction，清理冗餘資料。

oldWALs無法自動刪除

檢視Hmaster日誌，發現負責定期清理oldWALs的執行緒異常停止，可以通過倒換主備重啟執行緒2018-01-05 10:04:15,954 | WARN  | hdchannel-mgt3,21300,1514367333682_ChoreService_1 | A file cleanerLogsCleaner is stopped, won't delete any more files in:hdfs://hacluster/hbase/oldWALs | org.apache.hadoop.hbase.master.cleaner.CleanerChore.checkAndDeleteFiles(CleanerChore.java:228)

二級索引重構資料失敗

重構資料的二級索引欄位組成和主索引一致，只是順序不一樣，重新在二級索引中添加了一個欄位與主索引分開後，重構資料成功。長期解決方案為升級CTBase版本。

問題描述：

每天凌晨1:00呼叫指令碼完成HBase增量資料匯出到叢集外，以做離線分析，指令碼呼叫的是hbase提供的export介面。該程式已連續執行30天，今天突然失敗。

分析：檢視任務日誌，HBase資料匯出到HDFS這一步就失敗了。

通過YARN檢視該export MapReduce job，該job中有83個map task，其中82個已經完成，剩下1個map task一直處在running狀態，正常情況下半個小時左右整個程式可以跑完，但是這個map task已經處在running狀態。正是這個task導致整個程式掛住。

正常情況下半個小時左右整個程式可以跑完，但是這個map task已經處在running狀態。
檢視HBase服務狀態良好，通過manager檢視該task所在regionserver節點狀態正常，通過HMaster檢視增量匯出失敗表所在該regionserver的region狀態正常，由此基本可以判斷HBase服務本身沒問題。

通過YARN檢視該task日誌，發現報錯OutOfOrderScannerNextException，判斷scan操作讀超時，調整客戶端引數hbase.client.scanner.caching值由100到50，即一次scan操作返回50行資料，減少了每次scan花費的時間，降低了呼叫next時超時的可能性。另外，調整客戶端配置hbase.rpc.timeout值從60000到600000，增加客戶端rpc操作超時容忍時間。

改完以上配置後，手動呼叫重啟程式，順利執行完成。

為什麼前30天程式可以正常執行，但是今天突然出現異常？

個人認為可能有兩點原因：

1.scanner掛住的的map task所在的region的資料量較大，導致scan時延大

2.該叢集業務量增加或業務高峰導致網路IO負載大，(或者網路本身的問題導致網路IO慢),最終導致一次scan時間較長。