问题标题：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： 值设为360000002.重启controller sh /opt/huawei/Bigdata/om-0.1.1/sbin/restart-controller.sh3.在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 = 900002017-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.
报错信息显示客户端在连接zk时，出现票据超期连接失效，调整下客户端配置文件/opt/hadoop_client/Spark/adapter/client/controller/jaas.conf中的连接方式 默认使用cache方式连接，建议调整为使用keytab方式连接zk Client {com.sun.security.auth.module.Krb5LoginModule requireduseKeyTab=truekeyTab="/opt/keytabFile/hbase.keytab"principal="hbase/zkclient.hadoop.com@HADOOP.COM"useTicketCache=falsestoreKey=truedebug=true;}集群上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,返回false3.重启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,21302,1498474722136.default.1500233042596 返回Fsck on path'/hbase/WALs/hdsjzxdata3g03u08p,21302,1498474722136-splitting/hdsjzxdata3g03u08p,21302,1498474722136.default.1500233042596’ FAILED
1.执行hdfs fsck –openforwrite path –files -blocks –locations,将文件‘hdsjzxdata3g03u08p,21302,1498474722136.default.1500233042596’ mv到了其他目录2.倒换主备Hmaster3.恢复正常
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调到10c) hbase.hstore.compaction.kv.max由10 调大到 100 在业务空闲时期，手动执行major compactiona) 使用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，重启sssdservice sssd restartid -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:+PrintGCDateStampsnew:-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:+PrintGCDateStampsold:-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:+PrintGCDateStampsnew:-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*/@Overridepublic 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时间较长。
