十二、HBase运维
1、HBase监控指标
1.1、指标收集：http://master_ip:port/jmx；http://regionserver_ip:port/jmx
1.2、HBase核心指标
1.2.1、通用指标
regionCount： RegionServer上Region个数
storeFileCount： RegionServer上HFile的个数
storeFileSize： RegionServershang HFile的总大小
hlogFileCount： RegionServer上HLog文件数量
totalReuqestCount： RegionServer累计请求数
readRequestCount： RegionServer累计读请求数
writeRequestCount： RegionServer累计写请求数
munOpenConnections： RegionServer上开启的RPC连接数
munActiveHandler： RegionServer上活跃的请求队列Handler数量
flushQueueLength： Region Serve上flush队列长度
compactionQueueLength： RegionServer上Compaction队列长度
GcTimeMillis： RegionServer上当前GC时长
GcTimeMillisParNew： RegionServer上新生代GC时长
GcTimeMillisConcurrentMarkSweep： RegionServer上老年代GC时长
1.2.2、HBase写相关指标
memStoreSize： RegionServer上MemStore的总大小
updatesBlockedTime： RegionServer上因文件太多导致更新被阻塞的时间（毫秒）
1.2.3、读相关指标
blockCacheHitCount： 命中BlockCache的次数
blockCacheMissCount： 未命中BlockCache的次数
blockCacheExpressHitPercent： BlockCache命中率
percentFileLoacl： RegionServer上数据本地率
showGetCount： RegionServer上slow get的数量
1.2.4、系统硬件相关指标
系统IO、CPU、网络带宽、系统内存等
2、HBase业务隔离
HBase集群上业务共享的资源主要有队列资源、CPU/内存资源、IO资源等。
2.1、队列资源隔离：RegionServer默认提供一个请求队列给所有业务使用，这会导致部分延迟较高的请求影响其他对延迟敏感的业务，HBase并没有提供业务级别的队列设置功能，而是提供了读写队列隔离的方案。总共有三个队列: 写队列、get队列、scan队列
2.2、CPU/内存资源隔离：计算资源隔离的主流方案有Docker容器、yarn容器等，结合HBase使用场景，实现业务之间计算资源隔离还需要让不同业务运行在不同容器上，HBase提供了RSGroup方案，用户可以将集群划分为多个组，每个组包含指定RegionServer集合这样i就实现了业务之间计算资源隔离。
2.2、IO资源隔离：HBase存储依赖于HDFS系统，HDFS没有提供业务隔离的针对方案，这导致在IO隔离方面没有好的解决方案，目前只能独立部署HBase集群进行隔离
3、HBase核心参数配置
3.1、Region相关参数
hbase.hregion.max.filesize:默认10G,Region中最大Store的所有文件大小一旦超过该值就会执行分裂
太大：导致系统执行Compaction消耗大量系统资源，一定程度上影响业务响应
太小：导致Region分裂频繁，太多Region会消耗大量系统资源，并且在RS故障恢复时比较耗时
3.2、BlockCache相关参数
RegionSever内存在20G以内就选择LRUBlockCache,大于20G选择BucketCache的offHeap模式
hfile.block.cache.size:默认为0.4、设置LRUCache的内存大小，0.4表示JVM内存的40%
当前HBase默认采用LRUCache策略，blockCache和MemStore大小均为JVM的40%
hbase.bucketcache.ioengine:BucketCache策略的模式选择，包含heap、offheap、file三种。分别使用堆内存、堆外内存以及SSD硬盘作为存储介质
hbase.bucketcache.size:堆外内存大小。
3.3、MemStore相关参数
hbase.hregion.memstore.flush.size:默认128M,MemStore大于该值就会触发Flush,如果当前系统flush比较频繁，并且内存资源比较充足，可以适当提高，调大的副作用，这可能造成宕机时需要Split的HLog数量增多（原因是，你存在内存的东西变多了，宕机丢失数据更多、所以要恢复的HLog数据也会变多），从而延长故障恢复
hbase.hregion.memstore.block.multiplier:默认为4，表示一旦某个Region中所有写入MemStore的数据大小总和达到MemStore大小的4倍，就会强制执行Flush,并抛出RegionTooBusyException.如果日志中出现类似‘“Above memstore limit,regionName=,server=,memstoreSize="就需要考虑修改该参数了。
hbase.regionserver.global.memstore.size:默认0.4，表示占用总JVM内存大小的40%，整个RegionSever上所有MemStore的数据总大小不能超过该值，否则会阻塞所有请求并强制执行Flush。一旦写入阻塞，查看日志是否会有Blocking updates on关键字，如果存在说明当前RS Memstore已经超过阈值，需要明确是不是Region数目太多，单表列簇设计太或者该参数设置太小。
hbase.regionserver.global.memstore.lower.limit:默认0.95，表示达到JVM * hbase.regionserver.global.memstore.size 的0.95时就会选择最大的MemStore进行Flush
hbase.regionserver.opionalcaheflushinterval:默认为1H，HBase会发起一个线程定期flush所有的MemStore
3.4、Compaction相关参数
hbase.hstore.compactionThreshold:默认为3，当Store中文件数超过该阈值就会触发Compaction
hbase.hstore.compactiom.max：默认是10，最多可参与minor compaction 的文件数
hbase.regionserver.thread.compaction.throttle：默认是2G,是评估单个Compaction为大还是小的依据，为了防止大的compaction长时间执行阻塞其他小的compaction、HBase会根据compaction的大小进行分离处理，每种Compaction会分配独立的线程池。
hbase.regionseever.thread.compaction.large/small：默认为1，大compact 、小compact处理的线程数，在负载比较高的集群，可以适当增加
hbase.hstore.blockingStoreFiles: 默认是10,表示某个Store文件数一旦大于该阈值，就会导致阻塞更新，日志中出现 too many store files 就要查看该值设置是否合理
hbase.hregion.majorcompaction：默认1周进行一个Major Compaction，生产建议大表选择业务低峰期手动执行。将此参数设置为0代表关闭自动触发
3.5、Hlog相关参数
hbase.regionserver.maxlogs: 默认32，Region触发flush条件之一，wal日志文件总数超过阈值就会强制执行flush操作。默认值对于很多集群太小，具体设置参考HBASE-14951
heap memstore perc maxLogs
1G 40% 32
2G 40% 32
10G 40% 80
20G 40% 160
32G 40% 256
hbase.regionserver.hlog.splitlog.writer.threads：默认为3，RegionSever在恢复数据时HLog日志按照Region分组之后重新写入HDFS的线程数，生产环境中Region个数普遍较多，为了加速数据恢复，建议调大
3.6、请求队列相关参数
hbase.regionserver.handler.count:默认30，服务端用来处理用户请求的线程数，生产通常需要将该值调到100-200，请求时间由2部分构成，排队时间和处理时间，需要关注排队时间，如果排队很长，需要检查此参数是否合理
hbase.ipc.server.callqueue.handler.factor:默认为0，服务端设置队列个数，加入该值为0.1，那么服务器就会设置 30*0.1=3个队列。
hbase.ipc.server.callqueue.read.ratio:默认为0，表示服务端读写业务分别占用队列的比例
hbase.ipc.server.call.queue.scan.ratio:默认为0，表示在读的队列中 get 和scan的队列占比
3.7、其他重要参数
hbase.online.schema.update.enable:默认为true.更新表schema的时候不需要先disable在enable。直接在线更新即可。建议开启
hbase.quota.enabled：默认为false,表示是否开启quota功能，quota的功能主要是限制用户/表的QPS，起到限流作用
hbase.snapshot.endbled：默认为true.表示是否开启snapshot功能，建议开启
zookeeper.session.timeout：默认180s。表示RS与zk的超时时间，超时之后RS将会被踢出集群
hbase.zookeeper.useMutil：默认为ture。开启ZKmutil功能，在某些场景下可以加速批量请求。生产建议设置为true
hbase.coprocessor.master.classes：生产建议设置org.apache.hadoop.hbase.security.access.AccessController,可以使用grant 对namespace、table
、CF设置访问权限
hbase.coprocessor.region.classes：生产建议设置为org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController
4、HBase表设计
4.1、表名：建议使用nameSpace + 表名的方式，将同一个业务的表放在一个同一个命令空间下
4.2、列簇属性设置
4.2.1、VERSION: 保留最大版本数，默认是1.
4.2.2、BLOCKCACHE: 是否开启Block Cache，默认true.在两种场景下可以设置为flase: 数据量很大且读取没有任何热点；表数据仅供OLAP,没有OLTP需求
4.2.3、BLOOMFILTER:默认是ROW。ROW模式表示仅仅根据Rowkey就可以判断待查找数据是否存在HFile中，而ROWCOL模式只对指定列的随机读由优化作用，通常建议选择ROW模式
4.2.4、TTL:数据失效时间
4.2.5、COMPRESSION:压缩算法，建议SNAPPY,压缩率，编码速率等方面表现更加优秀
4.2.6、DATA_BLOCK_ENCODING:数据编码算法，生产不使用PREFIX_TREE编码算法
4.2.7、BLOCKSIZE: 文件块大小，默认是64k,建议选择默认。
4.2.8、DFS_REPLICATION:数据Block在HDFS上的副本数，默认是3
4.2.9、IN_MEMORY:如果表中某些列的数据量不大。但是进行get/scan操作频率又特别高，而且要求延迟更低，此时采用IN_MEMORY效果比较好
4.3、表属性设置
4.3.1、预分区设置属性：建议所有表线上进行预分区，NUMREGIONS表示预分区个数。SPLITALGO代表切分策略
4.3.2、MAX_FILESIZE:最大文件大小，默认是10G，配合Region的分裂
4.3.3、READONLY：只读表，默认为false
4.3.4、COMPACTION_ENABLED:compaction是否开启，默认为true,表示允许Minor/Major Compaction自动执行
4.3.5、MEMSTORE_FLUSHSIZE:单个MemStore的大小，默认128M
4.3.6、DURABLITY:WAL持久化级别
SKIP_WAL:只写缓存，不写HLog，不可取
ASYNC_WAL：异步写入HLog
SYNC_WAL：同步写入日志文件，数据只是被写入文件系统缓存中并没有真正落盘。默认是此级别
FSYNC_WAL：同步将数据写入日志文件并强制落盘，这是最严格的写入级别，保证数据不丢失，性能相对较差
USER_DEFAULT：如果用户没有指定持久化级别，默认HBase使用SYN_WAL等级持久化数据put.setDurability(Durability.SYNC_WAL);
