架构分析

HBase Architecture

HBase 采用 Master/Slave 架构搭建集群,它隶属于 Hadoop 生态系统,由一下类型节点组成:HMaster 节点、 HRegionServer 节点、ZooKeeper 集群,而在底层,它将数据存储于 HDFS 中,因而涉及到 HDFS 的 NameNode、 DataNode 等,总体结构如下: 其中HMaster 节点用于:

管理HRegionServer,实现其负载均衡。
管理和分配HRegion,比如在HRegion split时分配新的HRegion;在HRegionServer退出时迁移其内的HRegion到其他HRegionServer上。
实现DDL操作(Data Definition
Language,namespace和table的增删改,column
familiy的增删改等)。
管理namespace和table的元数据(实际存储在HDFS上)。
权限控制(ACL)。

HRegionServer 节点用于:

存放和管理本地HRegion。
读写HDFS,管理Table中的数据。
Client直接通过HRegionServer读写数据(从HMaster中获取元数据,找到RowKey所在的HRegion/HRegionServer后)。

ZooKeeper 集群是协调系统,用于:

存放整个
HBase集群的元数据以及集群的状态信息。
实现HMaster主从节点的failover。

HBase Client 通过 RPC 方式和 HMaster、HRegionServer 通信;一个 HRegionServer 可以存放 1000 个 HRegion;底层 Table 数据存储于 HDFS 中,而 HRegion 所处理的数据尽量和数据所在的 DataNode 在一起,实现数据的本地化;数据本地化并不是总能实现,比如在 HRegion 移动 ( 如因 Split) 时,需要等下一次 Compact 才能继续回到本地化。

Reference

HFile

HFile 数据格式中的 Data 字段用于存储实际的 KeyValue 数据,MetaIndex 字段用于 Meta 块的起始点,Magic 字段用于存储随机数,防止数据被破坏。而 HFile 中的 KeyValue 数据格式中的 Key 应该是 byte[] 数组,Value 部分是二进制数据。

预分区

HBase中,表会被划分为1...n个Region,被托管在RegionServer中。Region二个重要的属性:StartKey与 EndKey表示这个Region维护的rowKey范围,当我们要读/写数据时,如果rowKey落在某个start-end key范围内,那么就会定位到目标region并且读/写到相关的数据。简单地说,有那么一点点类似人群划分,1-15岁为小朋友,16-39岁为年轻 人,40-64为中年人,65岁以上为老年人。(这些数值都是拍脑袋出来的,只是举例,非真实),然后某人找队伍,然后根据年龄,处于哪个范围,就找到它 所属的队伍。 : ( 有点废话了。。。。
然后,默认地,当我们只是通过HBaseAdmin指定TableDescriptor来创建一张表时,只有一个region,正处于混沌时 期,start-end key无边界,可谓海纳百川。啥样的rowKey都可以接受,都往这个region里装,然而,当数据越来越多,region的size越来越大时,大到 一定的阀值,hbase认为再往这个region里塞数据已经不合适了,就会找到一个midKey将region一分为二,成为2个region,这个过 程称为分裂(region-split).而midKey则为这二个region的临界,左为N无下界,右为M无上界。< midKey则为阴被塞到N区,> midKey则会被塞到M区。
如何找到midKey?涉及的内容比较多,暂且不去讨论,最简单的可以认为是region的总行数 / 2 的那一行数据的rowKey.虽然实际上比它会稍复杂点。
如果我们就这样默认地,建表,表里不断地Put数据,更严重的是我们的rowkey还是顺序增大的,是比较可怕的。存在的缺点比较明显。
首先是热点写,我们总是会往最大的start-key所在的region写东西,因为我们的rowkey总是会比之前的大,并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中。
其次,由于写热点,我们总是往最大start-key的region写记录,之前分裂出来的region不会再被写数据,有点被打进冷宫的赶脚,它们都处于半满状态,这样的分布也是不利的。
如果在写比较频率的场景下,数据增长快,split的次数也会增多,由于split是比较耗时耗资源的,所以我们并不希望这种事情经常发生。
............
看到这些缺点,我们知道,在集群的环境中,为了得到更好的并行性,我们希望有好的load blance,让每个节点提供的请求处理都是均等的。我们也希望,region不要经常split,因为split会使server有一段时间的停顿,如何能做到呢?

随机散列与预分区。二者结合起来,是比较完美的,预分区一开始就预建好了一部分 region, 这些 region 都维护着自已的 start-end keys,再配合上随机散列,写数据能均等地命中这些预建的 region,就能解决上面的那些缺点,大大地提高了性能。提供 2 种思路 : hash 与 partition. 一、hash 就是 rowkey 前面由一串随机字符串组成 , 随机字符串生成方式可以由 SHA 或者 MD5 等方式生成,只要 region 所管理的 start-end keys 范围比较随机,那么就可以解决写热点问题。 long currentId = 1L; byte [] rowkey = Bytes.add(MD5Hash.getMD5AsHex(Bytes.toBytes(currentId)).substring(0, 8).getBytes(), Bytes.toBytes(currentId));

假设 rowKey 原本是自增长的 long 型,可以将 rowkey 转为 hash 再转为 bytes,加上本身 id 转为 bytes, 组成 rowkey,这样就生成随便的 rowkey。那么对于这种方式的 rowkey 设计,如何去进行预分区呢? 1. 取样,先随机生成一定数量的 rowkey, 将取样数据按升序排序放到一个集合里 2. 根据预分区的 region 个数,对整个集合平均分割,即是相关的 splitKeys. 3.HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys) 可以指定预分区的 splitKey,即是指定 region 间的 rowkey 临界值 .

以上,就已经按hash方式,预建好了分区,以后在插入数据的时候,也要按照此rowkeyGenerator的方式生成rowkey,有兴趣的话,也可以做些试验,插入些数据,看看数据的分布。
二、partition故名思义,就是分区式,这种分区有点类似于mapreduce中的partitioner,将区域用长整数(Long)作为分区号,每个region管理着相应的区域数据,在rowKey生成时,将id取模后,然后拼上id整体作为rowKey.这个比较简单,不需要取 样,splitKeys也非常简单,直接是分区号即可。直接上代码吧:

calcSplitKeys 方法比较单纯,splitKey 就是 partition 的编号 , 我们看看测试类 : Java 代码 收藏代码

通过partition实现的loadblance写的话,当然生成rowkey方式也要结合当前的region数目取模而求得,大家同样也可以做些实验,看看数据插入后的分布。

在这里也顺提一下,如果是顺序的增长型原 id, 可以将 id 保存到一个数据库,传统的也好 ,redis 的也好,每次取的时候,将数值设大 1000 左右,以后 id 可以在内存内增长,当内存数量已经超过 1000 的话,再去 load 下一个,有点类似于 oracle 中的 sqeuence.

随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的,随着时间不断地推移,已经分好的区域,或许已经装不住更多的数据,当然就要进一步进行 split了,同样也会出现性能损耗问题,所以我们还是要规划好数据增长速率,观察好数据定期维护,按需分析是否要进一步分行手工将分区再分好,也或者是 更严重的是新建表,做好更大的预分区然后进行数据迁移。