hbase 优化

客户端优化

1. scan 优化
   scan数据不是一次加载到本地，而是分批rpc加载到本地，默认情况下scan缓存100，这样数据量大的时候就容易引发延迟，适当增大scan缓存，在大数据量请求是可降低整体延迟
2. get请求优化
   hbase的get请求分分单条和批量，批量请求可以减少客户端到RegionServer之间的RPC连接数
3. 请求指定列
   基于hbase列式存储的特性，同一个列族的数据在同一个目录下，不同列族在不同目录下，可以指定列族或者列进行精确查找的尽量指定查找.
   4.离线批量读取请求设置禁用缓存，scan.setBlockCache(false)。
   通常离线批量读取数据会进行一次性全表扫描，一方面数据量很大，另一方面请求只会执行一次。这种场景下如果使用scan默认设置，就会将数据从HDFS加载出来之后放到缓存。可想而知，大量数据进入缓存必将其他实时业务热点数据挤出，其他业务不得不从HDFS加载，进而会造成明显的读延迟毛刺。

服务端优化

1. 服务端延迟，一般都是服务本身存在问题，整个业务响应请求比较慢
2. 热点region现象，请求都落在一个regionserver上，hbase负载均衡现象极端，这不仅影响当前业务，还好对其他业务造成影响，建议建表示尽量使rowkey均匀分布（有序列反转。MD5。hash值等，建表预分区等），这中现象要监控regionserver的QPS防止
3. 观察所有RegionServer的缓存未命中率情况、配置文件相关配置项一级GC日志，确认BlockCache是否可以优化。
   JVM内存配置量 < 20G，BlockCache策略选择LRUBlockCache；否则选择BucketCache策略的offheap模式，BlockCache作为读缓存，对于读性能来说至关重要。默认情况下BlockCache和Memstore的配置相对比较均衡（各占40%），可以根据业务进行修正，比如读多写少业务可以将BlockCache占比调大。另一方面，BlockCache的策略选择也很重要，不同策略对读性能来说影响并不是很大，但是对GC的影响却相当显著，尤其BucketCache的offheap模式下GC表现很优越。
4. hbase Hfile
   hbase 的读写首先会从Memstore和BlockCache中检索（读取最近写入数据&热点数据）取数，如果没有检索到，再到store文件中检索。hbase的lsm特性会有好多的hfile文件，文件越多查询延迟越大，hbase有两个参数来控制store中的文件数，hbase.hstore.compactionThreshold，控制HStore的storeFile数量，超过多少就应该进行Compaction合并操作，hbase.hstore.compaction.max.size，表示参数合并的文件大小最大是多少，超过此大小的文件不能参与合并。这两个参数不能设置太’松’（前者不能设置太大，后者不能设置太小），导致Compaction合并文件的实际效果不明显，进而很多文件得不到合并。这样就会导致HFile文件数变多。
   一般的设置原则：
   hbase.hstore.compactionThreshold设置不能太大，默认是3个；设置需要根据Region大小确定，通常可以简单的认为hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold
5. hbase的 compaction
   hbase为了防止小文件（被刷到磁盘的menstore）过多，以保证保证查询效率，hbase需要在必要的时候将这些小的store file合并成相对较大的store file，这个过程就称之为compaction。在hbase中，主要存在两种类型的compaction：minor compaction和major compaction。
   major compaction 的功能是将所有的store file合并成一个，触发major compaction的可能条件有：major_compact 命令、majorCompact() API、region server自动运行（相关参数：hbase.hregion.majoucompaction 默认为24 小时、hbase.hregion.majorcompaction.jetter 默认值为0.2 防止region server 在同一时间进行major compaction）。hbase.hregion.majorcompaction.jetter参数的作用是：对参数hbase.hregion.majoucompaction 规定的值起到浮动的作用，假如两个参数都为默认值24和0,2，那么major compact最终使用的数值为：19.2~28.8 这个范围。
   minor compaction的运行机制要复杂一些，它由一下几个参数共同决定：
   hbase.hstore.compaction.min :默认值为 3，表示至少需要三个满足条件的store file时，minor compaction才会启动
   hbase.hstore.compaction.max 默认值为10，表示一次minor compaction中最多选取10个store file
   hbase.hstore.compaction.min.size 表示文件大小小于该值的store file 一定会加入到minor compaction的store file中
   hbase.hstore.compaction.max.size 表示文件大小大于该值的store file 一定会被minor compaction排除
   hbase.hstore.compaction.ratio 将store file 按照文件年龄排序（older to younger），minor compaction总是从older store file开始选择，如果该文件的size 小于它后面hbase.hstore.compaction.max 个store file size 之和乘以 该ratio，则该store file 也将加入到minor compaction 中。
   正常配置情况下Minor Compaction并不会带来很大的系统资源消耗，除非因为配置不合理导致Minor Compaction太过频繁，或者Region设置太大情况下发生Major Compaction。
   Minor Compaction设置：hbase.hstore.compactionThreshold设置不能太小，又不能设置太大，因此建议设置为5～6；hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold
   Major Compaction设置：大Region读延迟敏感业务（ 100G以上）通常不建议开启自动Major Compaction，手动低峰期触发。小Region或者延迟不敏感业务可以开启Major Compaction，但建议限制流量；
6. HBase列族设计优化
   Bloomfilter主要用来过滤不存在待检索RowKey或者Row-Col的HFile文件，避免无用的IO操作。它会告诉你在这个HFile文件中是否可能存在待检索的KV，如果不存在，就可以不用消耗IO打开文件进行seek。很显然，通过设置Bloomfilter可以提升随机读写的性能。
   建议所有业务都设置Bloomfilter避免不必要的数据检索，一般row类型即可,除非确认业务随机查询类型为row+cf，可以设置为rowcol。

hdfs 优化

1. 当前HDFS读取数据都需要经过DataNode，客户端会向DataNode发送读取数据的请求，DataNode接受到请求之后从硬盘中将文件读出来，再通过TPC发送给客户端。Short Circuit策略允许客户端绕过DataNode直接读取本地数据，可以开启Short Circuit Local Read功能
2. 开启Hedged Read功能。Short Circuit会优先在本地读取，由于网磁盘问题或者网络问题引起的短时间本地读取失败，本地读去数据一段时间没有返回时，去其他节点拉去数据，社区开发者提出了补偿重试机制 – Hedged Read。该机制基本工作原理为：客户端发起一个本地读，一旦一段时间之后还没有返回，客户端将会向其他DataNode发送相同数据的请求。哪一个请求先返回，另一个就会被丢弃。

3. 提高数据本地性，避免避免Region无故迁移来保持数据本地率，另一方面如果数据本地率很低，也可以通过执行major_compact提升数据本地率到100%，比如关闭自动balance、RS宕机及时拉起并迁回飘走的Region等；在业务低峰期执行major_compact提升数据本地率。

   https://www.zhihu.com/question/19887265/answer/23897148