- 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模式，配置计算方式参考：
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:-DisableExplicitGCJDK 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