深入浅出系列Hbase之架构及读写流程

迈不过友情╰ 2023-02-20 07:08 128阅读 0赞

# Hbase架构设计 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA_size_16_color_FFFFFF_t_70][]

### HMaster ###

> 1.  负责HBASE table和Region的元数据管理，包含表的创建、修改等
> 2.  维护整个集群的负载均衡
> 3.  为RegionServer分配Region
> 4.  发现失效的region，并将失效的region分配到正常的RegionServer
> 5.  当RegionServer失效时，协调对应Hlog的拆分

## HRegionServer ##

> 1.  负责数据的路由，数据的读写和持久化
> 2.  是HBase的数据处理及计算的单元
> 3.  管理master为其分配的region
> 4.  和底层HDFS进行数据存储的交互
> 5.  Region变大以后的拆分以及StoreFile的合并
> 6.  regionserver要和DN一起部署
> 
> hregionserver内部管理了一系列的hregion对象，每个hregion对应table的一个region。hregion是多个store组成，是通过CF划分的，则是一个store管理一个region上的一个CF。每个store是包含 1个memstore 0个或多个storefile组成。

## Zookeeper ##

> 1.  存储meta表的地址，而不是内容！
> 2.  RegionServer主动向ZK注册，使得master可随时感知各个rs的健康状态
> 3.  避免master的单点故障（SPOF）

## HbaseClient ##

> 1.  RPC机制
> 2.  client和master进行ddl管理类通信  和rs进行数据的dml操作类通信

## Hlog ##

> 预写日志

## MemStore ##

> 写缓存

## StoreFile ##

> storefiles 合并后逐步形成越来越大的storefile文件，  
> 当region内所有的storefile(hfile)的总大小超过 hbase.hregion.max.filesize触发split,一个region变为2个。 父region下线，新的split的2个region被hmaster分配到合适的rs机器上。  
> 使得原先1个region的压力分流到2个region上。

## BlockCache ##

> 读缓存，是rs级别 ，一个rs只有一个blockcache ,在rs启动时 完成blockcache的初始化工作。

# Meta表 #

首先说明存储位置是记录在zookeeper上的。

hbase(main):026:0> scan 'hbase:meta'
    ROW                   COLUMN+CELL                                                
     hbase:namespace,,159 column=info:regioninfo, timestamp=1590821040270, value={ENC
     0821039635.0be1ccc4d ODED => 0be1ccc4de45f61db028e2081d5d673b, NAME => 'hbase:na
     e45f61db028e2081d5d6 mespace,,1590821039635.0be1ccc4de45f61db028e2081d5d673b.', 
     73b.                 STARTKEY => '', ENDKEY => ''}                              
     hbase:namespace,,159 column=info:seqnumDuringOpen, timestamp=1590821040270, valu
     0821039635.0be1ccc4d e=\x00\x00\x00\x00\x00\x00\x00\x02                         
     e45f61db028e2081d5d6                                                            
     73b.                                                                            
     hbase:namespace,,159 column=info:server, timestamp=1590821040270, value=xxx:60020
     0821039635.0be1ccc4d                                                  
     e45f61db028e2081d5d6                                                            
     73b.                                                                            
     hbase:namespace,,159 column=info:serverstartcode, timestamp=1590821040270, value
     0821039635.0be1ccc4d =1590821031895                                             
     e45f61db028e2081d5d6                                                            
     73b.   
    
    
     xxx:orderinfo,       column=info:regioninfo, timestamp=1590827295617, value={ENC
     ,1590826706747.2ce50 ODED => 2ce500c927ace1d96d365f4bdb3930c3, NAME => 
     0c927ace1d96d365f4bd 'xxx:orderinfo,,1590826706747.2ce500c927ace1d96d365f4bdb3930c3
     xxx:orderinfo,,15908 b3930c3. ', STARTKEY => '', ENDKEY => ''} 
     26706747.2ce500c927a column=info:seqnumDuringOpen, timestamp=1590827295617, 
     ce1d96d365f4bdb3930c value=\x00\x00\x00\x00\x00\x00\x00\x11
     3.                                                                                             
     xxx:orderinfo,,15908 column=info:server, timestamp=1590827295617, value=xxx:60020
     26706747.2ce500c927a
     ce1d96d365f4bdb3930c
     3.                                                                        
     xxx:orderinfo,,15908 column=info:serverstartcode, timestamp=1590827295617, value
     26706747.2ce500c927a =1590821031895 
     ce1d96d365f4bdb3930c3.                                                                        
    2 row(s) in 0.0260 seconds
    
    hbase(main):027:0>

通过上面两行的元数据信息，我们可以知道：

> rowkey组成: ns:table,region start key,region id
> 
> region start key： 是region的第一个rowkey，这里需要注意  
> a.这个地方为空，就表明table是第一个region，并且这个region的start key end key 都是空，说明这个表只有一个region  
> b.在meta表，start key 靠前的region 会排在start key靠后的region的前面。  
> hbase的key是按照字段的顺序来存放的  字典排序
> 
> region id: 是region创建的时候的timestamp+.+region id
> 
>   
> value组成:
> 
> regioninfo  包含 start key end key  
> server      是分配在哪个rs节点上

# 写流程 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA_size_16_color_FFFFFF_t_70 1][]

> 1、client先去zk获取hbase:meta表所在的rs节点，在hbase:meta表根据rk确定所在的目标rs节点和region  
> 2、hbase client将写的请求进行预处理，并根据元数据写入所在的rs节点；将请求发送给对应的rs,rs接收到写的请求将数据进行解析：  
>      先写wal-->再写对应的region的store的memstore，当memstore达到阈值，会异步的flush，将内存的数据写入HFile文件 
> 
> 注意： memstore是一个内存结构  是一个CF只有1个memstore，其中memstore里面的数据也是对rk进行字典排序的

hbase是采取**LSM树**架构，【天生的适合重写轻读的场景】  
注意:

对hbase来说 put（更新）、delete操作，在服务端看来 都是写操作。
        put更新 是写一条 最新版本数据
        delete  是写一条标记为deleted的kv的数据

# 读流程 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA_size_16_color_FFFFFF_t_70 2][]

> a.先去zk获取hbase:meta表所在的rs节点，在hbase:meta表根据读rk确定所在的目标rs节点和region  
> b.将读请求封装，发送给目标的rs节点，进行处理。  
> 先到memstore查数据，查不到再去blockcache查，再查不到就访问磁盘的HFile读数据。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200624150154892.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200624171130638.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200624173054128.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N6ejExNDE5Nzk1NzA=,size_16,color_FFFFFF,t_70