HBase Architecture

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

管理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才能继续回到本地化。

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了，同样也会出现性能损耗问题，所以我们还是要规划好数据增长速率，观察好数据定期维护，按需分析是否要进一步分行手工将分区再分好，也或者是 更严重的是新建表，做好更大的预分区然后进行数据迁移。