Hbase中的region和rowkey-Toy模板网

这篇具有很好参考价值的文章主要介绍了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结构

Hbase中的region和rowkey

数据的写入

Hbase中的region和rowkey

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 执行一次

<!--表示至少需要三个满足条件的store file时，minor compaction才会启动-->
<property>
        <name>hbase.hstore.compactionThreshold</name>
        <value>3</value>
</property>

<!--表示一次minor compaction中最多选取10个store file-->
<property>
        <name>hbase.hstore.compaction.max</name>
        <value>10</value>
</property>

<!--默认值为128m,
表示文件大小小于该值的store file 一定会加入到minor compaction的store file中
-->
<property>
        <name>hbase.hstore.compaction.min.size</name>
        <value>134217728</value>
</property>

<!--默认值为LONG.MAX_VALUE，表示文件大小大于该值的store file 一定会被minor compaction排除-->
<property>
        <name>hbase.hstore.compaction.max.size</name>
        <value>9223372036854775807</value>
</property>

major compaction（大合并）

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

线程先检查小文件数是否大于配置3，一旦大于就会触发compaction。
大文件周期性合并成Major Compaction
如果不满足，它会接着检查是否满足major compaction条件
如果当前store中hfile的最早更新时间早于某个值mcTime就会触发major compaction 
(默认7天触发一次，可配置手动触发)

<!--默认值为7天进行一次大合并，-->
<property>
        <name>hbase.hregion.majorcompaction</name>
        <value>604800000</value>
</property>

手动合并

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

# 造数据
truncate 'doit:test'
put 'doit:test','001','f1:name','zss'
put 'doit:test','002','f1:name','zss'
put 'doit:test','003','f1:name','zss'
put 'doit:test','004','f1:name','zss'
flush 'doit:test'                    
put 'doit:test','005','f1:name','zss'
put 'doit:test','006','f1:name','zss'
put 'doit:test','007','f1:name','zss'
put 'doit:test','008','f1:name','zss'
flush 'doit:test'                    
put 'doit:test','009','f1:name','zss'
put 'doit:test','010','f1:name','zss'
put 'doit:test','011','f1:name','zss'
put 'doit:test','012','f1:name','zss'
flush 'doit:test'
put 'doit:test','013','f1:name','zss'
put 'doit:test','014','f1:name','zss'
put 'doit:test','015','f1:name','zss'
put 'doit:test','016','f1:name','zss'
flush 'doit:test'
put 'doit:test','017','f1:name','zss'
put 'doit:test','018','f1:name','zss'
put 'doit:test','019','f1:name','zss'
put 'doit:test','020','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'
put 'doit:test','025','f1:name','zss'
put 'doit:test','026','f1:name','zss'
put 'doit:test','027','f1:name','zss'
put 'doit:test','028','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'

put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'

# 每次flush一下都会在底层生成一个小文件

Hbase中的region和rowkey

##使用major_compact命令
major_compact tableName

major_compact 'doit:test'

Hbase中的region和rowkey

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

手动合并

hbase(main):025:0> list_regions 'doit:test'
                 SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
 --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
 linux03,16020,1684200651855 |           doit:test,,1684205468848.920ae3e043ad95890c4f5693cb663bc5. |            | rowkey_010 |     0 |     0 |        0.0 |
 linux01,16020,1684205091382 | doit:test,rowkey_010,1684207066858.5e04eb75e5510ad65a0f3001de3c7aa0. | rowkey_010 | rowkey_015 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_015,1684207066858.ed1b328ca4c485d4fa429922f6c18f0b. | rowkey_015 | rowkey_020 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_020,1684205468848.25d62e8cc2fdaecec87234b8d28f0827. | rowkey_020 | rowkey_030 |     0 |     0 |        0.0 |
 linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
 linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
 6 rows
Took 0.0299 seconds
hbase(main):026:0> merge_region 'doit:test,,1684205468848.920ae3e043ad95890c4f5693cb663bc5.','doit:test,rowkey_010,1684207066858.5e04eb75e5510ad65a0f3001de3c7aa0.'
Took 1.2638 seconds
hbase(main):027:0> list_regions 'doit:test'
                 SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
 --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
 linux03,16020,1684200651855 |           doit:test,,1684207066859.cdc1226d634c0cf16f58832637f485b6. |            | rowkey_015 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_015,1684207066858.ed1b328ca4c485d4fa429922f6c18f0b. | rowkey_015 | rowkey_020 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_020,1684205468848.25d62e8cc2fdaecec87234b8d28f0827. | rowkey_020 | rowkey_030 |     0 |     0 |        0.0 |
 linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
 linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
 5 rows
Took 0.0271 seconds

手动拆分

hbase(main):029:0> list_regions 'doit:test'
                 SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
 --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
 linux03,16020,1684200651855 |           doit:test,,1684207066860.8ebf4555c58bd0e5fedae5d4efbe4235. |            | rowkey_030 |     0 |     0 |        0.0 |
 linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
 linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
 3 rows
Took 0.0329 seconds
hbase(main):030:0> split 'doit:test,,1684207066860.8ebf4555c58bd0e5fedae5d4efbe4235.','rowkey_025'
Took 0.1179 seconds
hbase(main):031:0> list_regions 'doit:test'
                 SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
 --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
 linux02,16020,1684200651886 |           doit:test,,1684207502853.af0819bd7f6daa9db2a8f994fb41682d. |            | rowkey_025 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_025,1684207502853.80d7feace447978ffe4a54418a20afd0. | rowkey_025 | rowkey_030 |     0 |     0 |        0.0 |
 linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
 linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
 4 rows
Took 0.0179 seconds
hbase(main):032:0> split 'doit:test,,1684207502853.af0819bd7f6daa9db2a8f994fb41682d.','rowkey_015'
Took 0.1262 seconds
hbase(main):033:0> list_regions 'doit:test'
                 SERVER_NAME |                                                          REGION_NAME |  START_KEY |    END_KEY |  SIZE |   REQ |   LOCALITY |
 --------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
 linux02,16020,1684200651886 |           doit:test,,1684207546572.0f550ec8fa1af0ab9e73032d224d9f00. |            | rowkey_015 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_015,1684207546572.09a2022c54dfef68866ac73e3f78bc70. | rowkey_015 | rowkey_025 |     0 |     0 |        0.0 |
 linux02,16020,1684200651886 | doit:test,rowkey_025,1684207502853.80d7feace447978ffe4a54418a20afd0. | rowkey_025 | rowkey_030 |     0 |     0 |        0.0 |
 linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |     0 |     0 |        0.0 |
 linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |            |     0 |     0 |        0.0 |
 5 rows
Took 0.0241 seconds

bulkLoad实现批量导入

bulkloader ：一个用于批量快速导入数据到hbase的工具/方法

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

原理

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

importTsv工具

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

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

逻辑数据组织格式

Hbase中的region和rowkey

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:是布隆过滤器的索引

物理数据结构图

Hbase中的region和rowkey

数据的读取

Hbase中的region和rowkey

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文章来源地址https://www.toymoban.com/news/detail-481417.html

到了这里，关于Hbase中的region和rowkey的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

Hbase中的region和rowkey

region

region的分配

region结构

数据的写入

Memstore Flush流程

Compact 合并机制

自动合并：

手动合并

region的拆分

region的拆分策略

手动合并拆分region

bulkLoad实现批量导入

原理

importTsv工具

hfile

逻辑数据组织格式

物理数据结构图

数据的读取

rowkey的设计

设计的三大原则

常见的避免热点的方法以及它们的优缺点

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏

支付宝扫一扫领取红包，优惠每天领

二维码1

二维码2