HBase–工作原理篇

  • A+
所属分类:HBase

HBase作为HDFS之上的分布式数据库,其本身并不负责数据存储,而是以二进制文件的形式将数据保存在HDFS上,了解HBase的架构及工作原理,有助于在实际应用中更好的设计表及存储结构,并且可以通过优化集群提高系统性能。

1. HBase系统架构图

  

整个HBase架构重点关注几部分:HMaster、HRegionServer、Zookeeper、HRegion(内部包括HLog、StoreFile、MemStore)。

  

2. HMaster介绍

Hbase集群采用的是master/slave模式,HMaster是集群老大(后面简称Master),统筹管理,所以干的底层杂活不多,负载不高。

2.1 Master职责
(1)为RegionServer分配Region。
(2)负责RegionServer的负载均衡。
(3)发现下线或dead的RegionServer,并重新分配其上的Region。
(4)回收HDFS上的垃圾文件。
(5)处理Schema的更新请求。

  

2.2 Master工作机制
(1) master上线
1)从zookeeper上获取唯一一个代表active master的锁,用来阻止其它master成为master。
2)扫描zookeeper上的server父节点,获得当前可用的region server列表。
3)和每个region server通信,获得当前已分配的region和region server的对应关系。
4)扫描.META.region的集合,计算得到当前还未分配的region,将他们放入待分配region列表。 
(2) master下线
由于master只维护表和region的元数据,而不参与表数据IO的过程(寻址访问zk和RegionServer,数据读写访问RegionServer),所以Master的负载很低,master下线仅导致所有元数据的修改被冻结(无法创建删除表,无法修改表的schema,无法进行region的负载均衡,无法处理region 上下线,无法进行region的合并,唯一例外的是region的split可以正常进行,因为只有region server参与),表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。从上线过程可以看到,master保存的 信息全是可以冗余信息(都可以从系统其它地方收集到或者计算出来),因此,一般hbase集群中总是有一个master在提供服务,还有一个以上 的’master’在等待时机抢占它的位置。
 
3. HRegionServer介绍

HRegionServer(后面简称RegionSever)是集群中的slave,负责处理具体的读写请求及对数据的compact和split等具体过程。

3.1 RegionServer职责
(1) 维护Master给它分配的Region,并处理这些Region的I/O请求。
(2) 负责切分在运行过程中不断变大的Region。
3.2 RegionServer工作机制
(1) regionserver上线
master通过zk来获取regionserver信息。当某个regionserver启动时,首先会在zk的server目录下建立一个属于自己的文件,并获得该文件的独占锁。由于master订阅了server目录的变更消息,所以当server目录下的文件出现新增或变更时,zk会及时通知master。

(2) regionserver下线
当region server下线时,它和zookeeper的会话断开,zookeeper而自动释放代表这台server的文件上的独占锁。而master不断轮询 server目录下文件的锁状态。如果master发现某个region server丢失了它自己的独占锁,(或者master连续几次和region server通信都无法成功),master就是尝试去获取代表这个region server的读写锁,一旦获取成功,就可以确定:
1) region server和zookeeper之间的网络断开了。
2) region server挂了。
的其中一种情况发生了,无论哪种情况,region server都无法继续为它的region提供服务了,此时master会删除server目录下代表这台region server的文件,并将这台region server的region分配给其它还活着的同志。
如果网络短暂出现问题导致region server丢失了它的锁,那么region server重新连接到zookeeper之后,只要代表它的文件还在,它就会不断尝试获取这个文件上的锁,一旦获取到了,就可以继续提供服务。

  

4. Zookeeper介绍

Zookeeper应该可以说是在Hadoop生态中主从结构架构的设计中是大众情人,它能够很好的协调整个集群统统一有序的工作。在HBase的架构中,ZooKeeper提供了类似文件系统一样的访问目录和文件(称为znode)的功能,通常分布式文件系统利用它协调所有权、注册服务、监听更新。
每台Region服务器在ZooKeeper中注册一个自己的临时节点,主服务器会利用这些临时节点来发现可用服务器,还可以利用临时节点来跟踪机器故障和网络分区。
在ZooKeeper服务器中,每个临时节点都属于某一个会话,这个会话是客户端连接ZooKeeper服务器后自动生成的。每个会话在服务器中有一个唯一的id,并且客户端会以此id不断的向ZooKeeper发送“心跳”,一旦发生故障ZooKeeper客户端进程死掉,ZooKeeper服务器会判定该会话超时,并自动删除属于它的临时节点。
HBase还可以利用ZooKeeper确保只有一个主服务器在运行,存储用于发现Region的引导位置,作为一个Region服务器的注册表,一级实现其他目的。ZooKeeper是一个关键组成部分,没有它HBase就无法工作。

   

Zookeeper的主要功能:

(1) 保证master的唯一性。    原理:master启动时会从ZK上获取一个active master锁,阻止其他节点成为master。 
(2) 实时监控RegionServer的状态,将Regionserver上下线的消息及时告知master。
(3) 存储所有Region的寻址入口(即ROOT表在哪台服务器上)。
(4) 存储Hbase的Scema(Zookeeper存的是-ROOT-和.META.这两张表的location,实际存在HBase中),包括有哪些table,每个table有哪些column family。
 

5. Region介绍

Region是HBase存储和管理数据的基本单位。Region和RegionServer是多对一的关系,即一个Region只能同时被一个RegionServer使用,而一个RegionServer可以同时处理多个Region。

5.1 Region和Table的关系

Region实际是Table在行方向上的一个个划分,一般来说一个表在初始的时候只有一个Region,随着数据的增多,当达到某个阈值时,ReginServer就会把这个Region切分成两个Region,以此类推。

5.2 Region细分

继续深究的话,Region还是可以再细分的,它是由一个或多个Store组成的,在这里有必要搞清楚几个基本概念:HFile、HLog、StoreFile、MemStore。

上图反应了客户端对数据请求在底层的流转,可以简单理解为:HLog实际就是备份数据,用来做灾难恢复的;MemStore是缓存数据,用来提高读写效率;StoreFile是最下面一层的存储,它基本等于HFile,前者是相对于HBase而已逻辑上的存储,后者是相对于HDFS在物理上的存储(也就是前面说的hbase不管存,数据二进制文件存在HDFS上,指的就是HFile)。

5.2.1 关于HLog

(1)HLog 又叫WAL(Write Ahead Log),类似于mysql中的binlog,用来做灾难恢复的,HLog记录所有数据的变更,一旦数据发生变化就会在HLog里记录,所以也可以从这里恢复。
(2) 每个RegionServer维护一个HLog,而不是每个Region对应一个。所以不同的Region(来自不同的table)的日志就会混合在一起。
        好处:所有日志都往一个文件写,减少磁盘寻址次数,提高对Hbase写的性能。
        缺点:假设某台RegionServer下线,正好要恢复某个Region,这时就需要将这个HLog发送到其他RegionServer然后再恢复。
补充:HLog就是一个普通的Hadoop Sequence File,Sequence File的key为HLogKey对象(包括数据的归属信息、tablename、region等信息,还包括sequence number和timestamp),value为Hbase实际的key-value对象数据。

5.2.2 关于MemStore

MemStore是挡在StoreFile前面的一层缓存,当Region请求到达时,会先去在MemStore中查找,若命中直接返回结果,这样可以避免对大规模的StoreFile进行扫描。

 

6. 数据读写过程
数据在更新时首先写入Log(WAL log)和内存(MemStore)中,MemStore中的数据是排序的,当MemStore累计到一定阈值时,就会创建一个新的MemStore,并且将老的MemStore添加到Flush队列,由单独的线程Flush到磁盘上,成为一个StoreFile。于此同时,系统会在Zookeeper中记录一个Redo Point,表示这个时刻之前的变更已经持久化了。(minor Compact)当系统出现意外时,可能导致内存(MemStore)中的数据丢失,此时使用Log(WAL log)来恢复Checkpoint之后的数据。StoreFile是只读的,一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后,就会进行一次合并(Major Compact),将对同一个Key的修改合并到一起,形成一个大的StoreFile,当StoreFile的大小达到一定阈值后,又会对 StoreFile进行Split,等分为两个StoreFile。由于对表的更新是不断追加的,处理读请求时,需要访问Store中全部的 StoreFile和MemStore,将他们的按照row key进行合并,由于StoreFile和MemStore都是经过排序的,并且StoreFile带有内存中索引,合并的过程还是比较快。

6.1 读请求
(1)客户端通过ZK和ROOT表、META表找到目标数据所在的RegionServer。
(2)请求RegionServer查找目标数据。
(3)由RegionServer定位到目标数据所在的Region,发出查询请求。
(4)Region会先从Memstore中查,命中则返回(先查Memstore的好处是在内存中,查询快)。
(3)若Memstore没有,则扫描StoreFile(这个过程可以能会扫描很多StorFfiel,借助Bloomfilter)。

6.2 写请求
(1)Client向Regionserver提交写请求。
(2)Regionserver找到目标Region。
(3)Region会检查数据是否与Schema一致。
(4)若客户端没有指定时间戳,默认取当前时间。
(5)将数据更新到WAL Log。
(6)将数据写入到Memstore。
(7)判断Memstore是否需要Flush为Storefile文件。

 

7. -ROOT-和.Meta.两张内置表介绍

Hbase内置两张表(-ROOT-、.META.)来管理region相关信息,且这两张表结构相同。

大致寻址过程:client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client

关于两张表的具体介绍及实例寻址过程,参考:http://greatwqs.iteye.com/blog/1838904

注意几点:
(1) 为什么要设计两张一模一样的表?
首先要注意这两张表也是两张普通的表,所以有可能会有多个region的情况(其实只有.META.表可能会有,.ROOT.很小)。
.META.表用来存储的是region相关的信息,每一行代表一个region,.META.表可能也会有很多region,且散落到不同的regionServer上,所以就用-ROOT-表,以同样的原理来管理.META.表的region(有点绕,其实就是公司管理的层级关系),然后把-ROOT-表的地址放到Zookeeper上(默认地址:/hbase/root-region-server),这样大家就知道所有查询的入口了。

(2) -ROOT-表并不会很大,永远不会被split,所以不会出现-ROOT-表也有很多region的情况,就避免了一直套表的现象了。
(3) -ROOT-表是放在内存中的,所以查询很快。
(4) 其实client的每次请求并非都走这么复杂的过程,client会将查询过的位置信息缓存起来,缓存不会主动失效。

   

圈里圈外

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: