Hbase读写流程

Hbase读写数据流程

regionserver

HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成,每个HStore对应了Table中的一个Column Family的存储，

可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效

HStore存储由两部分组成，一部分是MemStore(内存)，一部分是StoreFiles(磁盘)

容错与恢复

每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）

 

WAL就像日志中心一样，它被同一个region server中的所有region共享。

当客户端启动一个操作来修改数据，该操作便会被封装成一个KeyValue对象实例中，并通过RPC调用发送出去。

这些调用成批的发送给含有匹配region的HRegionServer。一旦KeyValue到达，它们会被发送到管理相应行的HRegion对象实例。数据便被写入到WAL，然后放入到实际拥有记录的存储文件的MemStore中。

最后当memstore达到一定的大小或者经历一个特定时间之后，数据就会异步地连续写入到文件系统中。

在写入的过程中，数据以一种不稳定的状态存放在内容中，即使在服务器完全崩溃的情况下，WAL也能够保证数据不丢失，因为实际的日志存储在HDFS上。其他服务器可以打开日志然后回放这些修改。

当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在LoadRegion的过程中，会发现有历史HLog需要处理，因此会ReplayHLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复

每个Region Server维护一个Hlog，而不是每个Region一个。

这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。

带来的麻烦是，如果一台Region Server下线，为了恢复其上的Region，需要将Region Server上的log进行拆分，然后分发到其它Region Server上进行恢复。

 

1 客户端寻找HRegionServer，及缓存位置信息

 

从这个过程中，我们发现客户会缓存这些位置信息，然而第二步它只是缓存当前RowKey对应的HRegion的位置，因而如果下一个要查的RowKey不在同一个HRegion中，则需要继续查询hbase:meta所在的HRegion，然而随着时间的推移，客户端缓存的位置信息越来越多，以至于不需要再次查找hbase:meta Table的信息，除非某个HRegion因为宕机或Split被移动，此时需要重新查询并且更新缓存。

2 写数据流程

1）通过2.3.1 找到该写数据最终需要去的HRegionServer；

2）然后客户端将写请求发送给相应的HRegionServer，在HRegionServer中它首先会将该写操作写入WAL（Hlog）日志文件中(Flush到磁盘中)。

3）写完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey，startkey、endkey找到对应的HRegion，并根据Column Family找到对应的HStore，并将Put写入到该HStore的MemStore中。此时写成功，并返回通知客户端。

 

写入MemStore后的操作：

存入MemStore，一直到MemStore满 

→ Flush成一个StoreFile，直至增长到一定阈值

→ 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除

→ 当StoreFiles Compact后，逐步形成越来越大的StoreFile

→单个StoreFile大小超过一定阈值（Region split 阈值）后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上；

 

什么时候执行MemStore Flush？

1）当一个MemStore的大小超过了hbase.hregion.memstore.flush.size的大小，此时当前的HRegion中所有的MemStore会Flush到HDFS中，不阻塞写操作。（Region级别的flush）

2）当全局MemStore的大小超过了hbase.regionserver.global.memstore.upperLimit（默认0.4，memstores所占最大堆空间比例）的大小，此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，阻塞写操作。（RS级别的flush）

3）当一个Region的MemStore总量达到hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size（默认2*128M=256M）时，会阻塞这个region的写操作，并强制刷写到HDFS。

触发这个刷新只会发生在MemStore即将写满128M时put了一个巨大的记录的情况，这时会阻塞写操作，强制刷新成功才能继续写入。（Region级别的flush）

4）当前HRegionServer中HLog的大小超过阈值，当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中。（RS级别的flush）

 

3 读数据流程

1）通过2.3.1 找到要读的数据的HRegionServer。

2）根据读取的TableName和RowKey的startkey 、 endkey 找到对应的HRegion。

4）每个regionserver只有一个blockcache（读缓存），读取数据时，先到memestore上读数据，找不到再到blockcahce上找数据，再查不到则到磁盘（storefile）查找，并把读入的数据同时放入blockcache。

 

4 Region拆分策略

Region概念

一个Table由一个或多个Region组成

一个Region由一个或者多个Store组成，每个store保存一个columns family；

一个Strore又由一个memStore和0至多个StoreFile 组成。memStore存储在内存中， StoreFile存储在HDFS上。

 

Region大小考量的因素

1）机器个数多，Region个数少，浪费机器，region数目太少就会妨碍可扩展性，降低并行能力，导致压力不够分散；

2）region小，数目太多就会造成性能下降；

 

Region拆分策略

HRegionServer拆分region的步骤是，先将该region下线，然后拆分，将其子region加入到hbase:meta表中，再将他们加入到原本的HRegionServer中，最后汇报Master。

 

split前

hbase:meta:   region_p

split中

region_p  ---> region1

                       region2

在 region_p  对应的hdfs目录下生成.splits 目录， 里面创建 两个子region的引用文件

tablename/region_p_md5/.splits/region1 引用文件

                                                   /region2 引用文件

在表目录下创建子region对应的hdfs目录， 把引用文件拷贝到 指定region目录下

tablename/region1_md5/region1 引用文件

                 /2region_md5/region2 引用文件

split后

把子region往hbase:meta表里写

hbase:meta

region_p

region1

region2

两个子region从父region获取数据，当数据获取完，删除相应的引用文件

汇报hmaster

可以通过设置RegionSplitPolicy的实现类来指定拆分策略，RegionSplitPolicy类的实现类有：

 

ConstantSizeRegionSplitPolicy

IncreasingToUpperBoundRegionSplitPolicy

DelimitedKeyPrefixRegionSplitPolicy

KeyPrefixRegionSplitPolicy

其中：

ConstantSizeRegionSplitPolicy

仅当region大小超过常量值（hbase.hregion.max.filesize大小,默认为10G）时，才进行拆分。

 

IncreasingToUpperBoundRegionSplitPolicy

默认region split策略。即当同一table在同一regionserver上的region数量在[0,100)之间时按照如下的计算公式算，否则按照上一策略计算：

Min (R^3* "hbase.hregion.memstore.flush.size"*2, "hbase.hregion.max.filesize")

        R为同一个table中在同一个regionserver中region的个数，

        hbase.hregion.memstore.flush.size默认为128M，

        hbase.hregion.max.filesize默认为10G。

第一次分裂:    1*1*1*128*2 = 256 --> 1 --> 2

第二次分裂：  2*2*2*128*2 = 2048 --> 2 --> 4

第三次分裂 : 4 * 4 * 4 * 128 * 2

一个表的region 越分越多 --> hmaster --> 平衡 --> RS --> region 移动(慢)

预分 region 表 数据 --> 够大 -- 分region

表 --> 分出region --> rowkey(范围识别) --> hive的分区 先分区 再存储 数据

 

 

DelimitedKeyPrefixRegionSplitPolicy

保证以分隔符前面的前缀为splitPoint，保证相同RowKey前缀的数据在一个Region中。如果定义rowkey时，采用'_'作为字段分隔符(如：userid_eventid)，则采用该策略拆分之后，能够确保具有相同userid的记录隶属于同一Region。

假设分割字段是 “_”

userid_eventid     -->    userid

userid_aaaid

username_aaa    --->   username

username_bb

 

KeyPrefixRegionSplitPolicy                    

保证具有相同前缀的row在一个region中（要求设计中前缀具有同样长度）。指定rowkey前缀位数划分region，通过读取table的prefix_split_key_policy.prefix_length属性，该属性为数字类型，表示前缀长度，在进行split时，按此长度对splitPoint进行截取。

此种策略比较适合固定前缀的rowkey。当table中没有设置该属性，或其属性不为Integer类型时，指定此策略效果等同与使用IncreasingToUpperBoundRegionSplitPolicy。

假设 prefix_split_key_policy.prefix_length=9

userid001_aaa      -->    userid001

userid001_bbb

userid002_aaa      -->    userid002

userid002_bbb

 

 

配置拆分策略

hbase配置文件中定义全局的拆分策略，设置hbase.regionserver.region.split.policy；也可以在创建和修改表时候指定。

如果想关闭自动拆分改为手动拆分，建议同时修改hbase.hregion.max.filesize和hbase.regionserver.region.split.policy值。

如果关闭自动拆分策略需要把 hbase.hregion.max.filesize 设置非常大，再采用手动。

• 点赞
• 收藏
• 分享
• • 文章举报

爱吃芝麻 发布了107 篇原创文章 · 获赞 0 · 访问量 1240 私信 关注

标签：hbase,HRegion,流程,读写,region,MemStore,HRegionServer,Hbase,Region
来源： https://blog.csdn.net/weixin_43006131/article/details/104161094