1 RowKey设计

重要:一条数据的唯一标识就是 rowkey,那么这条数据存储于哪个分区,取决于 rowkey 处于 哪个一个预分区的区间内,设计 rowkey的主要目的 ,就是让数据均匀的分布于所有的 region 中,在一定程度上防止数据倾斜。
设计方案如下:

  1. 生成随机数、hash、散列值
  2. 时间戳反转
  3. 字符串拼接

1.1 RowKey定长

  1. 避免扫描数据混乱,解决字段长度不一致的问题,可以使用相同阿斯卡码值的符 号进行填充,框架底层填充使用的是阿斯卡码值为 1 的^A。
  2. 最后的日期结尾处需要使用阿斯卡码略大于’-’的值,比如 .
rowKey 设计格式 => ^A^Auser

1.2 可枚举的部分放在前面

hbase 设计 rowKey 使用的特点为: 适用性强 泛用性差 能够完美实现一个需求 但是不能同时完美实现多个需要。
如果想要同时完成两个需求,需要对 rowKey 出现字段的顺序进行调整。
调整的原则为:可枚举的放在前面。其中时间是可以枚举的,用户名称无法枚举,所以 必须把时间放在前面。

rowKey 设计格式 => date(yyyy-MM)^A^Auserdate(-dd hh:mm:ss ms) 

1.3 添加预分区优化

每一个 region 维护着 startRow 与 endRowKey,如果加入的数据符合某个 region 维护的 rowKey 范围,则该数据交给这个 region 维护。
预分区的分区号同样需要遵守 rowKey 的 scan 原则。所有必须添加在 rowKey 的最前面, 前缀为最简单的数字。同时使用 hash 算法将用户名和月份拼接决定分区号。(单独使用用 户名会造成单一用户所有数据存储在一个分区)

1.3.1 预规划分区

根据12个月,规划120个分区,每个分区有startKey 和stopKey,采用startKey 作为分区号

添加预分区优化startKeystopKey000 001001 002002 003...119 120

1.3.2 提前将分区号和月份进行对应。

每一个月份对应10个分区

000 到 009 分区 存储的都是 1 月份数据010 到 019 分区 存储的都是 2 月份数据...110 到 119 分区 存储的都是 12 月份数据

1.3.3 设计rowKey

rowKey 设计格式 => 分区号date(yyyy-MM)^A^Auserdate(-dd hh:mm:ss ms)

1.3.4 根据 用户名和事件获取rowKey值

分区号=> hash(user+date(MM)) % 10 + 对应月份初始分区号分区号填充 如果得到 85 => 085例:zhagnsan2022-02-14 12:34:45 
分区号=hash(zhagnsan+date(02)) % 10 + 20 = 25分区号补0:025用户名补^A :^A^AzhagnsanrowKey => 0252022-02^A^Azhagnsan-14 12:34:45 

1.4 案例

可以穷举的写在前面即可 rowKey 设计格式 => 分区号date(yyyy-MM)^A^Auserdate(-dd hh:mm:ss ms) 

(1)统计张三在 2021 年 12 月份消费的总金额
分区号=> hash(user+date(MM)) % 10 + 110
scan: startRow => 分区号2021-12AAzhangsan stopRow => 2021-12AAzhangsan.
(2)统计所有人在 2021 年 12 月份消费的总金额
分区号=> hash(user+date(MM)) % 10 + 110
scan: startRow => 分区号2021-12 stopRow => 分区号2021-12.

2 参数调优

2.1 Zookeeper 会话超时时间

属性:zookeeper.session.timeout
解释:默认值为 90000 毫秒(90s)。当某个 RegionServer 挂掉,90s 之后 Master 才 能察觉到。可适当减小此值,尽可能快地检测 regionserver 故障,可调整至 20-30s。
看你能有都能忍耐超时,同时可以调整重试时间和重试次数
hbase.client.pause(默认值 100ms)
hbase.client.retries.number(默认 15 次)

2.2 设置 RPC 监听数量

属性:hbase.regionserver.handler.count
解释:默认值为 30,用于指定 RPC 监听的数量,可以根据客户端的请求数进行调整,读写 请求较多时,增加此值。

2.3 手动控制 Major Compaction

属性:hbase.hregion.majorcompaction 解释:默认值:604800000 秒(7 天), Major Compaction 的周期,若关闭自动 Major Compaction,可将其设为 0。如果关闭一定记得自己手动合并,因为大合并非常有意义

2.4 优化 HStore 文件大小

属性:hbase.hregion.max.filesize
解释:默认值 10737418240(10GB),如果需要运行 HBase 的 MR 任务,可以减小此值, 因为一个 region 对应一个 map 任务,如果单个 region 过大,会导致 map 任务执行时间过长。该值的意思就是,如果 HFile 的大小达到这个数值,则这个 region 会被切分为两 个 Hfile。

2.5 优化 HBase 客户端缓存

属性:hbase.client.write.buffer
解释:默认值 2097152bytes(2M)用于指定 HBase 客户端缓存,增大该值可以减少 RPC 调用次数,但是会消耗更多内存,反之则反之。一般我们需要设定一定的缓存大小,以达到 减少 RPC 次数的目的。

2.6 指定 scan.next 扫描 HBase 所获取的行数

属性:hbase.client.scanner.caching 解释:用于指定 scan.next 方法获取的默认行数,值越大,消耗内存越大。

2.7 BlockCache 占用 RegionServer 堆内存的比例

属性:hfile.block.cache.size
解释:默认 0.4,读请求比较多的情况下,可适当调大

2.8 MemStore 占用 RegionServer 堆内存的比例

属性:hbase.regionserver.global.memstore.size
解释:默认 0.4,写请求较多的情况下,可适当调大
Lars Hofhansl(拉斯·霍夫汉斯)大神推荐 Region HStore 文件设置 20G,刷写大小设置 128M,其 它默认。

3 JVM 调优

JVM 调优的思路有两部分:一是内存设置,二是垃圾回收器设置。
垃圾回收的修改是使用并发垃圾回收,默认 PO+PS 是并行垃圾回收,会有大量的暂停。 理由是 HBsae 大量使用内存用于存储数据,容易遭遇数据洪峰造成 OOM,同时写缓存的数 据是不能垃圾回收的,主要回收的就是读缓存,而读缓存垃圾回收不影响性能,所以最终设 置的效果可以总结为:防患于未然,早洗早轻松。

  1. 设置使用 CMS 收集器:
-XX:+UseConcMarkSweepGC
  1. 保持新生代尽量小,同时尽早开启 GC,例如:
//在内存占用到 70%的时候开启 GC-XX:CMSInitiatingOccupancyFraction=70//指定使用 70%,不让 JVM 动态调整-XX:+UseCMSInitiatingOccupancyOnly//新生代内存设置为 512m-Xmn512m//并行执行新生代垃圾回收-XX:+UseParNewGC// 设 置 scanner 扫 描 结 果 占 用 内 存 大 小 , 在 hbase-site.xml 中,设置hbase.client.scanner.max.result.size(默认值为 2M)为 eden 空间的 1/8(大概在 64M)// 设置多个与 max.result.size * handler.count 相乘的结果小于 Survivor Space(新生代经过垃圾回收之后存活的对象)

4 HBase 使用经验法则

官方给出了权威的使用法则:

  1. Region 大小控制 10-50G
  2. cell 大小不超过 10M(性能对应小于 100K 的值有优化),如果使用 mob(Mediumsized Objects 一种特殊用法)则不超过 50M。
  3. 1 张表有 1 到 3 个列族,不要设计太多。最好就 1 个,如果使用多个尽量保证不同时读取多个列族。
  4. 1 到 2 个列族的表格,设计 50-100 个 Region。
  5. 列族名称要尽量短,不要去模仿 RDBMS(关系型数据库)具有准确的名称和描述。
  6. 如果 RowKey 设计时间在最前面,会导致有大量的旧数据存储在不活跃的 Region中,使用的时候,仅仅会操作少数的活动 Region,此时建议增加更多的 Region 个数。
  7. 如果只有一个列族用于写入数据,分配内存资源的时候可以做出调整,即写缓存不会占用太多的内存。