其他分享
首页 > 其他分享> > HBase系列(三)HBase物理架构与工作流程详解--收藏这一份就够了!!!

HBase系列(三)HBase物理架构与工作流程详解--收藏这一份就够了!!!

作者:互联网

文章目录

HBase物理架构:

在这里插入图片描述

HMaster:

HMaster的主要作用:–负责table和region管理工作

HRegionServer:

img

1.HLog ----简直和NN的editlog还有mysql的log文件一毛一样

一个HRegionServer中就只有一个HLog


HLog它是采用一种叫做预写日志(write-ahead logging,简称WAL)的方式来记录数据的日志文件。数据在这个日志文件里起到一个备份的作用,它是用来作容灾的。HLog也是存储在HDFS上的

当Client想要写数据到HBase数据库中时,数据首先会写到这个HLog中。当数据在HLog中成功保存以后就会告诉客户端:我已经成功保存好你要我保存的数据了。随后进行下一步的保存操作。需要注意的是,数据成功保存进HLog中以后,仅仅完成了HBase数据存储的三分之一而已。但在这里,不讲这么多。

2.HRegion

一个HRegionServer中有0 ~ n个HRegion


Region概念:

Region组成:

img

如何找到Region定位流程:

B+树定位,通过ZooKeeper 来查找 -ROOT-,然后是.META.,然后找到Table里的Region


。HRegionServer在收到数据存储的请求以后,首先会将这些要被存储的数据写到HLog中。当HLog中写成功以后,。其实这种方式优点还是很明显的,既以提升“Client的响应”速度,又能减少IO操作,在数据存储中,减少IO就意味着延长存储介质的寿命,存储介质寿命延长了更意味着企业能降低运维成本。厉害了。。。

3.Store–一个Store代表一个列簇

每一个HRegion内部又维护着0 ~ n个Store


在这里插入图片描述

4.StoreFile

Store内部又维护着一个MemStore和0 ~ n个HFile,最终存储数据用的在HDFS之上的真实文件

在这里插入图片描述

这个MemStore是一段内存空间。而这个StoreFile就是HFile,再将这些数据写到MemStore中。而MemStore由于是内存,你往内存中写数据那速度就快了,在往内存中也写成功以后呢,HRegionServer就要向Client返回一个“我已经把你要我保存的数据保存起来了”的信号了。但是实际上HRegionServer在“骗”你。这个时候你如果到HDFS的后台上去看,你根本找不到你要保存的那段数据的文件。换句话说,HBase之所以要管理起大数据来速度这么快,很大一部分功劳在于它是一个很“狡猾的骗子”。HRegionServer啊,只有在MemStore中存储的数据达到一定的量以后,才会一次性的将这些数据输出到HFile中。

5.blockcache

HBase物理架构工作流程:

一:读操作:

在这里插入图片描述

第一步: client通过zookeeper的调度,通过读取zk的-root表,确定meta表的region位置,再通过读取meta表,读取用户表的region位置信息。

第二步: 根据namespace、表名和rowkey在meta表中找到对应的region信息后,通过region位置信息找到相应的RegionServer,通过RegionServer找到相应的数据存放的Region,并读取数据。

第三步: Regionserver的内存分为MemStore和BlockCache两部分,MemStore主要用于写数据,BlockCache主要用于读数据。读请求先到MemStore中查数据,查不到就到BlockCache中查,再查不到就会到StoreFile上读,并把读的结果放入BlockCache。

二:写操作

第一步: client通过zookeeper的调度,通过读取zk的-root表,确定meta表的region位置,再通过读取meta表,读取用户表的region位置信息。

第二步: 根据namespace、表名和rowkey在meta表中找到对应的region信息后,通过region位置信息找到相应的RegionServer,并将对应的数据发送到该Regionserver检查操作,看Region是不是只读状态,BlockMemorySize大小限制等。

第三步: 数据先写入hlog,然后写入memstore,知道memstore 到达一定的阈值,memstore到达阈值后,会创建一个新的memstore,并将老的添加到flush队列,由单独的线程flush到磁盘上,成为一个storeFile

PS:当得到了需要访问的Regionserver之后,Client,会向对应的Regionserver发起写请求,
数据写入流程,依次将数据写入MemoryStore 和HLog,在写入MemoryStore 和HLog的过程时,需要获取相关的锁,而且写入MemoryStore 和HLog是原子性的,要么都成功,要么都失败。

与此同时,zookeeper会记录一个checkpoint点,表示这个时间之前的数据已经持久化了,到系统故障导致memstore丢失的时候,可以通过hlog进行数据的恢复。

第四步: 随着storeFile的不断增多,当其数量达到一定的阈值之后,会触发Compact操作,将多个StoreFile合并成一个,对同一个key的修改合并到一起,同时对版本进行合并删除。
通过不断合并,当StoreFile到达一定大小的时候,会触发Split操作,把当前Region的文件,分成两个文件,放到相应的Region,此时父Region会下线。这样使得原先1个Region的压力得以分流到2个Region上。


细节扩展:

一:为什么Client只需要知道Zookeeper地址就可以了呢?

HMaster启动的时候,会把Meta信息表加载到zookeeper。
Meta信息表存储了HBase所有的表,所有的Region的详细的信息,比如Region开始的key,结束的key,所在Regionserver的地址。Meta信息表就相当于一个目录,通过它,可以快速定位到数据的实际位置,所以读写数据,只需要跟Zookeeper对应的Regionserver进行交互就可以了。HMaster只需要存储Region和表的元数据信息,协调各个Regionserver,所以他的负载就小了很多。

二:HBase三大模块如何一起协作的。(HMaster,RegionServer,Zookeeper)

通过三个问题解释

1.当HBase启动的时候发生了什么?

HMaster启动的时候会连接zookeeper,将自己注册到Zookeeper,首先将自己注册到Backup Master上,因为可能会有很多的节点抢占Master,最终的Active Master要看他们抢占锁的速度。

将会把自己从Backup Master删除,成为Active Master之后,才会去实例化一些类,比如Master Filesytem,table state manager。

当一个节点成为Active Master之后,他就会等待Regionserver汇报。

首先Regionserver注册Zookeeper,之后向HMaster汇报。HMaster现在手里就有一份关于Regionserver状态的清单,对各个Regionserver(包括失效的)的数据进行整理,
最后HMaster整理出了一张Meta表,这张表中记录了,所有表相关的Region,还有各个Regionserver到底负责哪些数据等等。然后将这张表,交给Zookeeper。
之后的读写请求,都只需要经过Zookeeper就行了。

Backup Master 会定期同步 Active Master信息,保证信息是最新的。

2.如果Regionserver失效了,会发生什么?

如果某一个Regionserver挂了,HMaster会把该Regionserver删除,之后将Regionserver存储的数据,分配给其他的Regionserver,将更新之后meta表,交给Zookeeper。

所以当某一个Regionserver失效了,并不会对系统稳定性产生任何影响。


3.当HMaster失效后会发生什么?

如果Active 的HMaster出现故障,处于Backup状态的其他HMaster节点会推选出一个转为Active状态。当之前出现故障的HMaster从故障中恢复,他也只能成为Backup HMaster,等待当前Active HMaster失效了,他才有机会重新成为Active HMaster。

对于HA高可用集群,当Active状态的HMaster失效,会有处于Backup 的HMaster可以顶上去,集群可以继续正常运行。

如果没有配置HA,那么对于客户端的新建表,修改表结构等需求,因为新建表,修改表结构,需要HMaster来执行,会涉及meta表更新。那么 会抛出一个HMaster 不可用的异常,但是不会影响客户端正常的读写数据请求。

三:为什么需要合并Region?

那为什么需要合并Region呢?这个需要从Region的Split来说。当一个Region被不断的写数据,达到Region的Split的阀值时(由属性hbase.hregion.max.filesize来决定,默认是10GB),该Region就会被Split成2个新的Region。随着业务数据量的不断增加,Region不断的执行Split,那么Region的个数也会越来越多。

一个业务表的Region越多,在进行读写操作时,或是对该表执行Compaction操作时,此时集群的压力是很大的。这里笔者做过一个线上统计,在一个业务表的Region个数达到9000+时,每次对该表进行Compaction操作时,集群的负载便会加重。而间接的也会影响应用程序的读写,一个表的Region过大,势必整个集群的Region个数也会增加,负载均衡后,每个RegionServer承担的Region个数也会增加。

因此,这种情况是很有必要的进行Region合并的。比如,当前Region进行Split的阀值设置为30GB,那么我们可以对小于等于10GB的Region进行一次合并,减少每个业务表的Region,从而降低整个集群的Region,减缓每个RegionServer上的Region压力。

标签:Region,HMaster,就够,Regionserver,详解,HRegionServer,HBase,数据
来源: https://blog.csdn.net/qq_35050438/article/details/107001713