目前HBase已经运用于淘宝主搜索的全量和增量的数据存储，有效的减低的数据库的压力，增强了业务扩展的能力。Dump系统的特点是要求在短时间内处理大量数据，对延时要求高。在实施这个项目过程中，我们积累了一些优化的实践，抛砖引玉，供大家参考。

    环境：Hadoop CDH3U4 + HBase 0.92.1

    1、  尽可能用LZO

    数据使用LZO，不仅可以节省存储空间尤其是可以提高传输的效率，因为数据是在regionserver端作解压的。通过测试，可以明显提高HBASE从HDFS的读的性能。尽量不用GZ的方式，GZ的方式在bulkload时有线程安全问题。

    2、  根据场景调整Block size

    由于使用我们非常关注随机读的性能，一条记录的长度较小，通过设置blocksize=8k，可以提高随机读的性能。

    3、  在系统空闲的时候，启动major compaction

    在实际中，我们发现随着region不停的flush，hfile的增多会影响scan的性能，为了能控制影响，我们设置了hbase.hregion.majorcompaction为一个比较大的时间，通过另外的定时脚本在空闲的时候集中做各表的major compaction。这样可以保证scan的性能是平稳的。

    4、  调整balance策略

    我们采用了表级别的balance，但是上线后依旧发现有时scan，会抛timeout的异常。通过hmaster的日志，发现当hbase的表多并且当有regionserver挂掉的时候，表级别balance的策略会导致大面积的region移动。后来通过增加阈值控制，每次balance的时候，每张表的region移动的数量不超过整张表region数量的5%。

    5、  关注HDFS的问题

    当有regionserver挂掉后，有时split log会很慢，会超时导致master不停的重新resubmit split task，最终导致某些scan任务抛timeout异常。原因是datanode的连接数太多，具体原因是https://issues.apache.org/jira/browse/HDFS-3359 通过升级hdfs到HADOOP CDH3U4之后，问题解决。

    6、  注重rowkey设计

    使用hash值+具体的key，并且设置一个巨大的MAX_FILESIZE。固定每个region的范围，防止做split，防止split带来的隐患。

    7、  尽可能的用batch操作

    通过使用batch的方式，能提高近10倍的性能，使原本单条记录的随机读从20ms左右降至2ms左右，因为batch的内部是按regionserver来发送数据的，所以每次batch的List的大小，应设置成regionserver的若干倍。

    8、  如果可以的话，减少数据的versions

    由于我们业务只需要一个版本，设置version=1，可以有效的控制hfile的大小，从而控制scan的性能。

建议继续学习：

1. HBase集群出现NotServingRegionException问题的排查及解决方法    (阅读：16227)
2. HFile存储格式    (阅读：14539)
3. hbase运维    (阅读：13679)
4. hbase介绍    (阅读：11035)
5. HBase技术介绍    (阅读：6761)
6. HBase随机写以及随机读性能测试    (阅读：6492)
7. HBase性能优化方法总结    (阅读：5830)
8. HBase二级索引与Join    (阅读：5793)
9. HBase Thrift 接口使用注意事项    (阅读：5413)
10. Cassandra和HBase主要设计思路对比    (阅读：4140)