您现在的位置是:首页 >学无止境 >大数据技术之HBase(四)RowKey设计原则及方法网站首页学无止境

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

five小点心 2024-06-13 12:01:02
简介大数据技术之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. 如果要存储多行数据的话,单凭rowkey就要占用很多的存储空间,这样会严重影响HFile的存储效率。

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的有序性。

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。