HBase之Rowkey设计
Rowkey基础
- Rowkey按自然顺序存储的,且具有唯一性,示例如下
a_022 a_101 b_123 f_031 f_051 f_131 z_121
- 当数据是有序的时候,通常利用二分查找的方式进行点查询、范围查询是最有效的(hash只能进行点查)。HBase的Rowkey查询正是遵循这种规律。
- Rowkey的查询可以分为两大类
- Get 点查询,给定一个rowkey,查询对应数据
- Scan 范围查询,给定一个起始rowkey、一个结束rowkey,查询范围内的所有数据
- 因此,我们需要根据查询的方式去设计Rowkey
Rowkey查询设计
-
数据
idCard name age address longitude latitude address_info 510***12 张三 18 重庆 105.55 29.30 *** 220***32 李四 23 北京 116.23 39.72 *** 310***65 王五 18 重庆 103.36 28.75 *** 240***13 李磊 27 上海 121.68 31.80 *** 510***12 张三 18 北京 115.38 38.95 *** -
一般来说,根据实际业务场景,我们需要将多个字段设计到一个Rowkey中,下面来分析几个场景
-
单点查询业务
- 单点查询设计最简单,只需要将能够唯一确定一条数据的几个字段组合为一个Rowkey即可
- 例如,查询某个人在某城市的地址信息
- 上面数据中,张三分别在重庆、北京都有住址信息,因此光靠idCard不能确定唯一条数据。
- Rowkey应当由
idCard_address
组合而成,例如510***12_重庆
-
范围查询业务
- 范围查询设计较麻烦,有几个要点如下
- 一般来说需要将范围字段放至Rowkey最后
- 查询时必须明确Rowkey的范围字段前面的所有字段值
- 通常除了取并集时不能同时存在2个及以上的范围字段(有特殊办法解决)
- 例如,查询某个地区一定年龄范围的人
- 如果age字段在address字段前面(age_address),显然无法进行范围查询,因为必须先确定address
- Rowkey应当由
address_age
组合而成,例如重庆_18
- 另外,如果想随意查询重庆某个经度范围、某个纬度范围的人(address_longitude_latitude),显然也是无法使用的(只能满足and查询)
- 范围查询设计较麻烦,有几个要点如下
-
范围查询业务——双重范围
- 前面已经说了,一般情况下无法同时存在2个及以上的范围字段。不过,在某些场景下,利用特殊手段,依然可以实现双重范围查询。
- 例如,查询某人在某个经度范围、某个纬度范围的地址
- 显然,此时存在2个范围,例如张三、经度100.23-105.34、纬度25.12-30.24
- 我们可以将经纬度划分为N个小块,根据小块的标签进行查询,图例如下
- 一个小块的标签编号,即代表了某个范围内的所有经纬度。利用小块编号就能进行范围查询,一个小块编号代表一个范围,多个小块编号就能代表一个大的范围。显然,这种方式会存在精度损失问题,当小块越大时,精度损失越大,如果缩小小块的范围,又会提高查询的代价(因为要查询更多的rowkey)。这种方案,在地理信息编码中用的较多,例如Geohash。
- 将Rowkey设计为
人名_小块编号
,例如张三_23
。想对张三进行多个范围的查询,只需执行多个Get查询即可。
- 虽然,使用这种方式实现双重范围查询,会损失部分精度,但
- 如果你的业务场景不敏感,那么这样就非常好
- 如果你的业务场景比较在乎这里的精度,你可以在查询中添加filter,或是查得数据后进行过滤(推荐后者,将计算分散到客户端)
-
其他部分,请看常见问题
二级索引
- 内部实现
- 利用协处理器(coprocessor),设计二级索引表
- 将二级索引设计到二级索引表的Rowkey中,二级索引表的列簇存原始表的Rowkey
- 查询时,根据字段从二级索引表的Rowkey查询到数据,数据即原始表的Rowkey,再根据该Rowkey到原始表查询数据
- 华为hindex,与协处理器方式同理,不过使用较方便(单表过大可能会出问题,例如我遇到的80亿数据量的单张表)
- 也可以不用协处理器,自己实现二级索引表,但是协处理器更方便
- 利用协处理器(coprocessor),设计二级索引表
- 外部实现
- Phoenix 专用于创建HBase二级索引
- ElasticSearch 通用型索引创建
常见问题
- 建表初期入库较慢?
- HBASE建表后,默认只有一个Region,会随着数据量增加,自动拆分为多个Region。因此,最开始时只有一个Region,数据量大的话,会感觉入库速度不理想。
- 建议,分析该表的Rowkey,进行预拆分,初始时就建立起多个Region,这样会提高HBase入库吞吐量。
- 难以决定Rowkey的预拆分?
- Rowkey较多,不知道怎么创建预拆分的key。如果是定期一张新表(例如每天一张),那么有个小技巧可以帮助你。
- 第一次建表时,不做预拆分,等待入库完成,HBase将会自动完成Region拆分。根据HBase本次的表拆分信息创建对下一次的表进行预拆分即可。
- 入库热点问题?
- 通常是数据不具备较强随机性(散列性)导致的
- 实时入库时,当相近的时间之间,其数据的Rowkey自然顺序较接近,会导致该时间段的数据都入向同一个Region,自然效率就降低了。
- 例如,将时间字段放在Rowkey的第一位,会导致实时入库时,总是同时只存在一个Region在入数据。
- 建议
- 重新设计Rowkey中导致入库热点问题的字段
- 如果该字段不是必须在第一位。那么可以将后面较随机的字段替换到前面来
- 如果该字段必须在第一位。那么查询时该字段若能固定长度,则可以将其打乱,例如将手机号的后面3位替换到最前面来
18912345678 -> 67818912345
- 如果不需要实时,那么可以进行批量入库,打乱数据顺序,就不存在Region热点问题了
- 使用数据的HASH值(取前几位即可)作为Rowkey前缀
- 例如:
c0bef_字段A_字段B
- 需要注意的是,如果以HASH值为Rowkey前缀,能够达到较好的数据分布均匀效果,解决热点问题,但是会牺牲Rowkey的易用性
- 因为你必须记住前面的HASH值,以用于后续查询
- 该方式只直接适用于GET查询,如需进行多维度查询,建议创建二级索引(典型架构就是 ES + HBase)
- 例如:
- 重新设计Rowkey中导致入库热点问题的字段
- Rowkey的实际顺序与期待的不符?
- 例如,一份数据
// 期待的顺序如下 f_31 f_51 f_131 // 实际的顺序如下 f_131 f_31 f_51
- 需要注意的是HBASE的Rowkey是按自然顺序排序的,后者才是真正的自然顺序
- 如果需要按照期待的顺序存储,那么应当对第二个字段进行补齐,例如
f_031 f_051 f_131
- 因此,通常我们会要求每个字段应当是定长的
- 例如,一份数据
- 入库程序无法保证 exactly-once ?
- 通常,入库程序可能由于某些原因挂了,或是网络问题,最终导致重复入库数据。
- HBase的Rowkey具有唯一性,因此合理的设计Rowkey,可以保证数据在业务上的幂等性!