每天一点进步：hbase预分区和压缩

一, rowkey是hbase的key-value存储中的key，通常使用用户要查询的字段作为rowkey，查询结果作为value。可以通过设计满足几种不同的查询需求。
      (1)数字rowkey的从大到小排序：原生hbase只支持从小到大的排序，这样就对于排行榜一类的查询需求很尴尬。那么采用rowkey
= Integer.MAX_VALUE-rowkey的方式将rowkey进行转换，最大的变最小，最小的变最大。在应用层再转回来即可完成排序需求。
      (2)rowkey的散列原则：如果rowkey是类似时间戳的方式递增的生成，建议不要使用正序直接写入rowkey，而是采用reverse的方式反转rowkey（例如：query_item将cust_id反转作为前缀），使得rowkey大致均衡分布，这样设计有个好处是能将regionserver相对负载均衡，否则容易产生所有新数据都在一个regionserver上堆积的现象，这一点还可以结合table的预切分一起设计。
 

二，columnfamily

当一个columnfamily有大量的数据的时候会触发整个region里面的其他column
family的memstore（其实这些memstore可能仅有少量的数据，还不需要flush的）也发生flush动作；另外compaction触发的条件是当store
file的个数（不是总的store file的大小）达到一定数量的时候会发生，而flush产生的大量store
file通常会导致compaction，flush/compaction会发生很多IO相关的负载，这对Hbase的整体性能有很大影响，所以选择合适的column
family个数尽量少。目前Hbase并不能很好的处理超过2~3个columnfamily的表。

 

三，预分配region

在创建一个表时如果不指定预分配region，则默认会先分配一个region，这样在大数据并行载入时性能很低，因为所有的数据都往一个region写入，容易引起单节点负载升高，从而影响入库性能，一个好的方法是在建立表时预先分配数个region。

预分配region方法有两种方式

    a,使用RegionSplitter方法（同时创建表），

       首先使用RegionSplitter建表，预分配region，例如建立一个query_item表，列簇为cri，预分配10个region，

hbaseorg.apache.hadoop.hbase.util.RegionSplitter -c 10 -f cri test6

 

       b,可以直接在建表时直接使用预分配regions：

       create 'test6','cri',SPLITS=>['1','2','3','4','5','6','7','8','9']

      

四，指定压缩格式

 压缩算法： snappy算法，相对lzo来说，压缩率接近，压缩效率稍高，解压效率高很多。      

alter 'test6',NAME => 'cri', COMPRESSION => 'snappy'

 

 

【备注】：完整的创建语句为：create 'test6', {NAME => 'cri', VERSIONS=>1,COMPRESSION => 'snappy'},{SPLITS=> ['1','2','3','4','5','6','7','8','9']}