HBase 经验小结 （Based on 1.x）

1. HBase
   1.1 存储

• Phoenix
  Schema qualifier管理方便、偶尔的SQL查数方便
  用不到二级索引实际没必要要，会有必定的性能损耗

• 列族划分
  粗粒度划分对于schema管理及上层取数十分方便
  列划分过大容易频繁触发flush，且对于部分不须要全列数据影响查询性能

• 预分区
  极大缓解在业务读写中Split和数据倾斜带来的开销
  有些业务场景的rowkey须要hash作适配预分区，要求不高的好比md5等

• 压缩与编码
  压缩可能采用Snappy，冷备集群能够考虑Gzip
  编码慎用所谓推荐的prefixTree，1.x版本有bug。ref: HBASE-12959

• 多版本存储
  利用timestamp能够作版本冗余、一致性问题缓解等事情
  注意磁盘压力，尤为是还有按期作snapshot的，archive有可能回收会比较慢

1.2 写入

• 注意List 批次大小
  适当聚合请求会加速一样数量的请求速度，减小请求IO次数
  批次太大会形成slow multi request，这类慢请求过多会影响吞吐率，后来的请求只能在客户端轮询wait

• 写请求较多的场景注意控制compaction
  若有必要能够手动关闭major compact，在闲时手动触发
  删改请求较多的，能够适当缩小major compact的间隔，以避免读性能影响

1.3 读取

• 注意List 批次大小
  适当聚合请求会加速一样数量的请求速度，减小请求IO次数
  批次太大会形成slow multi request，这类慢请求过多会影响吞吐率，后来的请求只能在客户端轮询wait
  Get所请求的字节数过大(超过数组上限)的话会没法返回，1.2.0以前的版本甚至会致使RegionServer OOM 宕机。

• 注意Version、ttl的特殊性，区分数据的逻辑删除与物理删除
  用户视角的HBase自身一致性问题80%都是搞不清楚逻辑删除。
  逻辑删除：HBase会读到这个数据，可是在RS层根据策略不返回给用户
  物理删除：真的从HDFS删除此数据，发生于compact阶段

• Scan的Filter
  善用Filter作下推减小返回的数据数量
  Filter也不要嵌套太复杂，使得RegionServer处理负载较重
  注意设置到Filter的qualifier首先要能取出来，所以scan若是显示设置了addColumn/addFamily，须要记得包括filter的qualifier
  注意指定qualifier是否为null，有可能致使想拿的数据没拿到；结合 filter.setFilterIfMissing 使用。

• Scan优化
  适当设置caching，通常为100
  blockCache设为false
  只取本身关注的列
  考虑设置 hbase.mapreduce.input.autobalance = true 以解决预期Region取数不太均衡或数据倾斜的scan问题

• BlockCache缓存配置
  强烈建议用BucketCache的offheap模式，配置计算方式参考：http://hbasefly.com/2016/04/08/hbase-blockcache-1/

1.4 GC优化

• JDK 1.7+ && CMS优化 (netease) :
  -Xmx20g -Xms20g -Xmn512m -Xss256k
  -XX:MaxPermSize=256m -XX:SurvivorRatio=2
  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
  -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15
  -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
  -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

• JDK 1.8+ && G1GC (XIaomi):
  -Xmx20g -Xms20g -XX:MaxDirectMemorySize=20g
  -XX:+UseG1GC
  -XX:+UnlockExperimentalVMOptions 
  -XX:MaxGCPauseMillis=90
  -XX:G1NewSizePercent=2 
  -XX:InitiatingHeapOccupancyPercent=65 
  -XX:+ParallelRefProcEnabled
  -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:MaxTenuringThreshold=1 
  -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=64 -XX:G1OldCSetRegionThresholdPercent=5
  -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime 
  -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy 
  -XX:+PrintTenuringDistribution -XX:+PrintSafepointS

GC状况最后依然还需根据实际本身的状况进行调整。

1.5 监控
方案：ELK、Grafana + 时序数据库(Opentsdb)/监控系统(OpenFalcon)等
指标：JVM (GC、Heap、OffHeap等)、Compact、Split、缓存命中数、各种请求count、slow request count、集群基础监控。（注：以上监控除了JVM和集群基础，有条件的表级别和RegionServer级别都作一份）

另：记得对RegionServer作自动拉起的守护进程。

1.6 Linux

• 关闭大页 Tuning transparent huge pages (THP) off
• 禁止swap Set vm.swappiness = 0
• 关闭NUMA vm.zone_reclaim_mode = 0

以上操做系统配置基本适用于持续服务的高读性能数据存储集群，包括但不只限于HBase、ES等。

1.7 备份与容灾
数据层面目前官方版本只支持异步式的冷备。

• Snapshot/Export 机制
  每次都是全量备份
  自行维护WAL回放（或业务重放）
• HBase 2.0 增量备份
  利用WAL作增量备份
  不支持对备份作compact，增量太多时恢复速度须要关注
• 主从一致性（备份自己也可能由于网络等缘由失败）

1.8 部署

• Master HA
• Region预留足够offheap内存给BucketCache读缓存，2.x会更多的利用offheap以缓解GC