HBase的宏观架构
我们将从整体到具体的角色来探索HBase的架构
从图中我们可以看出HBase存储数据是基于HDFS的同时也需要借助ZooKeeper对其进行管理
其中可以看出一个HBase集群由一个Master和多个RegionServer组成。这里我们需要注意也可以有两个Master来实现HighAvailable
角色介绍:
- Master:负责启动的时候分配Region到具体的RegionServer,执行各种管理操作,比如Region的分割和合并。在HBase中的Master的角色功能比其他类型集群弱很多。其他的集群系统中的主节点都是至关重要,比如Hadoop的namenode就负责了管理所有data的映射,而MongoDB的mongos负责了路由,他们的主节点只要宕机了,整个集群就瘫痪了。但是HBase的Master很特别,因为数据的读取和写入都跟它没什么关系,它挂了业务系统照样运行。这里我们可以理解为不会出现单点故障的问题。
- RegionServer:RegionServer上有一个或者多个Region。我们读写的数据就存储在Region上。如果你的HBase是基于HDFS的,那么Region所有数据存取操作都是调用了HDFS的客户端接口来实现的。
- Region:表的一部分数据。HBase是一个会自动分片的数据库。一个Region就相当于关系型数据库中分区表的一个分区,或者MongoDB的一个分片。
- HDFS:Hadoop的一部分。HBase并不直接跟服务器的硬盘交互,而是跟HDFS交互,所以HDFS是真正承载数据的载体。
- ZooKeeper:ZooKeeper虽然是自成一家的第三方组件,不属于HBase体系。但是ZooKeeper在HBase中的重要性甚至超过了Master。为什么这么说呢?你可以做一个实验:把Master服务器关掉你的业务系统照样跑,能读能写;但是把ZooKeeper关掉,你就不能读取数据了,因为你读取数据所需要的元数据表hbase:meata的位置存储在ZooKeeper上。
RegionServer的内部架构图
在RegionServer中有两个重要的结构
- 一个WAL:预写日志,WAL是Write-Ahead Log的缩写。从名字就可以看出它的用途,就是:预先写入。当操作到达Region的时候,HBase先、把操作写到WAL里面去。HBase会先把数据放到基于内存实现的Memstore里,等数据达到一定的数量时才刷写(flush)到最终存储的HFile内。而如果在这个过程中服务器宕机或者断电了,那么数据就丢失了。WAL是一个保险机制,数据在写到Memstore之前,先被写到WAL了。这样当故障恢复的时候可以从WAL中恢复数据。预写日志(Write-ahead log,WAL)就是设计来解决宕机之后的操作恢复问题的。数据到达Region的时候是先写入WAL,然后再被加载到Memstore的。就算Region的机器宕掉了,由于WAL的数据是存储在HDFS上的,所以数据并不会丢失。
先写日志后落盘是一种很重要的机制。通过日志保证数据的正确性,而不是通过数据保证数据的正确性。日志是顺序写 的也就是追加写,速度很快快。数据,是随机写相对来说速度较慢。可以提高系统的效率和正确性。
- 多个Region:Region相当于一个数据分片。每一个Region都有起始rowkey和结束rowkey,代表了它所存储的row范围。
在Store中有两个重要组成部分:
- MemStore:每个Store中有一个MemStore实例。数据写入WAL之后就会被放入MemStore。MemStore是内存的存储对象,只有当MemStore满了的时候才会将数据刷写(flush)到HFile中。
- HFile:在Store中有多个HFile。当MemStore满了之后HBase就会在HDFS上生成一个新的HFile,然后把MemStore中的内容写到这个HFile中。HFile直接跟HDFS打交道,它是数据的存储实体。接下来我们来解剖一下单个HFile中的成分。