Hbase高级

谁借莪１个温暖的怀抱￠ 2022-11-26 07:38 145阅读 0赞

### 目录 ###

*   *  RegionServer 架构
     *   *   *  总结
     *  写流程
     *   *   *  总结
     *  读流程
     *   *   *  总结
     *  MemStore Flush
     *   *   *   *  总结
     *  StoreFile Compaction
     *   *   *  总结
     *  Region Split
     *   *   *  总结

## RegionServer 架构 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70]  
1）StoreFile  
保存实际数据的物理文件，StoreFile以Hfile的形式存储在HDFS上。每个Store会有一个或多个StoreFile（HFile），数据在每个StoreFile中都是有序的。  
2）MemStore  
写缓存，由于HFile中的数据要求是有序的，所以数据是先存储在MemStore中，排好序后，等到达刷写时机才会刷写到HFile，每次刷写都会形成一个新的HFile。  
3）WAL  
由于数据要经MemStore排序后才能刷写到HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写在一个叫做Write-Ahead logfile的文件中，然后再写入MemStore中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。  
每间隔hbase.regionserver.optionallogflushinterval(默认1s)， HBase会把操作从内存写入WAL。  
一个RegionServer上的所有Region共享一个WAL实例。  
WAL的检查间隔由hbase.regionserver.logroll.period定义，默认值为1小时。检查的内容是把当前WAL中的操作跟实际持久化到HDFS上的操作比较，看哪些操作已经被持久化了，被持久化的操作就会被移动到.oldlogs文件夹内（这个文件夹也是在HDFS上的）。一个WAL实例包含有多个WAL文件。WAL文件的最大数量通过hbase.regionserver.maxlogs（默认是32）参数来定义。  
4）BlockCache  
读缓存，每次查询出的数据会缓存在BlockCache中，方便下次查询。

#### 总结 ####

1.进程组成

master(1个)： 负责对表的增删改查
    	master负责分配region到regionserver，自动监控rs的状态
    				 
    	在一个集群中，工作状态的master只能有一个，可以有多个备用的！
    				
    regionserver:  负责接受客户端的请求，对数据进行读写操作！
    	负责对region进行处理，例如region的切分和合并！
    						
    						
    		
    zookeeper: hbase需要依赖zookeeper保存一些元数据信息！

2.regionserver的架构

regionserver负责接受客户端的请求，对数据进行读写操作！
    		
        一个region由一个regionserver负责！
    	一个regionserer可以同时负责多个region的请求！
    		
    regionserver中有以下组件：
    ①一个regionserver有一个WAL对象，这个WAL对象负责当前regionserver的预写日志！
    预写日志主要为了防止memstore中的数据没有及时刷写到磁盘时，丢失，如果丢失可以使用预写日志恢复！
    			
    ②每个region都有多个列族，每个列族会创建一个store对象，一个store对象会维持
    一个memstore(写缓冲区)存储数据，并且在这个列族的目录中有多少个文件，就会创建多少个storefile对象，对应文件！
    				
    ③blockcache(读缓存): 客户端经常查询的数据，会放入到blockcache中，如果blockcache中
    有对应的数据，就不会再扫描storefile！

## 写流程 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 1]  
写流程：  
1）Client先访问zookeeper，获取hbase:meta表位于哪个Region Server。  
2）访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。  
3）与目标Region Server进行通讯；  
4）将数据顺序写入（追加）到WAL；  
5）将数据写入对应的MemStore，数据会在MemStore进行排序；  
6）向客户端发送ack；  
7）等达到MemStore的刷写时机后，将数据刷写到HFile。

#### 总结 ####

1.查看hfile

hbase org.apache.hadoop.hbase.io.hfile.HFile -e -p -f hdfs://xxx

2.写流程

找插入数据对应的rs:
    ①请求zookeeper，查询 /hbase/meta-region-server 节点，获取meta表所在的rs
    ②向meta表所在的rs发送读请求，讲读取到的内容缓存到客户端本地，此后就不需要频繁查询
    meta表
    ③从meta表中，根据region和regionserver的对应关系，找到rowkey所属的region的regionserver
    	写入数据：
    ④向regionserver发put请求，regionserver会使用WAL对象记录写请求，
    将写的数据，存储在memstore中
    ⑤响应客户端，写操作完成
    		
    
    写入数据的微观流程：
    	①尝试尽可能获取多个锁，至少需要获取一把
    	②如果当前数据没有设置时间戳，更新时间戳
    	③构建WAL对象
    	④写入WAL对象的buffer中，但是并不sync到磁盘
    	⑤写入memstore
    	⑥讲WAL对象buffer中的数据sync到磁盘
    	⑦滚动MVCC版本号，滚动后，客户端就可以查询到数据
    	⑧如果在整个写入过程中发生异常，此时，会讲已经写入到memstore中的数据回滚！

## 读流程 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 2]  
读流程  
1）Client先访问zookeeper，获取hbase:meta表位于哪个Region Server。  
2）访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。  
3）与目标Region Server进行通讯；  
4）分别在Block Cache（读缓存），MemStore和Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。  
5）将查询到的数据块（Block，HFile数据存储单元，默认大小为64KB）缓存到Block Cache。  
6）将合并后的最终结果返回给客户端。

#### 总结 ####

读流程

找到所读数据的Regionserver
    ①客户端请求zk的 /hbase/meta-region-server节点，读取到hbase:meta表所在regionserver
    	②请求rs，下载meta表
    	③查询meta表，当前所读region所在的rs
    	④向rs发起读请求
    读数据
    ⑤初始化两种scanner（扫描器）
    	memstorescannner：负责扫描store的memstore区域
    	storefileScanner: 负责扫描store的若干storefile
    			
    ⑥如果扫了storefile，会讲storefile数据所在的block(HFile中的block，64k)缓存到blockcache中
    blockcache是rs的读缓存，默认占用rs所在堆的40%容量，采取LRU回收策略进行缓存的回收！
    		
    此后如果读取的storefile文件已经缓存在blockcache了，那么就会从blockcache中读取数据
    而无需扫描磁盘读取storefile。
    ⑦扫描memstore,storefile,blockcache,取出version（时间戳最大的数据）返回给客户端！

## MemStore Flush ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 3]  
MemStore存在的意义是在写入HDFS前，将其中的数据整理有序。  
MemStore刷写时机：  
1.当某个memstore的大小达到了`hbase.hregion.memstore.flush.size（默认值128M）`，其`所在region的所有memstore都会刷写`。  
当memstore的大小达到了  
**`hbase.hregion.memstore.flush.size（默认值128M）`**  
**`* hbase.hregion.memstore.block.multiplier（默认值4）`**  
时，会`阻止继续`往该memstore写数据。  
2.当region server中memstore的总大小达到  
**`java_heapsize`**  
**`*hbase.regionserver.global.memstore.size（默认值0.4）`**  
**`*hbase.regionserver.global.memstore.size.lower.limit（默认值0.95），`**  
region会按照其所有memstore的大小顺序（由大到小）依次进行刷写。直到region server中所有memstore的总大小减小到上述值以下。  
当region server中memstore的总大小达到  
**`java_heapsize`**  
**`*hbase.regionserver.global.memstore.size（默认值0.4）`**  
时，会阻止继续往所有的memstore写数据。  
3. 到达自动刷写的时间，也会触发memstore flush。自动刷新的时间间隔由该属性进行配置`hbase.regionserver.optionalcacheflushinterval（默认1小时）`。  
4.当WAL文件的数量超过`hbase.regionserver.max.logs`，region会按照时间顺序依次进行刷写，直到WAL文件数量减小到`hbase.regionserver.max.log`以下（**`该属性名已经废弃，现无需手动设置，最大值为32`**）。

##### 总结 #####

1.讲memstore中的数据，刷写到磁盘，生成storefile的过程称为flush!
    		flush的目的是在memstore中对数据的rowkey进行排序，排序后刷写到磁盘后的数据
    		是有序的，方便检索！
    		
    2. 实现flush
    		hbase shell:  flush '表名'| 'region名'
    		
    3. 自动flush
    ①从容量上来说
    a)如果单个memstore使用的容量超过hbase.hregion.memstore.flush.size(默认128M)，
    			整个region的memstore都会刷写！
    			
    			在刷写时，客户端依然可以向rs发起写请求，写的数据依然是存储在memstore中，但是
    			如果memstore使用的容量超过hbase.hregion.memstore.flush.size(默认128M) *
    			hbase.hregion.memstore.block.multiplier（默认值4）,此时memstore会自动block（阻塞）,
    			客户端无法再执行写入！
    			
    b)整个rs所有的memstore使用的容量总和超过java_heapsize
    *hbase.regionserver.global.memstore.size（默认值0.4）
    *hbase.regionserver.global.memstore.size.lower.limit（默认值0.95）
    整个rs所有的memstore会依次按照大小顺序刷写。
    			
    在刷写时，如果rs所有的memstore使用的容量总和超过java_heapsize
    *hbase.regionserver.global.memstore.size（默认值0.4），此时所有的memstore也会block
    			
    ②从时间上来说
    没间隔hbase.regionserver.optionalcacheflushinterval（1h），自动flush
    			
    ③从WAL正在写入的日志数量上来说
    如果有大量的正在使用的WAL日志，说明memstore中有大量尚未刷写的数据，一旦数据过多，
    rs进程崩溃，此时恢复数据时间过长。所以，一旦正在使用的WAL日志文件的数量超过
    hbase.regionserver.max.logs(32)，此时，会根据WAL中记录的日志的先后顺序依次刷写memstore!

## StoreFile Compaction ##

由于Hbase依赖HDFS存储，HDFS只支持追加写。所以，当新增一个单元格的时候，HBase在HDFS上新增一条数据。当修改一个单元格的时候，HBase在HDFS又新增一条数据，只是版本号比之前那个大（或者自定义）。当删除一个单元格的时候，HBase还是新增一条数据！只是这条数据没有value，类型为DELETE，也称为墓碑标记（Tombstone）  
HBase每间隔一段时间都会进行一次合并（Compaction），合并的对象为HFile文件。合并分为两种  
minor compaction和major compaction。  
在HBase进行major compaction的时候，它会把多个HFile合并成1个HFile，在这个过程中，一旦检测到有被打上墓碑标记的记录，在合并的过程中就忽略这条记录。这样在新产生的HFile中，就没有这条记录了，自然也就相当于被真正地删除了  
由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。  
Compaction分为两种，分别是`Minor Compaction`和`Major Compaction`。Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。Major Compaction会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉过期和删除的数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 4]

#### 总结 ####

超过三个文件  使用compact是和major_compact一样的，都会删除delete的数据

目的： 对store中的多个hfile文件定期合并，消除每次flush产生的大量的小文件。
    对hfile中无效的过期的数据，进行合并整理，较少数据量！
    				
    分类：  minor_compact: 将临近的多个小文件，合并为一个大文件。不会删除delete类型的数据(0.94之前)！
    major_compact： 将store目录中所有的文件，合并为一个大文件，会删除delete类型的数据！
    				
    minor_compact和major_compact的区别是minor_compact只能合并有限数量的hfile！
    major_compact是合并目录下所有的文件！
    				
    对于major_compact建议取消自动合并的设置，改为在集群空闲时，手动执行合并！

## Region Split ##

默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的Region Server，但处于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的Region Server。  
Region Split时机：  
1.当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize，该Region就会进行拆分（0.94版本之前）。  
2. 0.94版本之后的切分策略  
默认使用IncreasingToUpperBoundRegionSplitPolicy策略切分region, getSizeToCheck()是检查region的大小以判断是否满足切割切割条件。

protected long getSizeToCheck(final int tableRegionsCount) { 
        // safety check for 100 to avoid numerical overflow in extreme cases
        return tableRegionsCount == 0 || tableRegionsCount > 100
                   ? getDesiredMaxFileSize()
                   : Math.min(getDesiredMaxFileSize(),
                              initialSize * tableRegionsCount * tableRegionsCount * tableRegionsCount);
      }

tableRegionsCount：为当前Region Server中属于该Table的region的个数。  
getDesiredMaxFileSize() 这个值是hbase.hregion.max.filesize参数值，默认为10GB。  
initialSize的初始化比较复杂，由多个参数决定。

@Override
      protected void configureForRegion(HRegion region) { 
        super.configureForRegion(region);
    Configuration conf = getConf();
    //默认hbase.increasing.policy.initial.size 没有在配置文件中指定
        initialSize = conf.getLong("hbase.increasing.policy.initial.size", -1);
        if (initialSize > 0) { 
          return;
    }
    // 获取用户表中自定义的memstoreFlushSize大小，默认也为128M
        HTableDescriptor desc = region.getTableDesc();
        if (desc != null) { 
          initialSize = 2 * desc.getMemStoreFlushSize();
    }
    // 判断用户指定的memstoreFlushSize是否合法，如果不合法，则为hbase.hregion.memstore.flush.size，默认为128. 
        if (initialSize <= 0) { 
          initialSize = 2 * conf.getLong(HConstants.HREGION_MEMSTORE_FLUSH_SIZE,
                                         HTableDescriptor.DEFAULT_MEMSTORE_FLUSH_SIZE);
        }
      }

具体的切分策略为tableRegionsCount在0和100之间，则为  
initialSize（默认为2\*128） \* tableRegionsCount^3,例如：  
第一次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了。  
tableRegionsCount超过100个，则超过10GB才会切分region。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 5]

#### 总结 ####

每张表在创建时，只有一个region.随着这个region中写入数据越来越多，此时，region
    会自动完成切分，切分后的region有可能出于负载均衡的目的，会分配给其他的rs负责！
    		
    自动切分：
    ①统计当前regionserver中负责的 当前表的region个数，称为tableRegionCount
    ②0=tableRegionCount 或 tableRegionCount>100，此时某个region超过hbase.hregion.max.filesize(10G)
    时切分（一分为二）！
    ③0<tableRegionCount<=100,此时使用
    initialSize * tableRegionsCount * tableRegionsCount * tableRegionsCount
    和 hbase.hregion.max.filesize(10G)进行对比取较小值
    					
    ④initialSize，取决于用户的配置，由hbase.increasing.policy.initial.size自定义！
    如果没有自定义通常为 2*hbase.hregion.memstore.flush.size,为 256M

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70]: /images/20221124/f80cd1fbaa574c27b7641ec35215847d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 1]: /images/20221124/d15b954dce12428cab5557bb6895e59a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 2]: /images/20221124/645f74d59edc4b23a2892f98d0a5e3f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 3]: /images/20221124/f9939b19d19845119ff9e30031e0329a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 4]: /images/20221124/a28ce61d75c14daba5edd8158751216b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ2NTQ4ODU1_size_16_color_FFFFFF_t_70 5]: /images/20221124/134f6c4e558f4494b9e9d87f6ac86088.png