HBase系统架构

  1. 云栖社区>
  2. 博客列表>
  3. 正文

HBase系统架构

友德 2018-07-11 09:29:28 浏览4763 评论0

摘要: 1 HBase整体架构 1.1 HMaster 1.2 HRegionServer 2 HBase 客户端读数据流程分析 3 HBase 客户端写数据流程分析 4 HBase服务端读数据流程分析 5 HBase服务端写数据流程分析 6 HBase服务端删除和increase操作 7 Region分...

1 HBase整体架构
1.1 HMaster
1.2 HRegionServer
2 HBase 客户端读数据流程分析
3 HBase 客户端写数据流程分析
4 HBase服务端读数据流程分析
5 HBase服务端写数据流程分析
6 HBase服务端删除和increase操作
7 Region分裂和合并问题分析
8 HBase主备集群数据同步分析

分享的目的

更进一步地深入掌握HBase的内核架构

1 HBase整体架构

整体架构图:
1.png

1.1 HMaster

  1. HMaster没有单点问题,HBase中可以启动多个HMaster,通过Zookeeper的Master Election机制保证总有一个Master运行,HMaster在功能上主要负责Table和Region的管理工作:

    1. 管理用户对Table的增、删、改、查操作(admin操作);
    2. 管理HRegionServer的负载均衡,调整Region分布;
    3. 在Region 合并分裂后,负责新的Region重新分配;
    4. 在HRegionServer停机后,负责失效HRegionServer 上的Regions迁移;
  2. HMaster是保证HBase高可靠的因素之一;
  3. 线上环境 ,HMaster是般由两到三台组成,普通(24G)的虚拟机;

1.2 HRegionServer

  1. HRegionServer是存储实际Region,响应客户端写入的IO,并负责存储数据到HDFS中,是HBase最核心的部分;
    2.理论上HRegionServer是可以无限扩容的,这也是为什么说HBase是一个存储海量数据的数据库;
  2. 在生产环境中,通常HRegionServer和HDFS部署在相同的机器上,并且最好要在同一个大交换机下面的端口;
  3. HRegionServer机器的配置要求: CPU内核数越多、内存越大、硬盘越大越好,当然regionServer的JVM堆内存不是越大越好,通常建议不要超过32G,过大,会有严重的Full GC问题,而且在64位的JVM中,堆大小超过32G,指针不能做压缩;
  4. 一台HRegionServer上有多个HRegion, 一个HRegion上有多个Hstore,一个family对应一个HStore ,一个Hstore上有多个StoreFile和一个MemStore ,HBase用LSM树来组织这些StoreFile和MemStore, 因为LSM树这种数据结构只适合写,不太适合读, 而B+树适合读,不太适合写 ,因此这才是HBase是一种适合写多读少的数据库的根本原因, 而mysql关系型数据库适合读多写少的应用场景。下面是LSM树和B+树的数据结构:
    2.png

2 HBase 客户端读数据流程分析

流程图
3.jpg

  1. 第一次读写数据, 需要定位相关Region所在的HRegionServer机器:

        1.HBase客户端先根据HBase的zk上的相关结点的内容定位到.Meta表所在的HRegionServer服务器的主机,并在客户端本地做相关的缓存; 
    1. HBase客户端和-Meta表所在的HRegionServer服务器通过rpc通信,获取相关的rowKey记录所在Region信息(包括该region所在的HRegionServer的机器名和IP), 并在客户端本地做相关的缓存,以后就不用再查找;
  2. 第二或第二次以后读写数据

        通过查找客户端本地的缓存,直接和相关的HRegionServer进行通信,进行相关的数据读操作; 
    

3 HBase 客户端写数据流程分析

流程图
4.jpg

  1. 如果autoFlush为true, 默认也为true, 如果单个写Put不是特别大的情况下,没是步骤4;如果单 个写Put特别大,还是会有步骤4;
  2. 如果客户端批量写,很容易出现客户端缓存超出的现象,还是会有步骤4, 如果一次提交的特别多,还是建议适当设置hbase.client.write.buffer的大小,建议不超过5M;
  3. 如果可以接受一部分数据丢失的可能,为了提高写入的吞吐量,可以在写入时在HTable上设置autoFlush 为false

HBase服务端读写据流程分析

1. 服务端核心类:

org.apache.hadoop.hbase.regionserver.HRegion

2. HBase源码模块名称:

hbase-server
5.jpg

4 服务端读数据流程分析

以get(final Get get)为例进行分析
6.png
代码层面如下两个主要的方法:
scanner = getScanner(scan);
scanner.next(results);
HBase regionServer读取数据主要有两个步骤:

    1. 根据Get对象生成相关的RegionScanner对象, 在这个过程中可以充分利用布隆过滤器和时间戳, RegionScanner对象主要包括多个StoreScanner,一个StoreScanner下面包含多个StoreFileScanner和一个MemStoreScanner,当然每个StoreFile下面有多个HFile;
    2. 调用next方法, 即扫描StoreFile和和MemStore, 依次查找每一个每符合要求的cell(当然在查找的过程中会有相关的缓存,在这里提一下,阿里HBase团队出一种针对SSD存储的BucketCache),并填充结果集;

5 服务端写数据流程分析

  1. 检查该region 写的状态是不是只能读,如果是只能读,就抛出异常结束;
  2. 检查该region 资源, 主要包含两个方面

    2.1 检查该region是不是.meta Region, 如果是.meta Region ,就直接返回结束;
    2.2 检查该region当前所有的memStore的大小,是不是超过了已经配置的刷写大小的2倍,如果超过
          这个值,就把memStore的数据全部刷到HDFS中, 然后抛出RegionTooBusyException
          的异常, 这个刷写的大小由blockingMemStoreSize 控制,而blockingMemStoreSize由
          hbase.hregion.memstore.flush.size(默认值是128M)和hbase.region.memstore.block.multiplier(默
          认值为2)的乘积确定,即 blockingMemStoreSize默认值为256M;  
  3. 如果步骤2没检查通过,就进入下面写入主流程:
    7.png

注意: 如果一次put的数据比较 多,3的步骤要反复执行多次,并且每次循环都要先开始执行依次步骤1和

     步骤2的检查操作。

重要: 在刷日志 这步骤中,需要根据建表时是否设置 同步写入WAL,以及WAL同步到HDFS中要求,会

     有很大的不同,默认是写一次操作,WAL要刷一次HDFS, 这是最安全的,但写入性能不是很
     高,设置 成异步刷盘(ASYNC_WAL)比较好性能最好(默认1s一次),这样丢失的数据最少,性能可
     以接受,常见的设置有(SKIP_WAL, ASYNC_WAL, SYNC_WAL, FSYNC_WAL, 建表的时候设
     置), 线上环境建议用默认值比较 好,刷日志的时候只写到HDFS,不会写到硬盘上, 而且性能也
     非常好,毕竟 Hlog是顺序文件 ,在HDFS中是append操作;
  1. 在Put, Delete, Increase过程中如果设置了setWriteToWAL(false), 就不会写WAL , 不过这样做非常危险;
  2. 在memStore刷写到HDFS时: 先向后台异步任务 提交一个任务 ,唤醒后台的异步任务 ,如果新memStore所在region符合分裂的要求 ,就执行分裂操作;

6 HBase服务端删除和increase操作

delete过程和put过程一样,只是在写的过程中添加相关的墓杯标记
increase操作在服务端主要有三个步骤:

  1. 读取原来列的数据到内存中; 
  2. 修改读到内存中的数据; 
  3. 重新数据写到memStore和WAL中; 

8.png

7 Region分裂和合并问题分析

7.1 Region分裂

  1. 当一个region里的StoreFile增长到大于配置的参数:hbase.hregion.max.filesize的大小,也可以在创建HBase表的时候指定这个参数,region会被一分为二。这个过程一般在2-3S内完成,对写数据的影响有短暂的暂停, 由于zookeeper全程记录分裂过程 ,因些分裂服务器失败的时候,其它服务器是可以知道这个region的状态 ,分裂在高并发写的情况下,影响非常大,如何减少在写入过程中region的分裂,是利用好HBase的关键所在,整个分裂是的流程如下:

    1. region所在regionServer创建splits目录;
    2. 关闭要分裂的region的读写请求;
    3. 在splits目录中创建所需要的文件结构;
    4. 移动两个新region文件 目录到目录 表中,并更新.META表;
    5. 异步复制父region中的数据到两个子region中(最主要的消耗时间);
    6. 复制完成后、打开两个新产生的region,并上线,可以接收新的读写请求;
    7. 异步任务把定时把原来被分裂的region从.META表中清除掉,并从文件系统中删除该region所占
      用的空间;
  2. 分割点的确定: Region中StoreFile最大文件中的内部中点
  3. 执行Region分裂的时间是: memStore刷到HDFS的时候,后台线程异步执行,所在类名为MemStoreFlusher

7.2 Region合并

  1. 随着MemStore不断有数据写入,当MemStore的大小超过配置或默认大小的时候,HBase会把

     MemStore中的数据刷新到HDFS中,生成新的StoreFile文件 ,当一个region中包含的StoreFile文
     件 数目超过配置地的阈值,后台合并任务,会把这些文件 合并成数量更少,体积更大的文件 
  2. 当这个过程持续到这些文件 中最大的StoreFile文件 超过配置最大存储文件 大小时,此时会触发

     一个region拆分操作,减少读取过程中的IO
  3. Region合并分为两种,minor合并和major合并:

        3.1 Minor合并:
              是把最后生成的几个小的StoreFile文件 合并一个更大的StoreFile, 默认同时合并的文
                  件数为10, 主要控制参数如下;
                  hbase.hstore.compaction.min 最小合并文件 数量大小, 默认为3
                  hbase.hstore.compaction.max  最大合并文件 数量大小, 默认为10
                  hbase.hstore.compaction.max.size 最大合并文件 的大小 , 默认值 为Long.MAX_VALUE
                  hbase.hstore.compaction.min.size 最小合并文件 的大小, 默认值是memStore刷写的大
                      小, 它是一个阈值, 它包含所有小于限制的文件 ,直到达到每次压缩允许的总文件数量
    
       3.2 Major合并:
             是把整个Store中所有StoreFile文件 合并成一个单独的StoreFile文件 后台定时任务定期检查, 
             这个检查周期是由下面这两人个参数决定 
     hbase.server.thread.wakefrequency * hbase.server.thread.wakefrequency.multiplier(默认值为1000)

8 HBase主备集群数据同步分析

9.png更进一步深入了解掌握HBase;

用云栖社区APP,舒服~

【云栖快讯】诚邀你用自己的技术能力来用心回答每一个问题,通过回答传承技术知识、经验、心得,问答专家期待你加入!  详情请点击

网友评论