因官方Book Performance Tuning部分章节没有按配置项进行索引，不能达到快速查阅的效果。所以我以配置项驱动，重新整理了原文，并补充一些自己的理解，如有错误，欢迎指正。

    配置优化

    zookeeper.session.timeout

     默认值：3分钟(180000ms)

     说明：RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.

     调优：

     这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。

     不过需要注意的是，对于一些Online应用，RegionServer的宕机到恢复时间本身就很短的(网络闪断，crash等故障，运维可快速介入)，如果调低timeout时间，会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了，当故障的RS快速恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。

    hbase.regionserver.handler.count

     默认值：10

     说明：RegionServer的请求处理IO线程数。

     调优：

     这个参数的调优与内存息息相关。

     较少的IO线程，适用于处理单次请求内存消耗较高的Big PUT场景(大容量单次PUT或设置了较大cache的scan，均属于Big PUT)或ReigonServer的内存比较紧张的场景。

     较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。

     这里需要注意的是如果server的region数量很少，大量的请求都落在一个region上，因快速充满memstore触发flush导致的读写锁会影响全局TPS，不是IO线程数越高越好。

     压测时，开启Enabling RPC-level logging，可以同时监控每次请求的内存消耗和GC的状况，最后通过多次压测结果来合理调节IO线程数。

     这里是一个案例 Hadoop and HBase Optimization for Read Intensive Search Applications，作者在SSD的机器上设置IO线程数为100，仅供参考。

    hbase.hregion.max.filesize

     默认值：256M

     说明：在当前ReigonServer上单个Reigon的大小，单个Region超过指定值时，这个Region会被自动split成更小的region。

     调优：

     小region对split和compaction友好，因为拆分region或compact小region里的storefile速度很快，内存占用低。缺点是split和compaction会很频繁。

     特别是数量较多的小region不停地split, compaction，会使响应时间波动很大，region数量太多不仅给管理上带来麻烦，甚至引发一些Hbase的bug。

     一般512以下的都算小region。

    大region，则不太适合经常split和compaction，因为做一次compact和split会产生较长时间的停顿，对应用的读写性能冲击非常大。此外，大region意味着较大的storefile，compaction时对内存也是一个挑战。

     当然，大region还是有其用武之地，你只要在某个访问量低峰的时间点统一做compact和split，大region就可以发挥优势了，毕竟它能保证绝大多数时间平稳的读写性能。

    既然split和compaction如此影响性能，有没有办法去掉？

     compaction是无法避免的，split倒是可以从自动调整为手动。

     只要通过将这个参数值调大到某个很难达到的值，比如100G，就可以间接禁用自动split(RegionServer不会对未到达100G的region做split)。

     再配合RegionSplitter这个工具，在需要split时，手动split。

     手动split在灵活性和稳定性上比起自动split要高很多，相反，管理成本增加不多，比较推荐online实时系统使用。

    内存方面，小region在设置memstore的大小值上比较灵活，大region则过大过小都不行，过大会导致flush时app的IO wait增高，过小则因store file过多读性能降低。

    hbase.regionserver.global.memstore.upperLimit/lowerLimit

    默认值：0.4/0.35

     upperlimit说明：hbase.hregion.memstore.flush.size 这个参数的作用是 当单个memstore达到指定值时，flush该memstore。但是，一台ReigonServer可能有成百上千个memstore，每个memstore也许未达到flush.size，jvm的heap就不够用了。该参数就是为了限制memstores占用的总内存。

     当ReigonServer内所有的memstore所占用的内存综合达到heap的40%时，HBase会强制block所有的更新并flush这些memstore以释放所有memstore占用的内存。

     lowerLimit说明： 同upperLimit，只不过当全局memstore的内存达到35%时，它不会flush所有的memstore，它会找一些内存占用较大的memstore，个别flush，当然更新还是会被block。lowerLimit算是一个在全局flush前的补救措施。可以想象一下，如果memstore需要在一段时间内全部flush，且这段时间内无法接受写请求，对HBase集群的性能影响是很大的。

     调优：这是一个Heap内存保护参数，默认值已经能适用大多数场景。它的调整一般是为了配合某些专属优化，比如读密集型应用，将读缓存开大，降低该值，腾出更多内存给其他模块使用。

     这个参数会给使用者带来什么影响？

     比如，10G内存，100个region，每个memstore 64M，假设每个region只有一个memstore，那么当100个memstore平均占用到50%左右时，就会达到lowerLimit的限制。假设此时，其他memstore同样有很多的写请求进来。在那些大的region未flush完，就可能又超过了upperlimit，则所有region都会被block，开始触发全局flush。

    hfile.block.cache.size

    默认值：0.2

     说明：storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。

     调优：当然是越大越好，如果读比写少，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认吧。设置这个值的时候，你同时要参考 hbase.regionserver.global.memstore.upperLimit ，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。

    hbase.hstore.blockingStoreFiles

    默认值：7

     说明：在compaction时，如果一个Store?oulmn Family)内有超过7个storefile需要合并，则block所有的写请求，进行flush，限制storefile数量增长过快。

     调优：block请求会影响当前region的读写性能，将值设为单个region可以支撑的最大store file数量会是个不错的选择。最大storefile数量可通过region size/memstore size来计算。如果你将region size设为无限大，那么你需要预估一个region可能产生的最大storefile数。

    hbase.hregion.memstore.block.multiplier

    默认值：2

     说明：当一个region里的memstore超过单个memstore.size两倍的大小时，block该region的所有请求，进行flush，释放内存。虽然我们设置了memstore的总大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个100M的数据或写请求量暴增，最后一秒钟put了1万次，此时memstore的大小会瞬间暴涨到超过预期的memstore.size。这个参数的作用是当memstore的大小增至超过memstore.size时，block所有请求，遏制风险进一步扩大。

     调优： 这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控，那么保持默认值即可。如果正常情况下，你的写量就会经常暴增，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBase server OOM。

    其他

    启用LZO压缩

     LZO对比Hbase默认的GZip，前者性能较高，后者压缩比较高，具体参见 Using LZO Compression 。对于想提高HBase读写性能的开发者，采用LZO是比较好的选择。对于非常在乎存储空间的开发者，则建议保持默认。

    不要在一张表里定义太多的Column Family

    Hbase目前不能良好的处理超过2-3个CF的表。因为某个CF在flush发生时，它邻近的CF也会因关联效应被触发flush，最终导致系统产生很多IO。

    批量导入

    在批量导入数据到Hbase前，你可以通过预先创建region，来平衡数据的负载。详见 Table Creation: Pre-Creating Regions

    Hbase客户端优化

    AutoFlush

    将HTable的setAutoFlush设为false，可以支持客户端批量更新。即当Put填满客户端flush缓存时，才发送到服务端。

     默认是true。

    Scan Caching

    scanner一次缓存多少数据来scan(从服务端一次抓多少数据回来scan)。

     默认值是 1，一次只取一条。

    Scan Attribute Selection

    scan时建议指定需要的Column Family，减少通信量，否则scan默认会返回整个row的所有数据(所有Coulmn Family)。

    Close ResultScanners

    通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题。

    Optimal Loading of Row Keys

    当你scan一张表的时候，返回结果只需要row key(不需要CF, qualifier,values,timestaps)时，你可以在scan实例中添加一个filterList，并设置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。这样可以减少网络通信量。

    Turn off WAL on Puts

    当Put某些非重要数据时，你可以设置writeToWAL(false)，来进一步提高写性能。writeToWAL(false)会在Put时放弃写WAL log。风险是，当RegionServer宕机时，可能你刚才Put的那些数据会丢失，且无法恢复。

    启用Bloom Filter

    Bloom Filter通过空间换时间，提高读操作性能。

    转载请注明原文链接：http://kenwublog.com/hbase-performance-tuning

建议继续学习：

1. HBase集群出现NotServingRegionException问题的排查及解决方法    (阅读：16084)
2. HFile存储格式    (阅读：14399)
3. hbase运维    (阅读：13591)
4. hbase介绍    (阅读：10824)
5. Linux常用性能调优工具索引    (阅读：7693)
6. HBase技术介绍    (阅读：6562)
7. HBase随机写以及随机读性能测试    (阅读：6400)
8. HBase性能优化方法总结    (阅读：5719)
9. HBase二级索引与Join    (阅读：5622)
10. HBase Thrift 接口使用注意事项    (阅读：5271)