一、hbase读优化
客户端优化
1、scan缓存是否设置合理？
优化原理：一次scan请求，实际并不会一次就将所有数据加载到本地，而是多次RPC请求进行加载。默认100条数据大小。
优化建议：大scan场景下将scan缓存从100增大到500或者1000，以减少RPC次数
2、get请求是否可以使用批量请求？
优化原理：Hbase分别提供了单条get以及批量get的API接口，使用批量get接口可以减少客户端到RegionServer之间的PRC连接数，提高读取性能。
3、请求是否可以显示指定列族或者列？
优化原理：同一列族的数据存储在一起，不同列族的数据分开存储在不同的目录下。如果一个表有多个列族，只是根据Rowkey而不指定列族进行检索的话不同列族的数需要独立进行检索，很多情况下甚至会有2倍~3倍的性能损失。
优化建议：可以指定列族或者列进行精确查找的尽量指定查找
4、离线批量读取请求是否设置禁止缓存？
优化原理：大量数据进入缓存必将其他实时业务热点数据挤出，其他业务不得不从HDFS加载，进而会造成明细的读延迟毛刺。
优化建议：离线批量读取请求设置禁用缓存，scan.setBlockCache(false)
服务端优化
1、读请求是否均衡？
优化原理：读请求不均衡不仅会造成本身业务性能很差，还会严重影响其他业务
观察确认：观察所有RegionServer的读请求QPS曲线,确认是否存在读请求不均衡现象
优化建议：RowKey必须进行散列话处理（比如MD5散列），同时建表时必须进行预分区处理
2、BlockCache是否设置合理？
优化原理：默认情况下BlockCache和Memstore的配置相对比较均衡（各占40%），可以根据集群业务进行修正，比如读多写少可以将BlockCache占比调大。
优化建议：JVM内存配置量<20G,BlockCache策略选择LRUBlockCache;否则选择BucketCache策略的offheap模式
3、HFile文件是否太多？
优化原理：文件越多，检索所需的IO次数必然越多，读取延迟也就越高。文件数量通常取决于Compaction的执行策略，一般和两个参数有关：
hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一个store中的文件数超过多少就应该进行合并，后者表示参数合并的文件大小最大是多少，超过此大小的文件不能参与合并。
观察确认：观察RegionServer级别以及Region级别的storefile数，确认HFile文件是否过多
优化建议：hbase.store.compactionThreshold设置不能太大，默认是3个；设置需要根据Region大小确定，通常可以简单的认为：
hbase.hstore.compaction.max.size=RegionSize / hbase.hstore.compactionThreshold
4、Compaction是否消耗系统资源过多？
优化原理：Compaction是将小文件合并为大文件，提高后续业务随机读性能，但是也会带来IO放大以及带宽消耗问题，问题主要产生于配置不合理导致Minor Compaction太过频繁，或者Region设置太大情况下发生Major Compaction。
观察确认：观察系统IO资源以及带宽资源使用情况，再观察Compaction队列长度，确认是否由于Compaction导致系统资源消耗过多。
优化建议：
a、Minor Compaction设置：hbase.hstore.compactionThreshold设置不能太小，又不能设置太大，因此建议设置为5~6；hbase.hstore.compaction.max.size=RegionSize / hbase.hstore.compactionThreshold
b、Major Compaction设置：大Region读延迟敏感业务（100G以上）通常不建议开启自动Major Compaction,手动低峰期触发。小Region或者延迟不敏感业务可以开启Major Compaction，但建议限制流量
Hbase列族设计优化
1、Bloomfilter是否设置？是否设置合理？
优化原理：过滤不存在待检索Rowkey或者Row-Col的HFile文件，避免无用的IO操作。它会告诉你在这个HFile文件中是否存在待检索的key-value，如果不存在，就可以不用消耗IO打开文件进行seek，可以提升随机读写的性能。
Bloomfiler取值有两个，Row以及RowCol ；如果业务大多数随机查询仅仅使用Row作为查询条件，Bloomfiler一定要设置为Row;如果大多数随机查询使用Row+cf作为查询条件，Bloomfilter要设置为RowCol。
优化建议：任何业务都应该设置Bloomfilter，通常设置为Row就可以，除非确认业务随机查询类型为Row+cf，可以设置为RowCol
HDFS相关优化
1、Short-Circuit Local Read功能是否开启？
优化原理：当前HDFS读取数据都需要经过DataNode，客户端会向DataNode发送读取数据的请求，DataNode接受请求之后从硬盘中将文件读出来发送给客户端。Short Circuit策略允许客户端绕过DataNode直接读取本地数据。
优化建议：开启Short Circuit Local Read功能
2、Hedged Read功能是否开启？
优化原理：优先会通过Short-Circuit Local Read功能尝试本地读。某些特殊情况下，有可能会出现因为磁盘问题或者网络问题引起的短时间本地读取失败。补偿重试机制-Hedged Read的基本工作原理为：客户端发起一个本地读，一旦一段时间之后还没有返回，客户端将会向其他DataNode发送相同数据的请求。哪一个请求先返回，另一个就会被丢弃。
优化建议：开启Hedged Read功能
3、数据本地率是否太低？
优化原理：本地化率低会产生大量的跨网络IO请求，必然会导致读请求延迟较高，原因一般是因为Region迁移（自动balance开启、RegionServer宕机迁移、手动迁移等），因此一方面可以通过避免Region无故迁移来保持数据本地率，另一方面如果数据本地率很低，也可以通过执行major_compact提升数据本地率。
优化建议：避免Region无故迁移，比如关闭自动balance、RegionServer宕机及时拉起并迁回飘走的Region等；在业务低峰期执行major_compact提升数据本地率
二、Hbase写优化
1、是否需要写WAL?WAL是否需要同步写入？
优化原理：
a、WAL机制一方面是为了确保数据即使写入缓存丢失也可以恢复，另一方面是为了集群之间异步复制
b、默认开启
c、对于部分业务可能并不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，比如某些推荐业务，这类业务即使丢失一部分用户行为数据可能对推荐结果并不构成很大影响，但是对于写入吞吐量要求很高，不能造成数据队列阻塞。这种场景下可以考虑关闭WAL写入，写入吞吐量可以提升2x~3x，然而有些业务不能接受不写WAL，但是可以接受WAL异步写入，也是可以考虑优化的，通常也会带来1x~2x的性能提升。
优化建议：根据业务关注点在WAL机制与写入吞吐量直接作出选择
2、Put是否可以同步批量提交
优化原理：Hbase分别提供了单条put以及批量put的API接口，使用批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能。另外需要注意的是批量put请求要么全部成功返回，要么抛出异常。
优化建议：使用批量put进行写入请求
3、Put是否可以一步批量提交?
优化原理：业务如果可以接受异常情况下少了数据丢失的话，还可以使用异步批量提交的方式提交请求。提交分为两个阶段执行：用户提交写请求之后，数据会写入客户端缓存，并返回用户写入成功；当客户端缓存达到阈值（默认2M）之后批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。
优化建议:在业务可以接受的情况下开启异步批量提交
使用方式：setAutoFlush(false)
4、Region是否太少？
优化原理：当前集群中表的Region个数如果小于RegionServer个数，即Num（Region of Table ）< Num(RegionServer),可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度
优化建议：在Num(Region of Tale)<Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer;
5、写入请求是否不均衡？
优化原理：如果不均衡，一方面会导致系统并发度较低，另一方面也有可能造成部分节点负载很高，进而影响其他业务。
优化建议：检查Rowkey设计以及预分区策略，保证写入请求均衡。
三、Hbase优化总结
