目前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<Row>的大小，应设置成regionserver的若干倍。
8、 如果可以的话，减少数据的versions
由于我们业务只需要一个版本，设置version=1，可以有效的控制hfile的大小，从而控制scan的性能。