前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >HBase 内部探索之旅

HBase 内部探索之旅

作者头像
木野归郎
发布2020-06-12 10:46:15
3510
发布2020-06-12 10:46:15
举报
文章被收录于专栏:share ai happinessshare ai happiness

Region Server 详细架构

StoreFile

存储有序的K-V的文件,存储在HDFS上。

MemStore

写缓存,K-V在MemStore中进行排序,达到阈值之后才会flush到StoreFile,每次flush生成一个新的StoreFile。

WAL

Write Ahead Log,预写日志,防止RegionServer故障,导致MemStore中的数据丢失。

BlockCache

读缓存,每次新查询的数据会缓存在BlockCache中。

另外,每个Region中有多个Store,1个WAL和1个BlockCache,每个Store对应一个列族,包含MemStore和StoreFile。

HBASE运行原理

MASTER职责

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

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

3、Admin职能

创建、删除、修改Table的定义。实现DDL操作(namespace和table的增删改,column familiy的增删改等)。

4、管理namespace和table的元数据(实际存储在HDFS上)。

5、权限控制(ACL)。hbase-site.xml =>acl|ssl

6、监控集群中所有RegionServer的状态(通过Heartbeat和监听ZooKeeper中的状态)。

REGION SERVER职责

管理自己所负责的region数据的读写。

Zookeeper集群所起作用

1、存放整个HBase集群的元数据以及集群的状态信息。

2、实现HMaster主从节点的failover(故障转移)

注: Master通过监听ZooKeeper中的Ephemeral节点(默认:/hbase/rs/*)来监控HRegionServer的加入和宕机。

在第一个Master连接到ZooKeeper时会创建Ephemeral节点(默认:/hbasae/master)来表示Active的HMaster,其后加进来的Master则监听该Ephemeral节点

如果当前Active的Master宕机,则该节点消失,因而其他Master得到通知,而将自身转换成Active的Master,在变为Active的Master之前,它会在/hbase/masters/下创建自己的Ephemeral节点。

HBASE读写数据流程

下面是我将图片流程转换成文字形式:

1、Client先访问zookeeper,获取hbase-meta表位于哪个Region Server。

2、访问对应的Region Server,获取hbase=meta表,根据请求的namespace-table/rowkey,查询出目标数据位于哪个Region Server中的哪个Region中,并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache,方便下次访问。

3、与目标Region Server进行通讯。

4、将数据顺序写入(追加)到WAL。

5、将数据写入对应的MemStore,。数据会在MemStore进行排序。

6、向客户端发送ack。

7、等达到MemStore的刷写时机后,将数据刷写到HFile中。

1、Client先访问zookeeper,获取hbase:meta表位于哪个RegionServer。

2、访问对应的Region Server,获取hbase=meta表,根据请求的namespace-table/rowkey,查询出目标数据位于哪个Region Server中的哪个Region中,并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache,方便下次访问。

3、与目标Region Server进行通讯。

4、分别在MemStore和StoreFile(HFile)中查询目标数据,并将查到的所有的数据进行合并。此处所有的数据是指同一条数据的不同版本(Time stamp)或者不同类型的(put/delete)。

5、将查询到的新的数据块(Block,HFile数据存储单元,默认大小为64kb)缓存到Block Cache。

6、将合并后的最后数据返回给客户端。

MemStore Flush机制

MemStore刷写时机:

1、当某个MemStore的大小达到了hbase.hregion.memstore.flush.size(默认值128M)其所在region的所有MemStore都会刷写。

当MemStore的大小达到了hbase.hregion.memstore.flush.size(默认值128M)*hbase.hregion.memstore.block.multipiler(默认值4)时,会阻止继续往该MemStore写数据。

2、当region server中的MemStore的总大小达到java heapsize*hbase.regionserver.global.memstore.size(默认值0.4)*hbase.regionserver.global.memstore.size.lower.limit(默认值0.95)region会按照其所有MemStore的大小顺序(由大到小)依次进行刷写。直到region server中所有MemStore的总大小减小到上述值以下。

当region server中MemStore的总大小达到java heapsize*hbase.regionserver.global.memstore.size(默认值0.4)时,会阻止继续往所有的MemStore中写数据。

3、到达自动刷写的时间,也会触发MemStore flush。自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcachefluchinterval(默认1小时)。

4、当WAL文件的数量超过hbase.regionserver.max.logs,region会按照时间顺序依次进行刷写,知道WAL文件数量减小到hbase.regionserver.max.log以下(该属性名已经废弃,现无需手动设置,最大值为32)。

补充两点:

StoreFile Compaction

Region Split

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-02-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 OnlyCoding 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
TDSQL MySQL 版
TDSQL MySQL 版(TDSQL for MySQL)是腾讯打造的一款分布式数据库产品,具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性,同时提供智能 DBA、自动化运营、监控告警等配套设施,为客户提供完整的分布式数据库解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档