Log表新的RowKey设计,预Split
1 目前Rawlog表的问题
- region数量庞大,空region 率大
- 共有12791个region
- 11409空region, 比例为89.19%
- 剩余的region大小也是极度不均衡,最大的region 287G, <1m的region有129个
- 读写不均衡
- 现有的rowkey设计,简单来说是appid+date的顺序序列
- 简单来说对于每个appid都有一个写热点,这不仅没有利用到分布式的优点,还会极大的降低整个hbase集群的服务能力
- 读存在同样的问题,一次读基本上会集中在一个region上,这对于scan是好的,但目前我们所有的log查询都是基于mutiget的,还不如分散来的性能好。
2 解决方案
现有的log查询方案:
- 从logindex表获取log的rowkey
- 根据rowkey使用mutiget获取具体的log
所以不在需要顺序的rowkey设计。
- 解决region数量庞大的问题
- 使用预分的region
- 根据实际数据量,预分出足够的region, 后续保证尽量少的出现split
- 解决空region率,大小不均衡,及读写不均衡
- 这些问题可以一起解决
- 写的时候足够散列的(平均)写到这些region上
- 理想状态下各region大小会完全一致
- 读写理想状态下也会完成一致
- 可以减少split的次数,理想状态下不会再出现,同样减少了该表region的blance出现的次数,理想状态下不会出现。
现在进行改造的优势是,我们有生产数据进行支持,金桥是一个全新的集群,这是一个机会,可以不考虑老数据的迁移(到时福泉与金桥应用并行运行,避免迁移数据)
2.1 预分region的数量
- 目前生产rawlog表的大小为2938.5G, 也就是3T,保存了7天的数据
- 考虑到以后的数据增量,以10T为存储目标,一个region2G, 可以预分5000个region
2.2 如何实现足够散列写(或对region平均写)
- 理论上可以对region依次写入一条log, 轮循一遍后,再次从头轮循,这样可以达到绝对平均
- 实际解决方案, 可以设计一种rowkey结构
hashcode
|
unique-id
|
---|---|
1 ~ 100000 | appid + hostip + timestamp + logid |
- 从通用角度,rowkey 分为两部分
- hashcode: 散列值,用于将数据散列到各region上
- unique-id: 这条数据的一个唯一id, 这个基本上和业务相关
- 对于rowlog表
- hashcode: 可以是一个1 ~ 100000的int值
- unique-id: 可以是一个由appid + hostip + timestamp + logid 组成的唯一id, 也是现有的rowkey设计
- 如果预分5000个region, 每个region将占有20个散列值(startKey-endKey):1-20, 21-40, .... 99981-100000
- 1(星期几)_100102(APPID)_123(IP)_2019730154044(时间)_随机数(logid): 这个样的值,如果2019730154044 时间一直增长,hbase的数据比如在7天内无法有效覆盖,因为你2019这个时间永远一直增加。 在hbase的查询中,如果确定了天,后面的2019730就不需要了,就只查小时,分钟,秒了:154044,这样,后面会很好有重复,也会很好覆盖7天前的数据。
2.3 工作量
- 只要修改writer端rowlog的rowkey生成策略
- 对于其他地方完全透明
- 编码的话只要两个小时就足够了,后续就是支持工作了。
- 如何获取一条log的hashcode, 有几种方案:
- writer每收一条log可以递增,到达100000,归1
- 也可以每次取1-100000的随机值,效率最低
- 为了去除1-20的连续写, 可以
- 可以分配一个int[100000],里面存放shuffle后的1-100000的值
- 每来一条log从数组里取一个值int[i++]
- 到达数组结尾后可以直接从头再取,或shuffle后再从头取
- 或着一开始就预先shuffle好几个数组,待用。