一、设计原则
1.行键设计
1)行键在设计的时候尽量的散列,例如可以考虑使用哈希、加密算法等使结果散列,这样能保证请求不会集中打到同一个HRegionServer上
2)行键设计最好有意义,如果行键真的完全随机,会增加查询难度。可以这么设计,例如:订单的行键可以设计为 hash订单编号得到的随机数 + 订单编号,订单编号是唯一的 => hash订单编号得到的随机数 + 订单编号也是唯一的
3)行键在使用的时候要保证唯一
2.列族设计
1)在HBase中虽然理论上不限制列族的数量,但在实际过程中,一个表的列族数量一般不要超过3个
2)在设计列族的时候,要尽量将具有相同特性的数据或者经常一起使用的数据放在一个列族中,尽量避免跨列族查询(因为跨列族查询要查询多个HStore,一个列族对应着一个HStore)
二、优化
1.调节DataBlock的大小。小的DataBlock利于Get查询,大的DataBlock利于Scan遍历。在建表的时候,就可以根据业务场景来确定DataBlock的大小。例如:
create 'person', {NAME => 'basic', BLOCKSIZE = '32768'}
2.关闭BlockCache。如果HBase的遍历偏多,此时没有必要将数据放到度缓存中,此时可以考虑关闭BlockCache(因为缓存的空间差不多没有的时候,会清空比较旧的比较少读的数据)
create 'person', {NAME => 'basic', BLOCKCACHE = 'false'}
alert 'person', {NAME => 'basic', BLOCKCACHE = 'false'}
3.更改BloomFilter的级别。BloomFilter支持三种方式:NONE,ROW,ROWCOL
- NONE:不适用BloomFilter,如果节点硬件性能一般,可以考虑关闭BloomFilter
- ROW:对行键进行过滤(HBASE默认是这个)
- ROWCOL表示对行键,列族和列同时进行过滤,如果节点硬件性能好,可以使用这个值
4.开启数据压缩机制。如果HBase占用大量的HDFS空间,那么可以考虑对HBase数据进行压缩。通过COMPERSSION属性来修改,支持NONE,LZO,SNAPPY和GZIP。其中NONE表示不压缩,HBase默认不对数据压缩。
5.在查询的时候能写具体就具体,类似于select * 和 select 具体的字段一样,一可以减少查询的压力,二是减少网络传输的压力,例如:
get 'person', 'p1', 'basic:name'
6.如果数据量较大,那么在读写的时候可以考虑使用批量读写
7.关闭WAL。如果想要提高写入效率,又能够容忍一定的数据丢失,那么可以考虑关闭WAL
8.预创建HRegion。当HRegion管理的数据比较多(默认是10G)的时候,会进行分裂。HRegion的分裂比较花费时间。因此在能够提前预估数据量的前提下,可以考虑在建表的时候就构建多个HRegion。例如
hbase org.apache.hadoop.hbase.util.RegionSplitter person
HexStringSplit -c 15 -f basic
9.调整Zookeeper的有效Session时长。默认情况下,HMaster和Zookeeper之间通过心跳来保证联系,心跳间隔时间默认是180s即3min,也就是意味着HMaster每隔3min会给Zookeeper发送一次心跳。如果HMaster产生了故障,那么可能Zookeeper需要3min之后才能发现故障。在业务高峰期,HBase有3min不能使用,此时会造成大量损失。解决方案是可以将这个时长调小一点,通过属性zookeeper.session.timeout来调节,单位是秒,放在hbase-site.xml中。