Hbase调优

Ps：这里列举一些常见的Hbase调优，并不全面，如果想要全面的了解hbase调优，可以参考Hbase的官方文档，或者参考这篇总结自官方的博客。

本文将从三个方面来对Hbase的调优进行总结：参数调优、表的设计、读取优化、写入优化。

目录

---

一、参数调优

---

1.zk超期参数

• zookeeper.session.timeout（默认3分钟）
• 这个是RegionServer与Zookeeper间的连接超时时间，当设置的更低的时候，可以减少因等待超时而被延长的failover时间，但是这个值必须要留足够的时间进行GC回收，否则会导致频繁额度RS宕机。一般取默认值。

2.RegionServer的请求处理IO线程数

• hbase.regionserver.handler.count
• 较少的IO线程，适用于处理单次请求内存消耗较高的场景。
• 较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。

3.ReigonServer上单个Reigon的最大存储空间

• hbase.hregion.max.filesize
• 小的Region：对split和compaction更加友好，因为拆分或者compact小Region里的storefile速度很快，内存占用低，缺点是split和compaction会很频繁，会导致集群响应时间波动很大，Region数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase的bug。
• 大的Region，则不太适合经常split和compaction，因为做一次compact和split会长生较长时间的停顿，对应用的读写性能冲击非常大。此外，大Region意味着较大的storefile，compact时对内存也是一个挑战。在访问量低的时候，做compact和split，既能顺利完成split和compaction，又能保证绝大多数时间平稳的读写性能。
• 优化时，可以把size设到一个很难达到的值，就可以间接禁用自动split，需要分割的时候，自己手动分割，这样灵活性和稳定性都要好很多，也会减少I/O负载。

4.单个region内所有的memstore大小总和被flush阈值

• hbase.hregion.memstore.flush.size
• hbase.regionserver.global.memstore.upperLimit/lowerLimit
• 单个region内所有的memstore大小总和超过指定值时，flush该region的所有memstore。
• 这里有个最大值，意思是超过这个值，就flush该region内所有memstore，这个参数是为了防止内存占用过大。
• 还有一个最小值的限制，如果所有menstore所占内存综合达到这个值，就会找一个memstore内存占用最大的region，做个别flush，这个是在所有region被强制flush前的一个补救措施

5.storefile的读缓存占用Heap的大小百分比

• hfile.block.cache.size
• 在偏向读的业务中，可以适当调大该值，需要注意的是，设置该值的时候还需要考虑一下 上一标题下的最大值（单个region内所有的memstore大小总和阈值最大值），如果两个值加起来超过80-90%，会有OOM（内存溢出）的风险。

6.每个列簇内storefile被compact的阈值

• hbase.hstore.blockingStoreFiles
• 在flush时，当一个region中的Store（Coulmn Family）内有超过7个storefile时，则block所有的写请求进行compaction，以减少storefile数量。
• block写请求会严重影响当前regionServer的响应时间，但过多的storefile也会影响读性能。从实际应用来看，为了获取较平滑的响应时间，可将值设为无限大。如果能容忍响应时间出现较大的波峰波谷，那么默认或根据自身场景调整即可。

7.memstore占用内存大小超过hbase.hregion.memstore.flush.size的倍数阈值

• hbase.hregion.memstore.block.multiplier
• 当一个region里总的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时，block该region的所有请求，进行flush，释放内存。

8.配置major合并的间隔时间

• hbase.hregion.majorcompaction
• minor：minor通常会把数个小的相邻的storeFile合并成一个大的storeFile，minor不会删除标示为删除的数据和过期的数据。
• major：major会删除需删除的数据，major合并之后，一个store只有一个storeFile文件，会对store的所有数据进行重写，有较大的性能消耗。
• 可以禁止自动的major合并，可以手动定期进行major合并。

9.开启mslab方案

• hbase.hregion.memstore.mslab.enabled
• 减少因内存碎片导致的Full GC，提高整体性能

10.JVM调整

• 内存大小：master默认为1G，可增加到2G，regionserver默认1G，可调大到10G，或者更大。
• 垃圾回收：

-Xmx8g -Xms8g -Xmn128M -XX:+UseParNewGC -XX:+UseConMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XLoggc:/logs/gc-hostname.log

其中：

-Xmx8g 最大堆内存8g

-Xms8g 初始堆内存设置与最大堆内存一样大。如果Xms设置得比较小，当遇到数据量较大时候，堆内存会迅速增长，当上升到最大又会回落，伸缩堆大小会带来压力。

-Xmn128M 新生代128M。新生代不能过小，否则新生代中的生存周期较长的数据会过早移到老生代，引起老生代产生大量内存碎片；新生代也不能过大，否则回收新生代也会造成太长的时间停顿，影响性能。

-XX:+UseParNewGC 新生代采用 ParallelGC 回收器。ParallelGC 将停止运行Java 进程去清空新生代堆，因为新生代很小，所以停顿的时间也很短，需几百毫秒。

-XX:+UseConMarkSweepGC 老生代采用CMS回收器(Concurrent Mark-Sweep Collector) . CMS 在不停止运行Java进程的情况下异步地完成垃圾回收，CMS会增加CPU的负载，但是可以避免重写老生代堆碎片时候的停顿。老生代回收不可使用 ParallelGC 回收机制，因为老生代的堆空间大，ParallelGC会造成Java进程长时间停顿，使得RegionServer与ZooKeeper的会话超时，该RegionServer会被误认为已经奔溃并会被抛弃。

-XX:CMSInitiatingOccupancyFraction=70 初始占用比为70%的时候开始CMS回收。此值不能太小，否则CMS发生得太频繁。此值不能太大，否则因为CMS需要额外堆内存，会发生堆内存空间不足，导致CMS 失败。

二、表的设计

---

1.预分配Region

• 默认情况下，在创建HBase表的时候会自动创建一个Region分区，当导入数据的时候，所有的HBase客户端都向Region写数据，知道这个Region足够大才进行切分，一种可以加快批量写入速度的方法是通过预先创建一些空的Regions，这样当数据写入HBase的时候，会按照Region分区情况，在进群内做数据的负载均衡。

2.Rowkey优化

• Region的数据边界是start key和end key。如果记录的row key落在某个region的start key和end key的范围之内，该数据就会存储到这个region上。
• 设计row key的方法千变万化，宗旨只有一条，尽量保证单位时间内写入数据的row key对于region呈均匀分布。
• 常见的方式有，把字符串倒过来、在rowkey前面加上hash值。

3.Column Family的数量

• 不要在一张表中定义太多的column family。目前HBase并不能很好的处理超过2-3个column family的表，因为某个column family在flush的时候，它临近的column family也会因关联效应被触发flush，最终导致系统产生更过的I/O。
• 实测发现column family的数量对性能会有直接影响。建议减少column family的数量。

4.In Memory设置

• 创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。

5.版本数限制

• 创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，对于一些不是特别重要的数据，可以设置setMaxVersions(1)。

6.数据生命周期限制

• 创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除，例如如果只需要存储最近两天的数据，那么可以设置setTimeToLive(2 * 24 * 60 * 60)。

7.采用压缩

• 压缩需要根据实际业务和机器性能来衡量是否要采用牺牲CPU来换取存储上的节约，并且能节省I/O和网络开销，可以使用Lzo或Snappy压缩的方式，大致可以压缩4~5倍。

三、读取优化

---

1.扫描缓存

• 在进行扫描时可以设置一次读取多条，缓存数据，减少I/O开销。

2.扫描制定列

• Scan时指定需要的Column Family，可以减少网络传输数据量，否则默认scan操作会返回整行所有Column Family的数据。

3.释放资源

• 通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题（对应的Server资源无法释放）。

4.批量读

• 通过调用HTable.get(Get)方法可以根据一个指定的row key获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List)方法可以根据一个指定的row key列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高而且网络传输RTT高的情景下可能带来明显的性能提升。

5.多线程并发读

• 多个线程同时进行读操作

6.缓存查询结果

• 对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑LRU等常用的策略。

7.Blockcache

• 读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后，会启动淘汰机制，淘汰掉最老的一批数据。

四、写入优化

---

1.Auto Flush

• 通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求。默认情况下auto flush是开启的。

2.Write Buffer

• 通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte字节数，可以根据实际写入数据量的多少来设置该值。
• 需要关闭Auto Flush

3.WAL Flag

• 在HBae中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会先写WAL（Write Ahead Log）日志（即HLog，一个RegionServer上的所有Region共享一个HLog），只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功；如果写WAL日志失败，客户端则被通知提交失败。这样做的好处是可以做到RegionServer宕机后的数据恢复。
• 对于不太重要的数据，可以选择放弃写入WAL日志。

4.批量写

• 通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase，同样HBase提供了另一个方法：通过调用HTable.put(List)方法可以将指定的row key列表，批量写入多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高，网络传输RTT高的情景下可能带来明显的性能提升。

5.多线程并发写

• 在客户端开启多个HTable写线程，每个写线程负责一个HTable对象的flush操作，这样结合定时flush和写buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被flush（如1秒内），同时又保证在数据量大的时候，写buffer一满就及时进行flush。