16 大数据之HBASE(第三部 HBase进阶)
HBASE详细架构
如上图:
- HBASE底层文件存储依赖了Hadoop的HDFS,所以最下面是DataNode数据存储节点.
- 随后我们来看图的最上方,分别是HMaster和zookeeper(zk),HMaster也就是HBASE的管理节点,负责维护了表信息和元数据等,同时还会分配给zookeeper一些任务来协助自己,HMaster管理了HRegionServer(其他工作节点)
- HRegionServer运行在每个节点上,维护了两个信息,第一个是HLog(预写入日志),这个日志类似于MySQL的binlog,但是用HDFS的edits,它里面主要存储了客户端已经提交,但是还没有刷写到磁盘的内容信息,前几部说过,客户端插入一条信息后可以查看等操作,但是在HDFS中并没有找到实际的存储文件,就是因为HBASE先刷写到了HLog,HLog是会写入在HDFS中的,也就是
/HBase/WALs目录下,如果故障恢复直接读取HLog用来恢复内存中存储的数据. - HRegion也就是表空间根据row key 被切分的行的数据信息了,一个HRegionServer可以维护许多个HRegion.
- HRegion中则再次被分为了store(列族)信息,store中一部分是
mem store内存列族信息,一部分是StoreFile内存写入到磁盘的信息,内存的数据被隔一段时间则被写入到HDFS中同时清空再次使用,写入到磁盘的信息,也就产生一个StoreFile,StoreFile使用了一个Hfile的文件存储协议. - HLog和StoreFile都通过
HDFS client写入到了HDFS的节点上. - 再回过来看最左上角的
client,也就是客户端,客户端操作HBASE表信息的时候,直接请求了zookeeper,由zookeeper操作控制HRegionServer节点,不需要经过HMaster,这个过程也就是前面说的zookeeper帮助HMaster做的工作内容,当HMaster突然停掉的一段时间内,获取表的行信息或者修改都是可以完成的,因为他根本没有经过HMaster,所有DML的操作都不会经过HMaster.
写流程
HBASE是一个读比写慢的数据库,因为读的过程操作过程很多,而写就简单了.
如上图:
- 先看左上角,由client(客户端)发起一个put请求.
- 这个请求会先发送到zookeeper,由zookeeper进行处理,返回meta表所在的HRegionServer节点信息,在Hadoop102上.
- 客户端接收到后,回去请求相关的节点Hadoop102,节点返回meta表信息,这时候会在客户端内存生成meta cache(缓存),从表信息(缓存)中获取RS,也就是我要写的这行数据,在那个Region里.
- 发现要找的这行数据在Hadoop103上,发送请求信息及写入的数据,103节点接收到之后开始处理请求,先刷写道wal(也就是HLog)中,然后这时候就可以返回ack了.
- 等待到达时间节点,将wal中的数据加载到内存,也就是Store(列族的内存空间),然后刷写到磁盘,完成.
关于为什么会请求了102再去请求103:
如上图,前面说过表会被切分为多个Region,Region中又会存储相关的列族信息,但是,HBASE是一个分布式的集群,他的Region会被切分,也就会落在不同的节点,由不同的HRegionServer维护,所以在请求了102之后,返回的数据类似于上图的右上角,里面还会有对应的行和所在的节点信息,所以需要再次请求该对应节点,获取数据.