一、Hbase中的4大组件

1、hbase-client

客户端,用来访问hbase集群。可以和Hbase交互,也可以和HRegionServer交互。都是通过hbase rpc来访问对应的接口。

这里的客户端模式有多种,可以是Thrift、Avro、Rest等。

另外,hbase-client自身会缓存region的一些信息。

2、Zookeeper

作用:

  • HMaster的HA,哪个HMaster先抢到zk上的锁,哪个就是active
  • 存储-ROOT-表的地址,HMaster的地址
  • 存储所有HRegionServer的状态,监控HRegionServer的上下线
  • 存储Hbase的一些schema和table的元数据

3、HMaster

HMaster可以启动多个,通过选举机制来保证只有一个HMaster正常运行并提供服务,其他的HMaster作为standby来保证HA。

HMaster主要负责表和Region的管理工作。如:

  • 用户对表的增删改查
  • 管理RegionServer的负载均衡,调整Region的分布
  • 在RegionServer宕机或下线后,负责迁移RegionServer上的Region到其他的RegionServer上
  • Region在分裂后,负责分配新的Region

4、HRegionServer

HRegionServer是hbase中真正的工作节点,主要负责响应用户的I/O请求,向HDFS文件系统读写数据,以及Region的数据文件的合并和拆分等,是Hbase中最核心的模块。

在Hbase中,一张表由多个的HRegion组成,一个HRegionServer中管理着多个HRegion对象。而一个HRegion由多个HStore组成,每个HStore对象都对应着表的一个列族(Column Family)。之后,一个HStore又由一个MemStore和多个StoreFile组成。这些StoreFile就是hbase存储在hdfs上的数据文件,MemStore表示还在内存中未刷新到文件上的那些数据。

在这里插入图片描述

MemStore是基于LSM算法来写数据的,当大小达到一定的量后,会将内存中的数据刷新到磁盘,形成一个新的StoreFile。随着程序的不断运行,StoreFile的数量会越来越多,所以HRegionServer还需要定期的去合并这些StoreFile

另外,当数据越来越多,一个Region下的StoreFile的总大小会越来越大,为了更好的查询性能,HRegionServer会负责将达到一定大小的Region分裂成两个Region。分配的过程大概就是原Region下线,然后分裂出来的两个新Region由HMaster来分配给相应的HRegionServer(根据负载均衡算法)。

HRegionServer还有一个HLog对象,主要实现了WAL机制。因为hbase是将数据先写到内存,堆积到一定程度才刷新到磁盘,如果HRegionServer突然宕机,就会导致一部分数据丢失。所以通过WAL机制,我们可以保证HRegionServer宕机后数据依旧可以通过WAL日志来恢复。每一个HRegionServer实例只会有一个HLog对象,也就是该HRegionServer上各个表的HRegion的写操作全部记录在一个WAL文件中。

在HRegionServer宕机后,主要数据恢复流程大概如下:

  1. HMaster通过zk检测到有HRegionServer下线,开始处理它遗留的WAL文件
  2. 将该WAL文件中不同Region的数据进行拆分,然后放到对应的Region的目录下
  3. 接着HMaster开始将这些失效的Region进行分配,也就是各个在线的HRegionServer都可能领到这些Region
  4. HRegionServer实例分配到Region后,发现对应的Region目录下有WAL文件需要处理,就会读取这些数据进行回放,数据也就重新加载到MemStore中去了

二、Hbase 组件的HA保证

1、zk的HA保证

作为一个分布式协调系统,zk本身就有做HA。只要有足够的zk实例在运行,zk就可以正常的提供服务。

zk一般建议部署单数台的实例,这主要和他的选举机制有关。zk在读数据的时候可以去任何一台节点读取数据,但是在写数据时需要把请求转发给leader节点进行处理,如果无法选出leader节点的话,zk集群是无法正常工作的。leader的选举规则是某个节点必须获得超过一半的选票才可以成为leader,所以如果挂掉n/2台,选举无法进行,zk集群就无法提供服务了。举几个例子:

  • 假设有2台zk节点,挂掉了一台后,只剩下一台zk节点,这时候只能获取到一个投票,没有超过1/2,所以剩下的那台zk节点也无法成为leader,集群无法提供服务(此时容忍度是可以挂掉0台)
  • 假设有3台zk节点,挂掉了一台后,只剩下2台zk节点,这时候可以获取到2个投票,占2/3,超过了1/2,所以zk可以选出leader,是可以正常工作的(此时容忍度是可以挂掉1台)
  • 假设有4台zk节点,挂掉两台后,只剩下两台zk节点,这时候只能获取到两个投票,没有超过1/2,所以剩下的那台zk节点也无法成为leader,集群无法提供服务(此时容忍度是可以挂掉1台)

从上面3个例子可以看出,1台zk节点和2台zk节点的容忍度都是0台,3台zk节点和4台zk节点的容忍度都是1台。可以推出2n-1和2n的效果是一样的,没必要花更多的资源去部署多余的zk节点。因此普遍建议部署奇数台zk节点即可。

hbase有许多地方都依赖于zk,如果zk无法正常工作,会严重影响hbase的运行。因此建议zk至少部署3个实例。

2、HMaster的HA保证

HMaster一般采用一主多备的方式来保证HA。HMaster在启动后通过尝试创建zk节点来成为Active,其他没有创建成果的则成为standby。如果active节点的HMaster因为一些原因挂掉了,standby的HMaster实例就可以迅速成为新的active然后开始工作。

HMaster的HA依赖于zk,因此只要zk能正常提供服务,HMaster只要部署2台即可保证高可用。

3、HRegionServer的HA保证

HRegionServer只是一个工作节点,负责一部分的Region,因此只要不是所有的HRegionServer全挂了,都不会对hbase有什么影响。

HRegionServer下线后,HMaster会将它负责的那些Region分发给其他的HRegionServer来管理。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐