参考博客:Hadoop HBase概念学习系列html
参考博客:Hadoop HBase概念学习系列之HBase里的Zookeeper(二十一)前端
参考博客:Hadoop HBase概念学习系列之HBase里的客户端和HBase集群创建链接(详细)(十四)java
参考博客:Hadoop HBase概念学习系列之META表和ROOT表(六)web
参考博客:Hadoop HBase概念学习系列之HBase里的HRegion(五)shell
参考博客:Hadoop HBase概念学习系列之HLog(二)编程
参考博客:Hadoop HBase概念学习系列之HRegion服务器(三)缓存
参考博客:Hadoop HBase概念学习系列之HMaster服务器(四)服务器
参考博客:ZooKeeper 原理及其在 Hadoop 和 HBase 中的应用架构
参考博客:HBase介绍和工做原理并发
参考博客:深刻了解HBASE架构(转)
HMaster选举与主备切换
HMaster选举与主备切换的原理和HDFS中NameNode及YARN中ResourceManager的HA原理相同。
系统容错
当HBase启动时,每一个RegionServer都会到ZooKeeper的/hbase/rs节点下建立一个信息节点(下文中,咱们称该节点为”rs状态节点”),例如/hbase/rs/[Hostname],同时,HMaster会对这个节点注册监听。当某个 RegionServer 挂掉的时候,ZooKeeper会由于在一段时间内没法接受其心跳(即 Session 失效),而删除掉该 RegionServer 服务器对应的 rs 状态节点。与此同时,HMaster 则会接收到 ZooKeeper 的 NodeDelete 通知,从而感知到某个节点断开,并当即开始容错工做。
HBase为何不直接让HMaster来负责RegionServer的监控呢?若是HMaster直接经过心跳机制等来管理RegionServer的状态,随着集群愈来愈大,HMaster的管理负担会愈来愈重,另外它自身也有挂掉的可能,所以数据还须要持久化。在这种状况下,ZooKeeper就成了理想的选择。
RootRegion管理
对应HBase集群来讲,数据存储的位置信息是记录在元数据region,也就是RootRegion上的。每次客户端发起新的请求,须要知道数据的位置,就会去查询RootRegion,而RootRegion自身位置则是记录在ZooKeeper上的(默认状况下,是记录在ZooKeeper的/hbase/meta-region-server节点中)。当RootRegion发生变化,好比Region的手工移动、从新负载均衡或RootRegion所在服务器发生了故障等是,就可以经过ZooKeeper来感知到这一变化并作出一系列相应的容灾措施,从而保证客户端老是可以拿到正确的RootRegion信息。
Region状态管理
HBase里的Region会常常发生变动,这些变动的缘由来自于系统故障、负载均衡、配置修改、Region分裂与合并等。一旦Region发生移动,它就会经历下线(offline)和从新上线(online)的过程。
分布式SplitWAL任务管理
当某台RegionServer服务器挂掉时,因为总有一部分新写入的数据尚未持久化到HFile中,所以在迁移该RegionServer的服务时,一个重要的工做就是从WAL中恢复这部分还在内存中的数据,而这部分工做最关键的一步就是SplitWAL,即HMaster须要遍历该RegionServer服务器的WAL,并按Region切分红小块移动到新的地址下,并进行日志的回放(replay)。
因为单个RegionServer的日志量相对庞大(可能有上千个Region,上GB的日志),而用户又每每但愿系统可以快速完成日志的恢复工做。所以一个可行的方案是将这个处理WAL的任务分给多台RegionServer服务器来共同处理,而这就又须要一个持久化组件来辅助HMaster完成任务的分配。当前的作法是,HMaster会在ZooKeeper上建立一个splitWAL节点(默认状况下,是/hbase/splitWAL节点),将“哪一个RegionServer处理哪一个Region”这样的信息以列表的形式存放到该节点上,而后由各个RegionServer服务器自行到该节点上去领取任务并在任务执行成功或失败后再更新该节点的信息,以通知HMaster继续进行后面的步骤。ZooKeeper在这里担负起了分布式集群中相互通知和信息持久化的角色。
目录表hbase:meta以hbase表的形式存在,并从hbase shell的列表命令中过滤出来,但实际上它和其余表同样是一个表。
hbase:meta表(之前称为.META.)保存了系统中全部的regions列表,hbase:meta的位置存储在ZooKeeper中。
一、client向Hregionserver发送写请求。
二、Hregionserver将数据写到Hlog(write ahead log)。为了数据的持久化和恢复。
三、hregionserver将数据写到内存(memstore)
四、反馈client写成功。
一、当memstore数据达到阈值(默认是128M),将数据刷到硬盘【数据存储到hdfs中】,将内存中的数据删除,同时删除Hlog中的历史数据。
二、在hlog中作标记点。
一、经过zookeeper和-ROOT- .META.表定位hregionserver。
二、数据从内存和硬盘合并后返回给client
三、数据块会缓存
一、管理用户对Table表的增、删、改、查操做;
二、管理HRegion服务器的负载均衡,调整HRegion分布;
三、在HRegion分裂后,负责新HRegion的分配;
四、在HRegion服务器停机后,负责失效HRegion服务器上的HRegion迁移。
Master负责监视集群中的全部RegionServer实例,是全部元数据更改的接口。在分布式集群中,主机一般在NameNode上运行。
一个常见的列表问题涉及到Master宕机时HBase集群发生了什么。由于Hbase客户端直接与regionserver通讯,因此集群仍然能够在“稳定状态”运行。此外,根据目录表,hbase:meta做为hbase表存在,并不驻留在Master中。可是,主服务器控制关键功能,如区RegionServer故障转移和完成区域分割。所以,虽然集群在没有Master的状况下仍然能够运行很短的时间,可是主服务器应该尽快重启。
在分布式集群中,主机一般在NameNode上运行。
一、HRegion Server主要负责响应用户I/O请求,向HDFS文件系统中读写数据,是HBASE中最核心的模块。
二、HRegion Server管理了不少table的分区,也就是region。
HBase客户端找到服务于特定行范围的RegionServers。它经过查询hbase:meta表来实现这一点。在定位所需的区域以后,客户端联系服务于该region(s)的RegionServer,而不是经过master,并发出读或写请求。这些信息缓存在客户端中,以便后续请求不须要通过查找过程。若是某个区域被主负载均衡器从新分配,或者由于某个RegionServer已死亡,客户端将从新请求目录表以肯定用户region的新位置。