HBase-1.2.3版本常用优化策略

一、hbase优化之我见

     Hbase作为一个分布式系统，本身代码量庞大，在整个Hadoop社区中，hbase的代码量是最多的，模块也很多。作为一个NoSql数据库，对其的优化无非就是想达到在保证读写的低延迟下，尽可能少的利用资源，做到资源最大化利用。一般来说，对Hbase的优化涉及的点比较广，比如hbase本身代码优化, 读的优化，写的优化，JVM配置，网络环境保障，hdfs的数据本地性等。本文将提供一些常见的优化方式，由于自身也处于探索阶段且没有相关条件来验证，也欢迎大家多提意见或数据支撑。

二、Hbase读优化

   2.1 hbase读数据的流程

       在Hbase里面,读数据会从几个地方读取。一个是memestore写缓存，一个是blockCache，一个是Hfile，其中memstore里面存的是最近写入Hbase集群且还没有flush到磁盘的数据，之所以要去读这个memstore是因为很有可能我们请求的rowkey是刚刚才写入hbase的，blockCache是读缓存，默认一个RegionServer一个blockCache，blockCache里面存的是从Hfile文件里面读出来后再加载到blockCache里面的热点数据，所以我们在读blockCache的时候,实际上也是会先去读hfile，在读Hfile的时候，根据rowkey定位到某个数据块的索引index，如果这个Index对应的块在blockCache里，就直接去读blockCache而越过hfile从而减少hfile的IO压力,而如果定位的数据块不在blockCache里面,那么就会直接读hfile,最后合并memstore，blockcache，hfile的结果返回给客户端。

  2.2 blockCache的合理配置

      对于一些读多写少的业务类型，可以适当增加blockCache的内存占用比，且选用BucketCache型的缓存策越。

  2.3  读请求是否均衡

     一般如果出现某个HRegionServer负载明显过高，可以看一下是否大量的请求落在了这台server上，而出现某台机器的负载过高很有可能是出现了热点问题。rowkey设计的不合理导致大量请求落在这台server的某些HRegion上，这就需要自己结合业务合理设计rowkey，可以考虑预分区，hash散列等方式优化rowkey。

  2.4 Hfile是否文件太多

     如果一个HRegion下的某个列族的hfile文件过多，在读的时候就会扫描大量的文件，势必会增大IO压力，且读延迟加大,，hfile文件过多一般是我们参数配置不合理引起的，需要考虑涉及执行compact操作的触发条件，控制每个列族下hfile的文件不能太多，也不能太大。

  2.5 compact操作选择时机

      在Hbase里面，major合并操作默认有2种，一种是几乎对集群没有影响的Minor major, minor compact会选择某个列族下的某些hfile文件进行合并(先读再写)，合并后文件数目减少，文件大小增大。而Major compact则是会将某个列族下的所有文件进行合并成一个，时间长，IO压力大，而且会阻塞对该HRegion的写操作。所以一般建议在集群空闲的时间手动执行major compact，关闭自动执行major compact的配置。

 2.6  scan配置

     Hbase里面有3种数据获取方式,包括get、scan range、scan。get是指获取某条数据，scan是全表扫描，scan range是范围扫描。在scan操作中,有2个参数很重要：

 Scan scan = new Scan();   //是否将读出来数据放入blockcache读缓存里面   
 scan.setCacheBlocks(false);   //表示每一次拿某个表的多少列   scan.setCaching(150);

     其中cacheBlock表示是否将scan操作读出的数据放入blockcache缓存里面，一般情况下，由于范围查询请求参数很少有一样的，都建议不要将数据放入blockcache。blockcache分为几层缓存，第一级in-memory一般是放元数据信息，比如hbase:meta表数据的in-memory就是true。而scan操作范围的数据量一般很大，所以不建议放入缓存里面。

    caching是说每次rpc请求返回的表列数的数据，这里需要了解一下scan操作的原理，scan操作并不是一次就将所有数据返回给客户端，一来容易导致客户端OOM，二来整个数据量很大网络传输也毕竟耗资源，所以它都是分批多次执行rpc请求去获取，默认是100行，比如每次rpc请求只读写100行满足条件的数据，实际生产中,可以根据自己的业务将其调大一些，减少RPC的次数，从而加快读取的速率。

2.7 get请求批量处理

      Hbase的get请求也是可以批量的，批量请求可以减少RPC次数。

2.8 只获取需要的列

     在查询的时候，可以addCloum添加你需要的列，不必进行全部列数据返回，并且可以利用hbase支持的那些过滤器来加以利用，在服务端就将数据进行过滤。

2.9 本地缓存

    其实hbase的缓存机制已经很好了，但是对于一些查询频繁的应用场景，我们也可以自己在本地再加一层缓存，这样会更快。

三、hbase写优化

  3.1 put操作处理

      Put操作也是可以批量put的，建议执行批量操作减少rpc次数。

  3.2 put操作异步处理, 关闭自动flush机制

      数据在写入hbase的时候，可以设置setAutoFlush(false)从而关闭自动刷新，每次写的时候，先缓存到客户端，当达到了客户端配置的阀值(默认是2M)再异步提交到server端，不过这有可能存在数据丢失，具体得根据自身对数据完整性要求来合理选择。

  3.3  是否必须写入WAL

      默认情况下，一个HRegionServer一个WAL。当然，当前版本也支持一个HRegion一个WAL，WAL主要是做HRegionServer宕机后的数据备份操作，保证数据的准确性，如果你的集群对这个要求不高，可以关闭wal写，每次写的时候，只写memstore就返回，写入性能会得到明显提高。  

 3.4 可能出现的配置优化

      Hbase写的时候，可能会有很多异常，包括写请求被阻塞(比如在执行major compact的时候)，写请求异常(比如写入的keyvalue数据太大)等，再比如rowkey设计不合理导致某台HRegionServer中HRgion太大，承担了大量的写入操作，而其他机器写入请求较少，导致写入在负载大的机器的请求变慢等，都有可能出现写的高延期，合理设置rowkey，合理配置各个影响参数，才能更好的利用资源，更快的响应请求。

四、hbase的列族优化

   4.1 blockSize的大小

      blockCache里面存储的数据块大小，如果你的集群的请求的数据大小较小，可以考虑将blockSize调小一些，这样一来可以使blockCache多缓存一些数据块，二来每个块小了，读的时候会块一些，但是这个需要根据你集群的数据访问方式来选择，比如你的get比较多，也就是随机读比较多，建议blockSize调小一点，如果你的scan range比较多，可以适当将blockSize调大。

   4.2 开启bloomfilter

     布隆过滤器可以有效减少扫描hfile文件的次数, 它能够帮你过滤那些肯定不存在请求rowkey对应的hfile文件，有效减少IO和读取延迟。一般情况下，如果你的业务时更多的按照row进行查询 ，建议bloomfilter设置为row，否则设置为row+列族。

    4.3 设置TTL

      如果你的数据不是永久保存，建设设置数据的过期时间，一来可以减少存储空间，二来也可以加快访问速度。

    4.4 设置最大版本数

         Hbase1.2.3版本默认最大版本数是1，版本越多，占用磁盘空间且导致集群变大，最好保持默认版本就行，只存储最新的版本数据。

五、其它优化

     其它优化主要是一些软硬件配置优化，比如hbase是基于LSM结果的一种存储数据库，对内存要求需求大，而它所支持的数据压缩，多条件扫描都是CPU密集型的计算,所有最好内存要打，cpu也要够强悍。

    Jvm优化主要是为了尽量避免full gc,避免出现stop the world的情况,然后根据业务需求，机器配置，合理配置各台机器上，memstore，blockcache的内存占比等。

       还有很多优化，比如hbase是基于hdfs的，hdfs也有很多优化，还有zookeeper，本文不做讨论，当然，如果还能想到其他可优化的地方，后面再做补充，也欢迎大家commit。