HBase架构核心模块

Hbase物理模型架构体系

           

hbase工作流程

HRegionServer负责打开region,并创建HRegion实例,它会为每个表的HColumnFamily(用户创建表时定义的)创建一个Store实例,每个Store实例包含一个或多个StoreFile实例。是实际数据存储文件HFile的轻量级封装,每个Store会对应一个MemStore。写入数据时数据会先写入Hlog中成功后在写入MemStore中。Memstore中的数据因为空间有限,所以需要定期flush到文件StoreFile中,每次flush都是生成新的StoreFile。HRegionServer在处理Flush请求时,将数据写成HFile文件永久存储到HDFS上,并且存储最后写入的数据序列号。

Client

整合HBase集群的入口

使用HBase RPC机制与HMaster和HRegionserver通信

与HMaster通信进行管理类的操作

与HRegionserver通信进行读写类操作

包含访问hbase 的接口,client 维护着一些cache 来加快对hbase 的访问,比如regione 的位置信息

Zookeeper

保证任何时候,集群中只有一个running master,Master与RegionServers启动时会向ZooKeeper注册默认情况下,HBase 管理ZooKeeper 实例,比如,启动或者停止ZooKeeperZookeeper的引入使得Master不再是单点故障

存贮所有Region 的寻址入口

实时监控RegionServer 的状态,将Regionserver 的上线和下线信息,实时通知给Master

存储Hbase的schema和table元数据

Master

管理用户对Table的增删改查操作

在RegionSplit后,分配新region的分配

负责regionserver的负载均衡,调整region分布

在RegionServer停机后,负责失效Regionserver上region的重新分配

HMaster失效仅会导致所有元数据无法修改,表达数据读写还是可以正常运行

Region Server

Regionserver维护region,处理对这些region的IO请求

Regionserver负责切分在运行过程中变得过大的region

由上图可以看出,client 访问hbase上数据的过程并不需要master 参与,寻址访问先zookeeper再regionserver,数据读写访问regioneserver。

HRegionServer主要负责响应用户I/O请求,向HDFS文件系统中读写数据,是HBase中最核心的模块。

物理存储

       

1.table中的所有行都是按照rowkey的字典排序

2.table在行的方向上分割为多个Region

3.Region按大小分割,每个表开始只有一个region,随着数据增多,region不断增大,但到达阈值时,region就会分割成两个新的region,因此region会越来越多。

4.region是hbase中分布式存储和负载均衡的最小单元,不同的regioon分布到不同的regionserver上,但Region不会拆分到不同的Region Server上。

Table 在行的方向上分割为多个HRegion,一个region由[startkey,endkey)表示

Region是分布式存储的最小单元,但不是存储的最小的单元。

1. region由一个或多个Store组成,每个Store保存一个columnfamily

2. 每个Store又由一个memStore和0个或多个StoreFile组成

3. memStore存储在内存中,StoreFile存储在HDFS上

Table中Region内部结构

1.一个表会按照行(看数据量)划分为若干个region每一个region分配给一台特定的regionserver管理

2.每一个region内部还要依据列族划分为若干个HStore

3.每个HStore中的数据会落地到若干个HFILE文件中

4.region体积会随着数据插入而不断增长,到一定阈值后会分裂

5.随着region的分裂,一台regionserver上管理的region会越来越多

6.HMASTER会根据regionserver上管理的region数做负载均衡

7.region中的数据拥有一个内存缓存:memstore,数据的访问优先在memstore中进行

8.memstore中的数据因为空间有限,所以需要定期flush到文件storefile中,每次flush都是生成新的storefile

9.storefile的数量随着时间也会不断增加,regionserver会定期将大量storefile进行合并(merge)

StoreFile

       

Data Block段–保存表中的数据,这部分可以被压缩

Meta Block段 (可选的)–保存用户自定义的kv对,可以被压缩。

File Info段–Hfile的元信息,不被压缩,用户也可以在这一部分添加自己的元信息。

Data Block Index段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。

Meta Block Index段 (可选的)–Meta
Block的索引。

Trailer–这一段是定长的。保存了每一段的偏移量,读取一个HFile时,会首先读取Trailer,Trailer保存了每个段的起始位置(段的Magic
Number用来做安全check),然后,DataBlock Index会被读取到内存中,这样,当检索某个key时,不需要扫描整个HFile,而只需从内存中找到key所在的block,通过一次磁盘io将整个
block读取到内存中,再找到需要的key。DataBlock Index采用LRU机制淘汰。

HFile的Data Block,Meta
Block通常采用压缩方式存储,压缩之后可以大大减少网络IO和磁盘IO,随之而来的开销当然是需要花费cpu进行压缩和解压缩。

目标Hfile的压缩支持两种方式:Gzip,Lzo。

HFile格式

      

HFile文件长度不固定,长度固定的块只有两个:Trailer和FileInfo

Trailer中指针指向其他数据块的起始点,它是在持久化数据到文件结束时写入的,即确定为不可变的存储文件。

File Info中记录了文件的一些Meta信息,例如:AVG_KEY_LEN,AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等

Data Index和Meta Index块记录了每个Data块和Meta块的起始点

Data Block是HBase I/O的基本单元,为了提高效率,HRegionServer中有基于LRU的Block Cache机制。

每个Data块的大小可以在创建一个Table的时候通过参数指定,大号的Block有利于顺序Scan,小号Block利于随机查询.

每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字,目的是防止数据损坏。

HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项,并且有固定的结构。

KeyValue格式

KeyLength和ValueLength:两个固定的长度,分别代表Key长度和Value的长度,因此可以忽略键直接访问,用户可以实现在数据中跳跃。

Key部分:Row Length是固定长度的数值,表示RowKey的长度,Row 就是RowKey,Column Family Length是固定长度的数值,表示Family的长度接着就是Column Family,再接着是Qualifier,然后是两个固定长度的数值,表示Time Stamp和Key Type(Put/Delete)

Value部分没有这么复杂的结构,就是纯粹的二进制数据

Zookeeper的作用

       

1.HBase依赖ZooKeeper,默认情况下,HBase管理ZooKeeper(开启和关闭)

2.Master与RegionServer启动时会向Zookeeper注册。

3.Zookeeper的引入使得Master不再是单点故障。

Redion定位

      

寻找RegionServer

1.ZooKeeper(可以找到ROOT表的位置)

2. -ROOT-(只会存储在一个region上,从ROOT表上找到.META表的位置)

3..META(存储了用户世实际存储的位置,如用户表)

4.用户表

-ROOT-

1.表包含.META.表所在的region列表,该表只会存储在一个表中

2.ZooKeeper中记录了-ROOT-表的location

.META:表包含了所有用户空间region列表,以及RegionServer的服务器地址

因此访问流程为Client访问用户数据之前需要首先访问zookeeper,然后访问-ROOT-表,接着问.META.表,最后才能找到用户数据的位置去访问。

HBase容错性

Master容错:Zookeeper重新选择一个新的Master

1.无Master过程中,数据读取仍照常进行;

2.无master过程中,region切分、负载均衡等无法进行;

RegionServer容错:定时向Zookeeper汇报心跳,如果一旦时间内未出现心跳,

1.Master将该RegionServer上的Region重新分配到其他RegionServer上,

2.失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer

Zookeeper容错:Zookeeper是一个可靠地服务,一般配置3或5个Zookeeper实例

Write-Ahead-Log

       

       Write-Ahead-Log  该机制用于数据的容错和恢复:

每个HRegionServer中都有一个HLog对象,HLog是一个实现Write Ahead Log的类,在每次用户操作写入MemStore的同时,也会写一份数据到HLog文件中(HLog文件格式见后续),HLog文件定期会滚动出新的,并删除旧的文件(已持久化到StoreFile中的数据)。

当HRegionServer意外终止后,HMaster会通过Zookeeper感知到,HMaster首先会处理遗留的 HLog文件,

将其中不同Region的Log数据进行拆分,分别放到相应region的目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复

        Write-Ahead-Log(WAL)预写日志

1.Client向RegionServer端提交数据的时候,会优先写WAL日志(WAL),当WAL日志写入成功后,Client才会被告知提交数据成功,如果写入WAL失败,会告诉客户端提交失败。可以通过WAL日志恢复失败的数据。

2.一个Regionserver上所有的Region都共享一个HLog,一次提交先写WAL,在写memStore。

时间: 2024-08-29 12:44:58

HBase架构核心模块的相关文章

网页搜索核心模块架构重构

X模块是百度网页搜索的核心模块,与其他系统接口多,逻辑复杂,代码陈旧.长年密集的新特性开发导致留下了大量的技术债.我们在不影响新特性开发的情况下,在设计层面.编码层面重构了X模块架构代码,在代码可维护性.内存使用和运行效率上都取得了显著成果. 转:http://www.infoq.com/cn/presentations/architecture-reconstruction

阿里P7级架构师总结Spring核心模块及功能汇总

如果你在使用Spring,而且没有使用SpringBoot,那么每个Spring的功能都需要引入相应的jar包依赖.而Spring的jar包依赖又有一二十个,很容易混淆,造成编译或运行错误. 下面我们就整理一下Spring3和Spring4的核心模块和对应的jar包,方便我们在具体使用的过程中更加清晰的了解到我们都需要什么. 与Spring3相比去掉了Struts,新增了Messaging和Websocket. 分析上面的框架结构图,大概包括以下模块和jar包依赖. 核心容器(Core Cont

Hbase架构与原理

HBase是Apache Hadoop中的一个子项目,Hbase依托于Hadoop的HDFS作为最基本存储基础单元,通过使用hadoop的DFS工具就可以看到这些这些数据存储文件夹的结构,还可以通过Map/Reduce的框架(算法)对HBase进行操作 一.   hbase架构  1.概述. HBase是Apache Hadoop的数据库,能够对大型数据提供随机.实时的读写访问.HBase的目标是存储并处理大型的数据.HBase是一个开源的,分布式的,多版本的,面向列的存储模型.它存储的是松散型

HBase架构、模型、特点

1.HBase概述 HBase是一个构建在HDFS上的分布式列存储系统(数据真正存放的位置是HDFS上的,HBase是做数据管理): HBase是Apache Hadoop生态系统中的重要一员,主要用于海量结构化数据存储: HBase是Google Bigtable的开源实现: 从逻辑上讲,HBase将数据按照表.行和列进行存储,它是一个分布式的.稀疏的.持久化存储的多维度排序表: HBase VS HDFS (HDFS适合批处理场景,HDFS不支持数据随机查找.HDFS不支持数据更新) HBa

Hbase架构原理解析

Hbase架构原理解析 https://developer.51cto.com/art/201904/595698.htm HBase 架构 HBase 的架构似乎也是 master-slave 架构,和 HDFS 有点像,HMaster 是用来管理集群,HRegionServer 是真正存储数据的地方 HBase 在数据查询和写入的时候,其实并不是像 HDFS 那样询问 HMaster. 在 HBase 中,每一张表都会有元信息,这些信息也是被存储为 HBase 表,称为元信息表,也叫 Met

《大型网站技术架构核心原理与案例分析》阅读笔记-01

通过阅读该书籍我们能够更加清楚的树立大型网站的的技术发展历程,剖析大型网站技术架构模式,深入的讲述大型互联网架构核心原理,并通过一些典型的技术案例来讲述大型网站开发全景视图,该书籍深入的阐述了各种大型网站面临的各种架构问题及解决方案. 在第一章第一篇大型网站架构演化中了解到与传统企业应用系统相比,大型互联网应用系统具有高并发大流量.高可用性.海量数据.用户分布广泛,网络情况复杂.安全环境恶劣.需求快速变更,发布频繁.渐进式发展等特点:大型网站架构演化发展历程经历了初始阶段的网络架构它的应用程序.

《大型网站技术架构-核心原理与案例分析》之一: 大型网站架构演化

最近刚刚读完李智慧的<大型网站技术架构-核心原理与案例分析>,对每章重点内容作了一些笔记,以便加深印象及日后查阅. 一.大型网站软件系统的特点 高并发,大流量:需要面对高并发用户,大流量访问. 高可用:系统7X24小时不间断服务. 海量数据:需要存储.管理海量数据,需要使用大量服务器. 用户分布广泛,网络情况复杂:许多大型互联网都是为全球用户提供服务的,用户分布范围广,各地网络情况千差万别. 安全环境恶劣:由于互联网的开放性,使得互联网站更容易受到攻击,大型网站几乎每天都会被黑客攻击. 需求快

《大型网站技术架构 -核心原理与安全分析》读书笔记

大型网站架构演化的价值观 网站的价值在于它能为用户提供什么价值,在于网站能做什么,而不在于它是怎么做的,所以在网站还很小的时候去追求网站的架构是舍本逐末,得不偿失的.小型网站最需要做的就是为用户提供好的服务来创造价值,得到用户的认可,活下去,野蛮生长. 网站架构设计误区 一味追求大公司的解决方案 大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路. 为了技术而技术 网站技术是为业务而存在的,除此毫无意义.在技术选型和架构设计中

深入HBase架构解析(一)[转]

前记 公司内部使用的是MapR版本的Hadoop生态系统,因而从MapR的官网看到了这篇文文章:An In-Depth Look at the HBase Architecture,原本想翻译全文,然而如果翻译就需要各种咬文嚼字,太麻烦,因而本文大部分使用了自己的语言,并且加入了其他资源的参考理解以及本人自己读源码时对其的理解,属于半翻译.半原创吧. HBase架构组成 HBase采用Master/Slave架构搭建集群,它隶属于Hadoop生态系统,由一下类型节点组成:HMaster节点.HR