关于HBase表的设计原则小结

前言: 这里是关于如何设计HBase表的一个小结

• 关于HBase表的设计,应该从以下几点出发: 设计名称空间(namespace)丶设计表(相当于region)丶设计列簇丶设计列丶版本设计丶压缩设计以及如何设计rowkey.

1.名称空间的设计

• 在HBase中名称空间类似于RDBMS中的数据库,在HBase中往往不同的的业务的数据需要存储在不同的的表中,为了管理的方便,不同业务域按照不同的namespace来划,
• HBase在安装好后有两个名称空间,一个defalut,创建表时默认都在此namespace下. 还有一个[HBase],用于存放系统的内建表(namespace丶meta).

语法:

1. 创建 create_namespace '名称空间名字'
	create_namespace 't1'      --在HBase shell中, 可以crate  tab键查看提示

2. 查看名称空间列表
	list_namespace
	
3. 查看名称空间描述
	describe_namespace '名称空间名字'

4. 命名空间创建表  create '名称空间:表名','列簇'
	create 't1:student','C1'
 
5. 删除名称空间  必须要先删除里面的表
	drop_namespace '名称空间'
	drop_namespace 't1'
	

HBase上可以看见:

HDFS上看见:

2.列簇的设计

原则 能用一个列簇解决的不用两个.

好处:

• 1. 减少IO的开销,列簇多影响性能
• 2. 列簇所储存的数据到达flush刷新的阈值时,表中所有的列簇都会刷新

3.数据压缩

速度快的压缩占比高丶速度压缩占比低,根据自己的业务选择合适的压缩方式

• HBase设置数据设置数据压缩:

1. 创建新的表，并指定数据压缩算法   COMPRESSION => "GZ"  --GZIP的压缩方式

create "t1:student", {NAME => "C1", COMPRESSION => "GZ"}

2.修改已有的表，并指定数据压缩算法
alter "t1:student", {NAME => "C1", COMPRESSION => "GZ"}

• 在HBase的webUI界面查看表可以发现指定了压缩格式:
  

4.rowkey的设计

• Hbase创建一个表，这个表默认只有1个Region(相当于RDBMS中的表)，而一个Region仅仅被一个RegionServer管理，这种情况如果出现大量的写入操作以及读取操作，都去操作这个表，而这个表只有一个Region，此时这个RegionServer面临高并发读写(就是region容易出现热点问题)，此时容易导致服务器宕机。

- 解决:

引入预分区,就是根据rowkey划分预分区.
本质: 就是在创建表之前划分多个region,分为手动预分区和基于分区策略.

4.1. 指定 start key、end key来分区

语法: create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']
	或者 在hbase shell中  help 'create'也可以看见
	
create 'namespace','表名',SPLITS => ['10', '20', '30', '40']

create 't', 'student', SPLITS => ['10', '20', '30', '40']

• 观察 HDFS:
  
• 观察 HBase
  
  负无穷 ~10, 10-20 ,20-30 , 30-40, 40-正无穷 5个分区

4.2 指定分区数量、分区策略

create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
这个以 16进制分区,共分为 15个区

分区策略:

• HexStringSplit: ROWKEY是十六进制的字符串作为前缀的

• DecimalStringSplit: ROWKEY是10进制数字字符串作为前缀的

• UniformSplit: ROWKEY前缀完全随机

• 查看HBase :
  

4.3 预分区问题思考?

问题: 预分区一定能够解决region的热点问题吗? 答案肯定是不一定的.

• 如果数据还是大量重复的数据可能还是会往同一个Region中写入，所以预分区只能够解决Region分布问题，但是如果在写入的时候没有很好的rowkey的设计，还是会出现相同的rowkey的数据放在同一个region中，还是会造成region热点。

HBase的官方设计原则:

• 1-顺序原则：尽量避免rowkey的顺序-递增行键/时序数据(时间序列型数据–156666)

• 2-长度原则：ROWKEY的最大长度是64KB，建议越短越好。10-100长度即可

• 3-类型原则：使用long等类型比String类型更省空间

• 4-唯一原则：rowkey设计唯一的

• rowkey设计
  1 反转策略:
  
  2 加盐策略
  
  3 哈希策略
  

完整设计: