小记--------hbase数据库预分区设计,rowkey设计及参数调优

  1. 表的设计

1.1预分区设计

每一个region维护者startrowkeyendrowkey,如果假如的数据符合某个region维护的rowkey范围,则该数据交给这个region维护,所以我们可以将数据所有投放的分区提前大致的规划好,以提高hbase性能

可以通过hbase shell 命令进行创建

create 't9' , 'MM' , SPLITS => ['30000' , '60000' , '90000' ]

create 't4' , { NAME => 'MM' , COMPRESSION => 'snappy' } , {NUMREGIONS => 5 , SPLITALGO => 'HexStringSplit'}

通过javaapi创建

调用HBASEAdmin类的createTable方法进行创建

1.2 rowkey设计

首先需要考虑应用场景的读写比列:重写轻读,重读轻写,读写一样

因为数据负载均衡和高效的读取时常是矛盾的

1.在重写轻读的大数据场景中:rowkey的设计应在满足基本查询需求的前提下,更注重整体的吞吐量

2.在重读轻写的大数据场景中:rowkey的设计则应更侧重于如何高效的读取;

rowkey字段的选取

唯一性:rowkey必须能够保证唯一的识别一行数据;不论应用什么样的负载均衡场景,rowkey字段应该参考最高频的查询场景

度原则:rowkey的字段应控制在16个字节之内(在大多数的场景中),从而避免因rowkey字段太长影响Hfile的存储效率

A.避免热点的方法1 -Reversing (反转)

如果rowkey 本身分布均匀,但是rowkey的尾部数据缺是比较好的随机性,此时,可以考虑将rowkey的信息反转,或者直接将尾部的数据提到rowkey的前部1001 1002 5

 缺点:场景利于查询中的get但是不利于scan,因为数据在原rowkey上的自然顺序已经被打乱

B.避免热点的方法2: - Salting (前部添加随机数)

 Salting的原理实在原rowkey的前面添加固定长度的随机bytes,随机bytes可以保证数据在所有的region上是负载均衡的

 缺点:因为是随机的bytes ,所以原rowkey查询时无法获知随机bytes信息,所以在读取过程中需要倒各个可能的region中查询。所以Salting对于读取是不利的

C.避免数据热点的方法3 - Hashing

 基于rowkey的全部或部分数据进行hash,而后将hashing后的值完整替代原rowkey或者替换rowkey的前缀部分

 缺点:与resersing类似,hashing也不利于scan,因为也打乱了原rowkey的自然顺序

例:

rowkeystartkey 的关系:

    如果startkey的值为1000 2000 3000

那么实际的region为:

第一个region 0-1000

第二个region 1000-2000

第三个region 2000-3000

第四个region 3000-无穷大

rowkey的设计为 随机数(1001)+id+create_time

那么这个rowkey将会落到第二个region上。 原理:会根据region的位数 去到rowkey上从左开始截取相同位数的值做比较,在哪个region的范围就落到哪个region上。

1.3列族设计

建议不超过2-3个列簇,因为当某个列簇在flush的时候,它邻近的列簇也会因关联效应被处罚flush,最终导致系统产生更多的IO

建议:将所有相关性很强的key-value都放在同一个列簇下,这样既能做到查询效率最高,也能保持尽可能少的访问不同的磁盘文件

1.4 Max Version 最大版本数

可以通过参数HColumnDescriptor.setMaxVersions(int maxVersions)

设置表中数据的最大版本。

如果应用场景只需要保存最新的数据那么可以设置为

HColumnDescriptor.setMaxVersions(1)

  1. 一些参数调优

2.1 hbase.client.write.buffer  Hbase客户端写入缓冲区大小

2.2 hbase.regionserver.handler.count  Regionserver中启动RPC服务器实例数量;该参数调小点,适用于单次请求内存消耗较高的Big PUT场景;调大点,适用于单次请求内存消耗低,远程过程调用要求高的场景。需要配合 hbase.client.write.buffer参数进行调优。

估计服务器已使用内存的数量,请用值hbase.client.write.buffer*hbase.regionserver.handler.count”。

2.3 hbase.hregion.max.filesizeHStorefile最大值,超过该值则进行切分region

2.4 hbase.regionserver.global.memstore.upperLimitregionserver中所有region的所有memstore总占堆内存比(默认为0.4)高水位线,也就是说当regionserver下的memstore的总和等于这个占比的时候进行flush操作

2.5 hbase.regionserver.global.memstore.size.lower.limitregionserver中所有region的所有memstore总占堆内存比(默认为0.95)低水位线,也就是说在进行flush操作时regionserver下的memstore的总和等于0.4*0.95=0.38

(long) (this.globalMemStoreLimit * this.globalMemStoreLimitLowMarkPercent);

2.6 hfile.block.cache.sizeHFile使用的缓存占分配的堆内存占比(默认值为0.2);当然是越大越好,如果写比读少很多,开到0.4-0.5也没问题。如果读写较均衡,0.3左右。如果写比读多,就默认值即可

2.7 hbase.hstore.blockingStoreFilesstore阻塞存储文件

hbase.hstore.blockingWaitTimestore阻塞等待时间;

store中有超过blockingstorefiles的数量时,会阻塞对HRegion的更新,直到完成storefile的合并或者超过blockingWaitTime的值;所以理论上为了减少写请求的阻塞从而影响regionserver的响应时间,可以将blockingstorefiles值设置无限大。

2.8 hbase.hregion.memstore.block.multiplierhbase memstore块乘法器;

当一个region里的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时,blockregion的所有请求,进行flush,释放内存。虽然我们设置了region所占用的memstores总内存大小,比如64M,但想象一下,在最后63.9M的时候,我Put了一个200M的数据,此时memstore的大小会瞬间暴涨到超过预期的hbase.hregion.memstore.flush.size的几倍。这个参数的作用是当memstore的大小增至超过hbase.hregion.memstore.flush.size 2倍时,block所有请求,遏制风险进一步扩大;

所以需要预估应用场景中会不会出现突发写请求暴涨,如果有可以调大这个参数值

2.9 hbase.hregion.memstore.flush.size;单个regionmemstore的值达到该值时会自动触发flush操作(默认值为128M

  1. 分别调整Masterregionserverjava堆栈大小(heapsize

由于默认的regionserver的内存才1G,而memstore默认是占40%,所以分配给memstore的才400M,在实际生产环境下很容易阻塞,可以通过HBASE_HEAPSIZE参数分别调整MasterRegionServer的内存

原文地址:https://www.cnblogs.com/yzqyxq/p/12103525.html