HBase原理详解【Master、Region Server内部机制、Zookeeper、读写数据流程、hbase:meta表】

一、HBASE运行原理

组件结构图

二、各组件的职责

2.1    MASTER职责

1、管理HRegionServer,实现其负载均衡

2、管理和分配HRegion,比如在HRegion split时分配新的HRegion;在HRegion Server退出时迁移其负责的HRegion到其他HRegionServer上。

3、Admin职能:创建、删除、修改Table的定义。实现DDL操作(namespace和table的增删改,column familiy的增删改等),管理namespace和table的元数据(实际存储在HDFS上)。
4、权限控制(ACL)。
监控集群中所有HRegion Server的状态(通过Heartbeat和监听ZooKeeper中的状态)。
 

2.2    REGION SERVER职责

  1. 管理自己所负责的region数据的读写。
  2. 读写HDFS,管理Table中的数据。
  3. Client直接通过HRegionServer读写数据。

2.3    Zookeeper集群所起作用

1、存放整个HBase集群的元数据以及集群的状态信息。
2、实现HMaster主从节点的failover。
注: HMaster通过监听ZooKeeper中的Ephemeral节点(默认:/hbase/rs/*)来监控HRegionServer的加入和宕机。
在第一个HMaster连接到ZooKeeper时会创建Ephemeral节点(默认:/hbasae/master)来表示Active的HMaster,其后加进来的HMaster则监听该Ephemeral节点
如果当前Active的HMaster宕机,则该节点消失,因而其他HMaster得到通知,而将自身转换成Active的HMaster,在变为Active的HMaster之前,它会在/hbase/masters/下创建自己的Ephemeral节点。

2.4   HBASE读写数据流程

1在HBase 0.96以前,HBase有两个特殊的Table:-ROOT-和.META.用来记录用户表的rowkey范围所在的的regionserver服务器:

因而客户端读写数据时需要通过3次寻址请求来对数据所在的regionserver进行定位,效率低下;

2、而在HBase 0.96以后去掉了-ROOT- Table,只剩下这个特殊的目录表叫做Meta Table(hbase:meta),它存储了集群中所有用户HRegion的位置信息,而ZooKeeper的节点中(/hbase/meta-region-server)存储的则直接是这个Meta Table的位置,并且这个Meta Table如以前的-ROOT- Table一样是不可split的。这样,客户端在第一次访问用户Table的流程就变成了:
① 从ZooKeeper(/hbase/meta-region-server)中获取hbase:meta的位置(HRegionServer的位置),缓存该位置信息。
② 从HRegionServer中查询用户Table对应请求的RowKey所在的HRegionServer,缓存该位置信息。
③ 从查询到HRegionServer中读取Row。

注:客户会缓存这些位置信息,然而第二步它只是缓存当前RowKey对应的HRegion的位置,因而如果下一个要查的RowKey不在同一个HRegion中,则需要继续查询hbase:meta所在的HRegion,然而随着时间的推移,客户端缓存的位置信息越来越多,以至于不需要再次查找hbase:meta Table的信息,除非某个HRegion因为宕机或Split被移动,此时需要重新查询并且更新缓存。
 

2.5    hbase:meta表

hbase:meta表存储了所有用户HRegion的位置信息:
Rowkey:tableName,regionStartKey,regionId,replicaId等;
info列族:这个列族包含三个列,他们分别是:
info:regioninfo列:
regionId,tableName,startKey,endKey,offline,split,replicaId;
info:server列:HRegionServer对应的server:port;
info:serverstartcode列:HRegionServer的启动时间戳。

三、REGION SERVER内部机制

     WAL即Write Ahead Log,在早期版本中称为HLog,它是HDFS上的一个文件,如其名字所表示的,所有写操作都会先保证将数据写入这个Log文件后,才会真正更新MemStore,最后写入HFile中。WAL文件存储在/hbase/WALs/${HRegionServer_Name}的目录中

     BlockCache是一个读缓存,即"引用局部性"原理(也应用于CPU,分空间局部性和时间局部性,空间局部性是指CPU在某一时刻需要某个数据,那么有很大的概率在一下时刻它需要的数据在其附近;时间局部性是指某个数据在被访问过一次后,它有很大的概率在不久的将来会被再次的访问),将数据预读取到内存中,以提升读的性能。

     HRegion是一个Table中的一个Region在一个HRegionServer中的表达。一个Table可以有一个或多个Region,他们可以在一个相同的HRegionServer上,也可以分布在不同的HRegionServer上,一个HRegionServer可以有多个HRegion,他们分别属于不同的Table。HRegion由多个Store(HStore)构成,每个HStore对应了一个Table在这个HRegion中的一个Column Family,即每个Column Family就是一个集中的存储单元,因而最好将具有相近IO特性的Column存储在一个Column Family,以实现高效读取(数据局部性原理,可以提高缓存的命中率)。HStore是HBase中存储的核心,它实现了读写HDFS功能,一个HStore由一个MemStore 和0个或多个StoreFile组成。

     MemStore是一个写缓存(In Memory Sorted Buffer)所有数据的写在完成WAL日志写后,会 写入MemStore中,由MemStore根据一定的算法将数据Flush到地层HDFS文件中(HFile)通常每个HRegion中的每个 Column Family有一个自己的MemStore。

     HFile(StoreFile) 用于存储HBase的数据(Cell/KeyValue)。在HFile中的数据是按RowKey、Column Family、Column排序,对相同的Cell(即这三个值都一样),则按timestamp倒序排列。

     FLUSH详述

① 每一次Put/Delete请求都是先写入到MemStore中,当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile),即一个HStore(Column Family)可以有0个或多个StoreFile(HFile)。

② 当一个HRegion中的所有MemStore的大小总和超过了hbase.hregion.memstore.flush.size的大小,默认128MB。此时当前的HRegion中所有的MemStore会Flush到HDFS中。

③ 当全局MemStore的大小超过了hbase.regionserver.global.memstore.upperLimit的大小,默认40%的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中,Flush顺序是MemStore大小的倒序(一个HRegion中所有MemStore总和作为该HRegion的MemStore的大小还是选取最大的MemStore作为参考?有待考证),直到总体的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit,默认38%的内存使用量。

④ 当前HRegionServer中WAL的大小超过了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量,当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中,Flush使用时间顺序,最早的MemStore先Flush直到WAL的数量少于hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs这里说这两个相乘的默认大小是2GB,查代码,hbase.regionserver.max.logs默认值是32,而hbase.regionserver.hlog.blocksize默认是32MB。但不管怎么样,因为这个大小超过限制引起的Flush不是一件好事,可能引起长时间的延迟。
 

发布了162 篇原创文章 · 获赞 237 · 访问量 26万+

猜你喜欢

转载自blog.csdn.net/itcats_cn/article/details/89383404