HBase 顺序序列rowkey和预分区规则的思考和设计

2019年6月9日 324次阅读 来源: 刘_威

以往工作中HBase存储海量数据时候，因为历史原因主键使用自增长序列，数据迁移到HBase中时，并没有改变主键策略。导致数据全部写入一个region，造成数据热点。当时也没有采用预分区，数据增长过快，region过大时，在系统低负载时段需手动切分region。这些原因导致集群整体效率低。

现在要求

目前正好有一个新的数据存储场景开始设计，对数据需要增量顺序读（如：增量构建全文索引等），中等规模随机读。能按照区间范围顺序查询，并能控制查询的开始和结束。以方便增量或重新构建索引或控制区间化数据读取需求等等。总结历史经验和教训， 现在需要考虑的2种场景：

  1. 海量文本数据A，天入库数据量在30-200W左右，文本格式长，需要保存原文。（数量现对小，单文本容量比较大，需要保存原文）
  2. 海量文本数据B，天数据量在500w-5000w之间，文本格式短小。（数量现对多，单文本容量相对小 ）

HBase基本情况

表和索引组成

  • HBase一般由行键(row key)、列键(column qualifier )、列族(column family)组成。行键对应关键数据库中主键，HBase为行键建立了索引，列键归属列族。通过行键/列键/列族定位到一个唯一记录。

  • HBase中使用.META内部表存储region的分布情况以及每个region的详细信息。region中记录了rowkey范围，region分散在不同服务器中。通过region server提供访问数据访问服务，region server可服务多个region，来自不同region server上的region组合成表格的整体逻辑视图。

获取记录方式

  • 通过get方式，指定rowkey获取唯一记录
  • 通过scan方式，设置startRow和stopRow参数进行范围匹配
  • 通过scan方式，全表扫描，并通过RowFilter过滤出数据
    基本可归纳为顺序读和随机读。

rowkey原则

长度原则

行键长度尽量短和合理，因为持久化文件HFile中使用KeyValue形式保存数据，column family/column qualifier/rowkey会记录到每一条数据中，导致存储文件过大，也会导MemStore内存有效利用率降低。rowkey使用byte[]保存数据，使用数值(long)比字符(String)占用更小空间。64为系统内存8字节对齐，控制在16个字节，尽量使用8为倍数。

散列原则避免热点
  • 加盐
    在rowkey前按规则加随机数，使数据分散到不同region上避免热点。也可通过业务规则分段比如：userid-service-timestamp，把不同userid或不同业务数据切分到不同region。
  • 哈希
    生成哈希或使用UUID散列它。
  • 反转
    如果是顺序序列可以反转它，让他经常改变的部分排到前面避免数据集中。时间反转也可以考虑Long.Max_Value – timestamp。
唯一原则

主键都必须保证唯一。

分布式主键算法

分布式主键算法要求

  • 毫秒级的快速响应
  • 可用性强
  • prefix有连续性方便DB顺序存储
  • 体积小，8字节为佳

目前分布式主键算法比较

UUID

16字节，JAVA自带，好用，占用空间大。

Twitter Snowflake

Snowflake： timestamp + work id + seq number

《HBase 顺序序列rowkey和预分区规则的思考和设计》 图引用自其他Blog

8字节，可用性强，速度快。占用空间小，如果考虑复杂环境work id需要更好处理。twitter默认实现需要引入zookeeper 和独立的snowflake专用服务器，UC实现通过配置文件确定work id。

MongoDB ObjectId

ObjectId：timestamp + machine + pid + seq number

《HBase 顺序序列rowkey和预分区规则的思考和设计》 图引用自MongoDB 官方文档

12字节,可用性强，速度快。占用空间中等，用空间降低实现复杂度，基本没有其他依赖。

业务rowkey设计

业务的需求

  • 大文本A每分钟最多1388条，每秒23条。
  • 小文本B每分钟最多34722条，每秒578条。

考虑到大量顺序读，需要做到局部连续，全局分散。每秒极端情况写数据量不多，可考虑按照分钟分区。一共60个分区。获取一天数据时候通过60*24=1440 按照1440个局部连续批来获取数据。

rowkey规则1

参考snowflake和ObjectId原理，感觉它并不好直观分区，所以：
partition + timestamp + work id+ seq number 增加分区，减少时间和work id范围。
0-000000-01111111 10111111 11111000 00111100-00000000 0-00000000 00000000
1bit 不用
6bit 分区，可支持63个分区，可使用秒或分钟做分区
32bit 时间 System.currentTimeMillis()到秒(可以用到2099年)
9bit 区分机器和进程，需要在存储空间和复杂度上找平衡
16bit seq(最大65535)
全长64Bit，8Byte可做到不依赖其他服务。
分区可表示为：
0-000000-0000000 000000000 00000000 00000000-00000000 0-00000000 00000000
0-000001-0000000 000000000 00000000 00000000-00000000 0-00000000 00000000
0-000010-0000000 000000000 00000000 00000000-00000000 0-00000000 00000000
0-000011-0000000 000000000 00000000 00000000-00000000 0-00000000 00000000

rowkey规则2

规则1太复杂实现和可读性低简，简化下
reverse timestamp(mmHHddMMyyyy)+ seq number(0-99999)
seq number使用redis保证全局唯一，每个客户端使用步长减少redis访问频次。
例如：rowkey=20170719213012345表示为：30211907201712345使用分钟做分区30表示分区。
分区可表示为：
1000000000000000L：11100011010111111010100100110001101000000000000000
3000000000000000L：111000110101111110101001001100011010000000000000000
59000000000000000L：11010001100111000010111111111001101111111000000000000000
56Bit，7Byte 依赖redis服务 简单直观可读性好。

rowkey规则2顺序读取数据方式

假如我需要scan查询2017/07/19数据，我需要从201707190000~201707192359
60*24=1440做循环。2017/07/19/ 21:35为例子， StartRow和StopRow设置如下：
StartRow=35211907201700000L
StopRow=35211907201799999L

最终选择规则2作为rowkey规则，随然依赖redis服务，但是存储空间小、可读性高、可理解性好、方便使用和维护。

其他

不考虑HBase RowFilter方式，希望的效果就是直接利用rowkey内部索引和.META表。对于其他复杂组合查询，我倾向使用全文索引ES或Solr。

可以参考算法源码

UC Snowflake

https://github.com/sumory/uc/blob/master/src/com/sumory/uc/id/IdWorker.java

MaongoDB ObjectID

https://github.com/mongodb/mongo-java-driver/blob/master/bson/src/main/org/bson/types/ObjectId.java

Email：wei.liu@qq.com
刘威 2017年7月19日 长沙

    原文作者：刘_威
    原文地址: https://www.jianshu.com/p/9ad59c0e65ec
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞