默认情况下,每个Table只有一个Region。随着数据的不断写入,Region会自动进行拆分,拆分后的Region会被分配到其他RegionServer上,实现HBase的负载均衡。
- HBase已经有6种Split触发策略,常见的Split策略如下:
-
如果知道hbase数据表的key的分布情况,就可以在建表的时候对hbase进行region的预分区。这样做的好处是防止大数据量插入的热点问题,提高数据插入的效率。
-
HBase中的表,支持十亿行 * 百万列 * 千版本
-
TTL是作用于列族的,它设置了一个基于时间戳的临界值, 内部的管理会自动检查TTL值是否达到上限,在major合并过程中时间戳被判定为超过TTL的数据会被自动删除。
- 即使超过TTL设置,依然要保留最小版本数相应的版本个数
HBase也有一种机制可以将列当作计数器。否则,如果用户需要对一行数据加锁,然后读取数据,再对当前数据做加法,最后写回 HBase并释放该行锁,从而其他写程序可以访问该行数据。这样做会引起大量的资源竞争问题,尤其是当客户端进程崩溃之后,尚未释放的锁需要等待超时恢复——这会在一个高负载的系统中引起灾难性的后果。
计数器是面向列的操作,即每次对特定计数器的操作只会锁住一列而不是一行,然后读取数据,再对当前数据做加法操作,最后再写入HBase中并释放该列的锁,在操作的过程中用户是可以访问这一行的其他数据的
- 增加值和对计数器产生的作用:
-
单计数器顾名思义就是一次操作只能操作一个计数器,用户需要自己设置列,方法由HTable类提供 单计数器每一次只允许操作一个计数器,如果一行中多个列都是计数器则需要将代码重复编写,因此HBase的HTable类提供了另外一个方法,可以一次操作同一行的多个计数器
- Rowkey 是一个二进制码流,Rowkey 的长度被很多开发者建议说设计在 10~100 个字节,不过建议是越短越好,不要超过 16 个字节,存为byte[]字节数组,一般设计成定长的。
- MemStore 将缓存部分数据到内存,如果 Rowkey 字段过长内存的有效利用率会降低, 系统将无法缓存更多的数据,这会降低检索效率。因此 Rowkey 的字节长度越短越好。
- 目前操作系统是都是 64 位系统,内存 8 字节对齐。控制在 16 个字节,8 字节的整数 倍利用操作系统的最佳特性。
- 如果 Rowkey 是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将 Rowkey 的高位作为散列字段,由程序循环生成,低位放时间字段,这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段,首字段直接是时间信息将产生所有 新数据都在一个 RegionServer 上堆积的热点现象,这样在做数据检索的时候负载将会集中
-
- 必须在设计上保证其唯一性。rowkey 是按照字典顺序排序存储的,因此,设计 rowkey 的时候,要充分利用这个排序的特点,将经常读取的数据存储到一块,将最近可能会被访问 的数据放到一块。
# 从快照复制生成一个新表 # 用快照恢复数据,它需要先禁用表,再进行恢复
- HBase作为MR的数据源,实现聚合操作
- HBase作为Hive的外表,实现离线分析