Hbase中的region和rowkey

region

Region是HBase数据管理的基本单位,region有一点像关系型数据的分区。
Region中存储这用户的真实数据，而为了管理这些数据，HBase使用了RegionSever来管理region。
region的分配

一个表中可以包含一个或多个Region。
每个Region只能被一个RS（RegionServer）提供服务，RS可以同时服务多个Region，来自不同RS上的Region组合成表格的整体逻辑视图。
regionServer其实是hbase的服务，部署在一台物理服务器上，region有一点像关系型数据的分区，数据存放在region中，当然region下面还有很多结构，确切来说数据存放在memstore和hfile中。我们访问hbase的时候，先去hbase 系统表查找定位这条记录属于哪个region，然后定位到这个region属于哪个服务器，然后就到哪个服务器里面查找对应region中的数据
region结构


数据的写入


Memstore Flush流程

flus流程分为三个阶段：

• prepare阶段：遍历当前 Region中所有的 MemStore ，将 MemStore 中当前数据集 CellSkpiListSet 做一个快照 snapshot；然后再新建一个 CellSkipListSet。后期写入的数据都会写入新的 CellSkipListSet 中。prepare 阶段需要加一把 updataLock 对写请求阻塞，结束之后会释放该锁。因为此阶段没有任何费时操作，因此锁持有时间很短
  
• flush阶段：遍历所有 MemStore，将 prepare 阶段生成的snapshot 持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及到磁盘 IO 操作，因此相对耗时
  
• commit阶段：遍历所有 MemStore，将flush阶段生成的临时文件移动到指定的 ColumnFamily 目录下，针对 HFile生成对应的 StoreFile 和 Reader，把 StoreFile 添加到 HStore 的 storefiles 列表中，最后再清空 prepare 阶段生成的 snapshot快照
  

Compact 合并机制

hbase中的合并机制分为自动合并和手动合并
自动合并：

• minor compaction 小合并
  
• major compacton 大合并
  

minor compaction（小合并）
将 Store 中多个 HFile 合并为一个相对较大的 HFile 过程中会选取一些小的、相邻的 StoreFile 将他们合并成一个更大的 StoreFile，对于超过 TTL 的数据、更新的数据、删除的数据仅仅只是做了标记，并没有进行物理删除。一次 minor compaction 过后，storeFile会变得更少并且更大，这种合并的触发频率很高
小合并的触发方式：
memstore flush会产生HFile文件，文件越来越多就需要compact.每次执行完Flush操作之后，都会对当前Store中的文件数进行判断，一旦文件数大于配置3，就会触发compaction。compaction都是以Store为单位进行的，而在Flush触发条件下，整个Region的所有Store都会执行compact
后台线程周期性检查
检查周期可配置：
hbase.server.thread.wakefrequency 默认10000毫秒)
hbase.server.compactchecker.interval.multiplier 默认1000
CompactionChecker大概是2hrs 46mins 40sec 执行一次

1. <property>
2.         <name>hbase.hstore.compactionThreshold</name>
3.         <value>3</value>
4. </property>
7. <property>
8.         <name>hbase.hstore.compaction.max</name>
9.         <value>10</value>
10. </property>
13. <property>
14.         <name>hbase.hstore.compaction.min.size</name>
15.         <value>134217728</value>
16. </property>
19. <property>
20.         <name>hbase.hstore.compaction.max.size</name>
21.         <value>9223372036854775807</value>
22. </property>

复制代码

major compaction（大合并）
合并 Store 中所有的 HFile 为一个 HFile，将所有的 StoreFile 合并成为一个 StoreFile，这个过程中还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。合并频率比较低，默认7天执行一次，并且性能消耗非常大，建议生产关闭（设置为0），在应用空间时间手动触发。一般是可以手动控制进行合并，防止出现在业务高峰期。

1. 线程先检查小文件数是否大于配置3，一旦大于就会触发compaction。
2. 大文件周期性合并成Major Compaction
3. 如果不满足，它会接着检查是否满足major compaction条件
4. 如果当前store中hfile的最早更新时间早于某个值mcTime就会触发major compaction
5. (默认7天触发一次，可配置手动触发)
8. <property>
9.         <name>hbase.hregion.majorcompaction</name>
10.         <value>604800000</value>
11. </property>

复制代码

手动合并

一般来讲，手动触发compaction通常是为了执行major compaction，一般有这些情况需要手动触发合并是因为很多业务担心自动maior compaction影响读写性能，因此会选择低峰期手动触发也有可能是用户在执行完alter操作之后希望立刻生效，执行手动触发maiorcompaction:

1. # 造数据
2. truncate 'doit:test'
3. put 'doit:test','001','f1:name','zss'
4. put 'doit:test','002','f1:name','zss'
5. put 'doit:test','003','f1:name','zss'
6. put 'doit:test','004','f1:name','zss'
7. flush 'doit:test'                    
8. put 'doit:test','005','f1:name','zss'
9. put 'doit:test','006','f1:name','zss'
10. put 'doit:test','007','f1:name','zss'
11. put 'doit:test','008','f1:name','zss'
12. flush 'doit:test'                    
13. put 'doit:test','009','f1:name','zss'
14. put 'doit:test','010','f1:name','zss'
15. put 'doit:test','011','f1:name','zss'
16. put 'doit:test','012','f1:name','zss'
17. flush 'doit:test'
18. put 'doit:test','013','f1:name','zss'
19. put 'doit:test','014','f1:name','zss'
20. put 'doit:test','015','f1:name','zss'
21. put 'doit:test','016','f1:name','zss'
22. flush 'doit:test'
23. put 'doit:test','017','f1:name','zss'
24. put 'doit:test','018','f1:name','zss'
25. put 'doit:test','019','f1:name','zss'
26. put 'doit:test','020','f1:name','zss'
27. flush 'doit:test'
28. put 'doit:test','021','f1:name','zss'
29. put 'doit:test','022','f1:name','zss'
30. put 'doit:test','023','f1:name','zss'
31. put 'doit:test','024','f1:name','zss'
32. flush 'doit:test'
33. put 'doit:test','025','f1:name','zss'
34. put 'doit:test','026','f1:name','zss'
35. put 'doit:test','027','f1:name','zss'
36. put 'doit:test','028','f1:name','zss'
37. flush 'doit:test'
38. put 'doit:test','021','f1:name','zss'
39. put 'doit:test','022','f1:name','zss'
40. put 'doit:test','023','f1:name','zss'
41. put 'doit:test','024','f1:name','zss'
42. flush 'doit:test'
43. put 'doit:test','021','f1:name','zss'
44. put 'doit:test','022','f1:name','zss'
45. put 'doit:test','023','f1:name','zss'
46. put 'doit:test','024','f1:name','zss'
47. flush 'doit:test'
48. put 'doit:test','021','f1:name','zss'
49. put 'doit:test','022','f1:name','zss'
50. put 'doit:test','023','f1:name','zss'
51. put 'doit:test','024','f1:name','zss'
52. flush 'doit:test'
54. put 'doit:test','021','f1:name','zss'
55. put 'doit:test','022','f1:name','zss'
56. put 'doit:test','023','f1:name','zss'
57. put 'doit:test','024','f1:name','zss'
58. flush 'doit:test'
60. # 每次flush一下都会在底层生成一个小文件

复制代码

1. ##使用major_compact命令
2. major_compact tableName
4. major_compact 'doit:test'

复制代码

region的拆分

region中存储的是一张表的数据，当region中的数据条数过多的时候，会直接影响查询效率。当region过大的时候，region会被拆分为两个region，HMaster会将分裂的region分配到不同的regionserver上，这样可以让请求分散到不同的RegionServer上，已达到负载均衡  , 这也是HBase的一个优点
region的拆分策略

• ConstantSizeRegionSplitPolicy：0.94版本前，HBase region的默认切分策略
  

当region中最大的store大小超过某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分，一个region等分为2个region。
但是在生产线上这种切分策略却有相当大的弊端（切分策略对于大表和小表没有明显的区分）：
1.阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，形成热点，这对业务来说并不是什么好事。
2.如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。

• IncreasingToUpperBoundRegionSplitPolicy：0.94版本~2.0版本默认切分策略
  

总体看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大的store大小大于设置阈值就会触发切分。 但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.
region split阈值的计算公式是：
1.设regioncount：是region所属表在当前regionserver上的region的个数
2.阈值 = regioncount^3 * 128M * 2，当然阈值并不会无限增长，最大不超过MaxRegionFileSize（10G),当region中最大的store的大小达到该阈值的时候进行region split
例如：
•        第一次split阈值 = 1^3 * 256 = 256MB
•        第二次split阈值 = 2^3 * 256 = 2048MB
•        第三次split阈值 = 3^3 * 256 = 6912MB
•        第四次split阈值 = 4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB
•        后面每次split的size都是10GB了
特点
•        相比ConstantSizeRegionSplitPolicy，可以自适应大表、小表；
•        在集群规模比较大的情况下，对大表的表现比较优秀
•        对小表不友好，小表可能产生大量的小region，分散在各regionserver上
•        小表达不到多次切分条件，导致每个split都很小，所以分散在各个regionServer上

• SteppingSplitPolicy：2.0版本默认切分策略
  

相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些  region切分的阈值依然和待分裂region所属表在当前regionserver上的region个数有关系
•        如果region个数等于1，切分阈值为flush size 128M * 2
•        否则为MaxRegionFileSize。
这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。

• KeyPrefixRegionSplitPolicy
  

根据rowKey的前缀对数据进行分区，这里是指定rowKey的前多少位作为前缀，比如rowKey都是16位的，指定前5位是前缀，那么前5位相同的rowKey在相同的region中

• DelimitedKeyPrefixRegionSplitPolicy
  

保证相同前缀的数据在同一个region中，例如rowKey的格式为：userid_eventtype_eventid，指定的delimiter为 _ ，则split的的时候会确保userid相同的数据在同一个region中。 按照分隔符进行切分，而KeyPrefixRegionSplitPolicy是按照指定位数切分

• BusyRegionSplitPolicy
  

按照一定的策略判断Region是不是Busy状态，如果是即进行切分
如果你的系统常常会出现热点Region，而你对性能有很高的追求，那么这种策略可能会比较适合你。它会通过拆分热点Region来缓解热点Region的压力，但是根据热点来拆分Region也会带来很多不确定性因素，因为你也不知道下一个被拆分的Region是哪个

• DisabledRegionSplitPolicy：不启用自动拆分, 需要指定手动拆分
  

手动合并拆分region

手动合并

1. hbase(main):025:0> list_regions 'doit:test'
2.                  SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
3. --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
4. linux03,16020,1684200651855 |           doit:test,,1684205468848.920ae3e043ad95890c4f5693cb663bc5. |            | rowkey_010 |     0 |     0 |        0.0 |
5. linux01,16020,1684205091382 | doit:test,rowkey_010,1684207066858.5e04eb75e5510ad65a0f3001de3c7aa0. | rowkey_010 | rowkey_015 |     0 |     0 |        0.0 |
6. linux02,16020,1684200651886 | doit:test,rowkey_015,1684207066858.ed1b328ca4c485d4fa429922f6c18f0b. | rowkey_015 | rowkey_020 |     0 |     0 |        0.0 |
7. linux02,16020,1684200651886 | doit:test,rowkey_020,1684205468848.25d62e8cc2fdaecec87234b8d28f0827. | rowkey_020 | rowkey_030 |     0 |     0 |        0.0 |
8. linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
9. linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
10. 6 rows
11. Took 0.0299 seconds
12. hbase(main):026:0> merge_region 'doit:test,,1684205468848.920ae3e043ad95890c4f5693cb663bc5.','doit:test,rowkey_010,1684207066858.5e04eb75e5510ad65a0f3001de3c7aa0.'
13. Took 1.2638 seconds
14. hbase(main):027:0> list_regions 'doit:test'
15.                  SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
16. --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
17. linux03,16020,1684200651855 |           doit:test,,1684207066859.cdc1226d634c0cf16f58832637f485b6. |            | rowkey_015 |     0 |     0 |        0.0 |
18. linux02,16020,1684200651886 | doit:test,rowkey_015,1684207066858.ed1b328ca4c485d4fa429922f6c18f0b. | rowkey_015 | rowkey_020 |     0 |     0 |        0.0 |
19. linux02,16020,1684200651886 | doit:test,rowkey_020,1684205468848.25d62e8cc2fdaecec87234b8d28f0827. | rowkey_020 | rowkey_030 |     0 |     0 |        0.0 |
20. linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
21. linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
22. 5 rows
23. Took 0.0271 seconds

复制代码

手动拆分

1. hbase(main):029:0> list_regions 'doit:test'
2.                  SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
3. --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
4. linux03,16020,1684200651855 |           doit:test,,1684207066860.8ebf4555c58bd0e5fedae5d4efbe4235. |            | rowkey_030 |     0 |     0 |        0.0 |
5. linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
6. linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
7. 3 rows
8. Took 0.0329 seconds
9. hbase(main):030:0> split 'doit:test,,1684207066860.8ebf4555c58bd0e5fedae5d4efbe4235.','rowkey_025'
10. Took 0.1179 seconds
11. hbase(main):031:0> list_regions 'doit:test'
12.                  SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
13. --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
14. linux02,16020,1684200651886 |           doit:test,,1684207502853.af0819bd7f6daa9db2a8f994fb41682d. |            | rowkey_025 |     0 |     0 |        0.0 |
15. linux02,16020,1684200651886 | doit:test,rowkey_025,1684207502853.80d7feace447978ffe4a54418a20afd0. | rowkey_025 | rowkey_030 |     0 |     0 |        0.0 |
16. linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
17. linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
18. 4 rows
19. Took 0.0179 seconds
20. hbase(main):032:0> split 'doit:test,,1684207502853.af0819bd7f6daa9db2a8f994fb41682d.','rowkey_015'
21. Took 0.1262 seconds
22. hbase(main):033:0> list_regions 'doit:test'
23.                  SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
24. --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
25. linux02,16020,1684200651886 |           doit:test,,1684207546572.0f550ec8fa1af0ab9e73032d224d9f00. |            | rowkey_015 |     0 |     0 |        0.0 |
26. linux02,16020,1684200651886 | doit:test,rowkey_015,1684207546572.09a2022c54dfef68866ac73e3f78bc70. | rowkey_015 | rowkey_025 |     0 |     0 |        0.0 |
27. linux02,16020,1684200651886 | doit:test,rowkey_025,1684207502853.80d7feace447978ffe4a54418a20afd0. | rowkey_025 | rowkey_030 |     0 |     0 |        0.0 |
28. linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
29. linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
30. 5 rows
31. Took 0.0241 seconds

复制代码

bulkLoad实现批量导入

bulkloader ： 一个用于批量快速导入数据到hbase的工具/方法
用于已经存在一批巨量静态数据的情况！如果不用bulkloader工具，则只能用rpc请求，一条一条地通过rpc提交给regionserver去插入，效率极其低下
原理


相比较于直接写HBase，BulkLoad主要是绕过了写WAL日志这一步，还有写Memstore和Flush到磁盘，从理论上来分析性能会比Put快！
importTsv工具

原理：
Importtsv是hbase自带的一个 csv文件--》HFile文件 的工具，它能将csv文件转成HFile文件，并发送给regionserver。它的本质，是内置的一个将csv文件转成hfile文件的mr程序！

1. # CSV转HFILE的命令示例如下：
2. # 001,北戴河,河北省,河北省北戴河昌平区沙河镇赋腾国际创客中心A座4018室
3. hbase  org.apache.hadoop.hbase.mapreduce.ImportTsv \
4. -Dimporttsv.separator=, \
5. -Dimporttsv.columns='HBASE_ROW_KEY,f:city,f:province,x:address'  \
6. -Dimporttsv.bulk.output=/tsv/output \
7. user_info \
8. /tsv/input

复制代码

ImportTsv命令的参数说明如下：
-Dimporttsv.skip.bad.lines=false - 若遇到无效行则失败
-Dimporttsv.separator=, - 使用特定分隔符,默认是tab也就是\t
-Dimporttsv.timestamp=currentTimeAsLong - 使用导入时的时间戳
-Dimporttsv.mapper.class=my.Mapper - 使用用户自定义Mapper类替换TsvImporterMapper
-Dmapreduce.job.name=jobName - 对导入使用特定mapreduce作业名
-Dcreate.table=no - 避免创建表，注：如设为为no，目标表必须存在于HBase中
-Dno.strict=true - 忽略HBase表列族检查。默认为false
-Dimporttsv.bulk.output=/user/yarn/output 作业的输出目录

hfile

逻辑数据组织格式

• Scanned block section：表示顺序扫描HFile时（rile时（包含所有需要被读取的数据）所有的数据块将会被读取，包括Leaf Index Block和Bloom Block；
  
• Non-scanned block section：HFile顺序扫描的时候该部分数据不会被读取，主要包括Meta Block和Intermediate Level Data Index Blocks两部分；
  
• Load-on-open-section：这部分数据在HBase的region server启动时，需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index等各种索引的元数据信息；
  
• Trailer：这部分主要记录了HFile的基本信息、各个部分的偏移值和寻址信息。
  
• Data Block：主要存储用户的key，value信息
  
• Meta Block：记录布隆过滤器的信息
  
• Root Data Index：DataBlock的根索引以及MetaBlock和Bloom Filter的索引
  
• Intermediate Level Index:DataBlock的第二层索引
  
• Leaf Level Index：DataBlock的第三层索引，即索引数的叶子节点
  
• Fileds for midKey:这部分数据是Optional的，保存了一些midKey信息，可以快速地定位到midKey,常常在HFileSplit的时候非常有用
  
• MetaIndex:即meta的索引数据，和data index类似，但是meta存放的是BloomFilter的信息
  
• FileInfo:保存了一些文件的信息，如lastKey,avgKeylen,avgValueLen等等
  
• Bloom filter metadata:是布隆过滤器的索引
  

物理数据结构图


数据的读取

• Client访问zookeeper，获取hbase:meta所在RegionServer的节点信息
  
• Client访问hbase:meta所在的RegionServer，获取hbase:meta记录的元数据后先加载到内存中，然后再从内存中根据需要查询的RowKey查询出RowKey所在的Region的相关信息（Region所在RegionServer）
  
• Client访问RowKey所在Region对应的RegionServer，发起数据读取请求
  
• 读取memstore中的数据，看是否有key对应的value的值
  
• 不管memstore中有没有值，都需要去读取Hfile中的数据(再读取Hfile中首先通过索引定位到data block)
  
• 判断cache block中中是否已经加载过需要从文件中读取的bloom block和data block，如果加载过了，就直接读取cache block中的数据，如果没有，就读取文件中的block数据
  
• 将memstore和Hfile中读取的数据汇总取正确的数据返回给客户端
  

rowkey的设计

设计的三大原则

• Rowkey长度原则
  

Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议设计在10-100个字节，不过建议是越短越好，不要超过16个字节
原因如下：

• 数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响Hfile的存储效率；
  
• MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率降低，系统将无法缓存更多的数据，这会降低检索效率，因此Rowkey的字节长度越短越好。
  
• 目前操作系统一般都是64位系统，内存8字节对齐，空值在16个字节，8字节的整数倍利用操作系统的最佳特性。
  

• Rowkey散列原则
  

如果Rowkey是按时间戳的方式递增，因为rowkey是按照字典顺序排序的，这样会出现大量的数据插入到一个reion中，而其他的region相对比较空闲从而造成热点问题，所以尽量不要将开头相同的内容作为rowkey造成热点问题，可以将时间戳反转后在作为rowkey。

• Rowkey唯一原则
  

必须在设计Rowkey上保证其唯一性。否则前面插入的数据将会被覆盖。
常见的避免热点的方法以及它们的优缺点

加盐
这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，以避免热点。
哈希
哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据
反转
第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。
比如手机号的反转，时间戳的反转，当一个连续递增的数字类型想要作为rowkey时，可以用一个很大的数去减这个rowkey，反转后再当成rowkey

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！