HBase写性能优化策略

HBase写入通常会遇到两种问题：

# 写的性能很差

# 根本写不进去

一 HBase写入性能优化

1.1 是否需要写WAL? WAL是否需要同步写？

WAL机制可以确保数据即使写入缓存的数据丢失了，也可以恢复；另外是为了集群之间的异步复制。默认WAL机制开启，且使用同步机制写入WAL. 我们可以考虑是否需要写入WAL,通常大多数企业业务都会开启，但是对于部分业务可能并不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，不能造成数据队列堵塞。这种场景可以选择关闭WAL写入；或者看能否接受异步写入

所以应该根据业务关注点在WAL机制和写入吞吐量之间做一个抉择

 

1.2 PUT是否可以同步批量提交

HBase分别提供了单条put以及批量put的API接口，使用批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能。另外需要注意的是，批量put请求要么全部成功返回，要么抛出异常。

所以建议使用批量PUT写入请求

 

1.3 PUT是否可以异步批量提交

业务如果可以接受异常情况下少量数据丢失的话，还可以使用异步批量提交的方式提交请求。提交分为两阶段执行：用户提交写请求之后，数据会写入客户端缓存，并返回用户写入成功；当客户端缓存达到阈值（默认2M）之后批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。

 

所以在业务可以接受的情况下开启异步批量提交

1.4 Region数量少于RegionServer数量

当前集群中表的Region个数如果小于RegionServer个数,可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度，如果Num(Region of Table) > Num(RegionServer)，再增加Region个数效果并不明显

 

所以在Num(Region of Table) <Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer

 

1.5 写入请求是否均衡

另一个需要考虑的问题是写入请求是否均衡，如果不均衡，一方面会导致系统并发度较低，另一方面也有可能造成部分节点负载很高，进而影响其他业务。分布式系统中特别害怕一个节点负载很高的情况，一个节点负载很高可能会拖慢整个集群，这是因为很多业务会使用Mutli批量提交读写请求，一旦其中一部分请求落到该节点无法得到及时响应，就会导致整个批量请求超时。

 

所以建议检查Rowkey和预分区策略

 

1.6 写入的KeyValue数据是否太大

KeyValue大小对写入性能的影响巨大，一旦遇到写入性能比较差的情况，需要考虑是否由于写入KeyValue数据太大导致。KeyValue大小对写入性能影响曲线图如下：

KeyValue太大会导致HLog文件写入频繁切换、flush以及compaction频繁触发，写入性能急剧下降。

如果是大字段scan导致RegionServer宕机，那么客户端在访问的时候对返回结果大小做限制(scan.setMaxResultSize(2*1024*1024))，并且对列数量做限制(scan.setBatch(100))

   

二 写异常问题

2.1 MemStore相关的配置是否合理

以RegionServer级别flush进行解析，HBase设定一旦整个RegionServer上所有Memstore占用内存大小总和大于配置文件中upperlimit时，系统就会执行RegionServer级别flush，flush算法会首先按照Region大小进行排序，再按照该顺序依次进行flush，直至总Memstore大小低至lowerlimit

 

Region规模与Memstore总大小设置是否合理？如果RegionServer上Region较多，而Memstore总大小设置的很小（JVM设置较小或者upper.limit设置较小），就会触发RegionServer级别flush

 

列族是否设置过多，通常情况下表列族建议设置在1～3个之间，最好一个。如果设置过多，会导致一个Region中包含很多Memstore，导致更容易触到高水位upperlimit

 

2.2 Store中HFile数量是否大于配置参数blockingStoreFile

对于数据写入很快的集群，还需要特别关注一个参数：hbase.hstore.blockingStoreFiles，此参数表示如果当前hstore中文件数大于该值，系统将会强制执行compaction操作进行文件合并，合并的过程会阻塞整个hstore的写入。通常情况下该场景发生在数据写入很快的情况下，在日志中可以发现”Waited 3722ms on a compaction to clean up ‘too many store files“

 

参数设置是否合理？hbase.hstore.compactionThreshold表示启动compaction的最低阈值，该值不能太大，否则会积累太多文件，一般建议设置为5～8左右。hbase.hstore.blockingStoreFiles默认设置为7，可以适当调大一些。