大数据技术之HBase（四）RowKey设计原则及方法

一、RowKey设计（HBase表格的设计）

1、HBase的表格可以按照MySQL的表格进行相同的设计方案。MySQL在表格设计时有行有列，HBase同样也能实现相同的功能。但是这种使用方法的性能不会很高，所以不推荐使用。

2、TSDB( TimeStamp DataBase )：时间戳数据库。MySQL数据库中的字段能够修改，但是在MySQL中数据一旦发生修改，修改之前的数据就无法保存，相当于数据被删除。TSDB倾向于使用多行，把时间写到行号RowKey里。

这么做的好处在于：可以记录下值value一直以来的变化情况。

        一条数据的唯一标识就是rowkey，那么这条数据存储再哪个分区，取决于rowkey处于哪一个预分区的区间内。

        从更大的角度来看，数据将被写入整个集群的多个区域，而不是一次写入一个区域。设计rowkey主要是为了让数据均匀的分布于所有的region中，防止数据倾斜。

二、RowKey设计原则

1. 长度原则

        rowkey是二进制码流，可以是任意字符串，最大长度64kb。实际应用中一般为10-100bytes，它以byte[]形式保存，一般设定成定长。建议越短越好，不要超过16个字节。

原因：

1. 目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。

2. 在HBase中，值value总是与它们的坐标一起传递。值value将始终伴随着它的行rowkey、列名column和时间戳。如果您的行rowkey和列名column很大，特别是与单元格值的大小相比，那么在HBase StoreFile (StoreFile (HFile))上的索引可能会因为单元格值坐标较大而占用HBase分配的大块RAM。

2. 散列原则

        如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位字节采用散列字段处理，由程序随即生成。低位放时间字段，这样将提高数据均衡分布，各个regionServer负载均衡的几率。

        如果不进行散列处理，首字段直接使用时间信息，所有该时段的数据都将集中到一个regionServer当中，这样当检索数据时，负载会集中到个别regionServer上，造成热点问题，会降低查询效率。

3. 唯一原则

        必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的，因此设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

三、解决数据热点问题 - 哈希散列+预分区

3.1 什么是热点

        检索HBase的记录首先需要通过RowKey来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数regionServer的读/写请求过大，或负载过大，而其他的regionServer负载却很小。这就是 “热点” 现象。

3.2 热点的解决方法

3.2.1 预分区

        预分区的目的是让表的数据可以均衡的分散在集群中，而不是默认只有一个region分布在集群的一个节点上。

3.2.2 加盐salt

        加盐就是在rowkey的前面分配随机数，具体就是给rowkey分配一个随机前缀，使得它和之前的rowkey的开头不同。

3.2.3 哈希

        哈希会使得同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一行数据。

3.2.4 反转

        反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。