Hadoop HBase性能优化学习

一、调整参数

入门级的调优可以从调整参数开始。投入小，回报快。

1. Write Buffer Size
快速配置

HTable htable = new HTable(config, tablename);   
htable.setWriteBufferSize(6 * 1024 * 1024);  
htable.setAutoFlush(false);

  
设置buffer的容量，例子中设置了6MB的buffer容量。
* 必须禁止auto flush。
* 6MB是经验值，可以上下微调以适应不同的写场景。

原理
HBase Client会在数据累积到设置的阈值后才提交Region Server。这样做的好处在于可以减少RPC连接次数。同时，我们得计算一下服务端因此而消耗的内存：hbase.client.write.buffer * hbase.regionserver.handler.count。在减少PRC次数和增加服务器端内存之间找到平衡点。

2. RPC Handler
快速配置
修改hbase-site.xml的hbase.regionserver.handler.count配置项：

<property>  
<name>hbase.regionserver.handler.count</name>  
<value>100</value>  
</property> 

原理
该配置定义了每个Region Server上的RPC Handler的数量。Region Server通过RPC Handler接收外部请求并加以处理。所以提升RPC Handler的数量可以一定程度上提高HBase接收请求的能力。当然，handler数量也不是越大越好，这要取决于节点的硬件情况。

3. Compression 压缩
快速配置

HColumnDescriptor hcd = new HColumnDescriptor(familyName);   
hcd.setCompressionType(Algorithm.SNAPPY);  

原理
数据量大，边压边写也会提升性能的，毕竟IO是大数据的最严重的瓶颈，哪怕使用了SSD也是一样。众多的压缩方式中，推荐使用SNAPPY。从压缩率和压缩速度来看，性价比最高。

4. WAL
快速配置

Put put = new Put(rowKey);  
put.setWriteToWAL(false);

 

原理
其实不推荐关闭WAL，不过关了的确可以提升性能...因为HBase在写数据前会先写WAL，以保证在异常情况下，HBase可以按照WAL的记录来恢复还未持久化的数据。

5. Replication
虽然推荐replica=3，不过当数据量很夸张的时候，一般会把replica降低到2。当然也不推荐随便降低replica。

6. Compaction
在插数据时，打开HMaster的web界面，查看每个region server的request数量。确保大部分时间，写请求在region server层面大致平均分布。

在此前提下，我们再考虑compaction的问题。继续观察request数量，你会发现在某个时间段，若干region server接收的请求数为0（当然这也可能是client根本没有向这个region server写数据，所以之前说，要确保请求在各region server大致平均分布）。这很有可能是region server在做compaction导致。compaction的过程会block写。

优化的思路有两种，一是提高compaction的效率，二是减少compaction发生的频率。

提高以下两个属性的值，以增加执行compaction的线程数：

hbase.regionserver.thread.compaction.large  
hbase.regionserver.thread.compaction.small  

推荐设置为2。

7. 减少Region Split次数
region split是提升写性能的一大障碍。减少region split次数可以从两方面入手，一是预分配region(该内容会在下章节表设计优化里详述)。其二是适当提升hbase.hregion.max.filesize

提升region的file容量也可以减少split的次数。具体的值需要按照你的数据量，region数量，row key分布等情况具体考量。一般来说，3~4G是不错的选择。

8. HFile format version
0.92.0后的version都应该是2。v2比v1支持更大的region大小。一般经验是Region越大越少，性能更好(当然也不能过分大，否则major compaction的时候时间长的吃不消)。所以推荐把hfile.format.version改成2，并提高hfile大小。对于使用v1 format的用户，不用担心，数据迁移到v2上是有工具的。具体参见HBASE-1621。

9. hbase.ipc.client.tcpnodelay
设置成True。关闭Nagle，可能提高latency。当然HDFS也关掉TPC Nagle。

二、表设计优化
1. 预分配Region
之前有说防止region split的两大手段其中之一就是预分配region。

在此不重复region split的原理，请参见http://blog.sina.com.cn/s/blog_9cee0fd901018vu2.html。按数据量，row key的规则预先设计并分配好region，可以大幅降低region split的次数, 甚至不split。这点非常重要。

2. Column Family的数量
实测发现column family的数量对性能会有直接影响。建议减少column family的数量。单个cf是最好

3. Column Family MAX_VERSIONS/MAX_LENGTH
前者确定保存一个cell的最大历史份数，后者确定多少byte可以存进一个cell 历史记录。所以我们可以减低这些值。

4. Row Key的设计
Region的数据边界是start key和end key。如果记录的row key落在某个region的start key和end key的范围之内，该数据就会存储到这个region上。在写数据的时候，尤其是导入客户原有数据的时候，如果row key设计不当，很可能导致性能问题。之前我们也介绍了row key和region的关系。如果在某个时段内，很多数据的row key都处在某个特定的row key范围内。那这个特定范围row key对应的region会非常繁忙，而其他的region很可能非常的空闲，导致资源浪费。

那么，如何设计row key呢？举个比较实际的例子，如果有张HBase表来记录每天某城市的通话记录， 常规思路下的row key是由电话号码 + yyyyMMddHHmmSS(通话开始时间) + ... 组成。按电话号码的规律来划分region。但是这样很容易导致某时段row key极其不均匀(因为电话通话呈随机性)。但是，如果把电话号码倒序，数据在region层面的分布情况就大有改观。

设计row key的方法千变万化，宗旨只有一条，尽量保证单位时间内写入数据的row key对于region呈均匀分布。