《HBase 不睡觉》HBase的宏观架构

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中的成分。