hbase系统架构
Client
1 包含访问hbase的接口,client维护着一些cache来加快对hbase的访问,比如regione的位置信息。
Zookeeper
1 保证任何时候,集群中只有一个master
2 存贮所有Region的寻址入口
3 实时监控Region Server的状态,将Region server的上线和下线信息实时通知给Master
4 存储Hbase的schema,包括有哪些table,每个table有哪些column family
Master职责
1 为Region server分配region
2 负责region server的负载均衡
3 发现失效的region server并重新分配其上的region
4 HDFS上的垃圾文件回收
5 处理schema更新请求
Region Server职责
1 Region server维护Master分配给它的region,处理对这些region的IO请求
2 Region server负责切分在运行过程中变得过大的region
可以看到,client访问hbase上数据的过程并不需要master参与(寻址访问zookeeper和region server,数据读写访问regione server),master仅仅维护者table和region的元数据信息,负载很低。
HBase的表数据模型
Row Key
row key是用来检索记录的主键,访问hbase table中的行,只有三种方式:
1 通过单个row key访问
2 通过row key的range
3 全表扫描
Row key行键 (Row key)可以是任意字符串(最大长度是 64KB,实际应用中长度一般为 10-100bytes),在hbase内部,row key保存为字节数组。
Hbase会对表中的数据按照rowkey排序(字典顺序)
列族Column Family
hbase表中的每个列,都归属与某个列族。列族是表的schema的一部分(而列不是),必须在使用表之前定义。
列名都以列族作为前缀。例如courses:history , courses:math 都属于 courses 这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。
列族越多,在取一行数据时所要参与IO、搜寻的文件就越多,所以,如果没有必要,不要设置太多的列族
列 Column
列族下面的具体列,属于某一个ColumnFamily,类似于我们mysql当中创建的具体的列
时间戳
时间戳可以由
hbase(
在数据写入时自动
)
赋值,工程师也可以自己设置时间戳。
不同版本的数据按照时间倒序排序。
Cell
由{row key, column( =<family> + <label>), version} 唯一确定的单元。
cell中的数据是没有类型的,全部是字节码形式存贮。
VersionNum
数据的版本号,每条数据可以有多个版本号,默认值为系统时间戳,类型为Long
hbase物理存储结构
1 Table中的所有行都按照row key的字典序排列。
2 Table 在行的方向上分割为多个Hregion。
3 region按大小分割的(默认10G),每个表一开始只有一个region,随着数据不断插入表,region不断增大,当增大到一个阈值的时候,Hregion就会等分会两个新的Hregion。当table中的行不断增多,就会有越来越多的Hregion。
4 Hregion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。
5 HRegion虽然是负载均衡的最小单元,但并不是物理存储的最小单元。
事实上,HRegion由一个或者多个Store组成,每个store保存一个column family。
每个Strore又由一个memStore和0至多个StoreFile组成。
一个regionserver
内可以存储多个表的
region
一个表内的region,
只属于这个表。但是这个表的
region,
可能分配到不同的节点(
regionserver
)上。
Memstore与storefile
一个region由多个store组成,每个store包含一个列族的所有数据
Store包括位于内存的memstore和位于硬盘的storefile
写操作先写入memstore,当memstore中的数据量达到某个阈值,Hregionserver启动flashcache进程写入storefile,每次写入形成单独一个storefile,输出多个storefile后,当storefile数量达到阈值时,将多个合并成一个大的storefile。
当storefile大小超过一定阈值后,会把当前的region分割成两个,并由Hmaster分配给相应的region服务器,实现负载均衡
客户端检索数据时,先在memstore找,找不到再找storefile
HLog(WAL log)
WAL log类似mysql中的binlog,用来 做灾难恢复时用,Hlog记录数据的所有变更,一旦数据修改,就可以从log中进行恢复。
每个
Region Server
维护一个
Hlog,
而不是每个
Region
一个。
弊端:数据的写入速度相对较慢,慢的原因是数据写操作执行两次。
Hlog
日志可以关闭,关闭后写入速度能够加快,但是存在数据丢失的风险。
Hlog
日志的拆分
1
、放数据写入日之后,如果发生异常,那么就会关闭当前日志文件,
2
、日志人间大小维度:当日志文件大小达到 一定的量时,就会关当前日志,生成新的日志。
日志的大小是
HDFS
数据块大小的
0.95
倍。
3
、时间维度:默认的时间为
1
小时,即一个小时生成一个日志文件
读写过程
读请求过程:
1
、首先
Client
先去访问
zookeeper
,从
zookeeper
里面获取
meta
表所在的位置信息
2
、
Client
通过刚才获取到的
IP
来访问
Meta
,读取
Meta
内的数据,
3
、
Client
通过元数据(
meta
表内的数据
)中存储的信息,找到
region
在哪个
HRegionServer
,访问对应的 HRegionServer读取数据
写请求过程:
1 Client
先访问
zookeeper
,找到
Meta
表,并获取
Meta
表元数据。确定将要写入的数据所对应的
HRegion
和 HRegionServer服务器。
2 Client
向该
HRegionServer
服务器发起写入数据请求
3 Client
先把数据写入到
HLog
,以防止数据丢失。
4
然后将数据写入到
Memstore
。
5
若
Memstore
达到阈值,会把
Memstore
中的数据
flflush
到
Storefifile
中
6 Storefifile
数量达到阈值(默认
3
个)时,会触发
Compact
合并操作,把过多的
Storefifile
合并成一个大的Storefifile
说明
:
支持数据更新(伪更新),这里的更新实际上时数据的新添加。
region 的管理
前提:一个region只能分配给一个region server。
1
、
master
记录了当前有哪些可用的
region server
。以及当前哪些
region
分配给了哪些
region server
,哪些
region 还没有分配。
2
、当需要分配的新的
region
,并且有一个region server
上有可用空间时,
master
就给这个
region server
发送一个 装载请求,把region
分配给这个
region server
。
3
、
region server
得到请求后,就开始对此
region
提供服务。
regionserver的上线
前提:
master
使用
zookeeper
来跟踪
region server
状态
1
、
region server
启动时,会首先在
zookeeper
上的
/hbase/rs
目录下建立代表自己的
znode
。
2
、
master
订阅了
/hbase/rs
目录上的变更消息,当
/hbase/rs
目录下的文件出现新增或删除操作时,
master
可以得 到来自zookeeper
的实时通知。
3
、一旦region server
上线,
/hbase/rs
有新增
node, zookeeper
通知
master,master
能马上得到消息
.
regionserver的下线
1
、当
region server
下线时,它和
zookeeper
的会话断开
2
、
zookeeper
而自动释放代表这台
server
的文件上的
node
3
、
zookeeper
通知
master, master
得知那个节点下线。
4
、
master
将这台
region server
的
region
分配给其它还活着的
regionserver.
Hmaster的上线
1
从
zookeeper
上获取唯一 一个代表active master
的锁,用来阻止其它
master
成为真正你的
master
。
2
扫描
zookeeper
上的
/hbase/rs
节点,获得当前可用的
region server
列表。
3
和每个
region server
通信,获得当前已分配的
region
和
region server
的对应关系。
4
描.META.表数据,计算得到当前还未分配的region
,将他们放入待分配
region
列表
Hmaster下线
master
只维护表和
region
的元数据,不参与表数据
IO
的过程,
master
下线短时间内对整个
hbase
集群没有影响。
长时间下线的影响:
无法创建删除表,无法修改表的
schema
,无法进行
region
的负载均衡,无法处理
region
上下线,无法进行
region
的合并,(region
的
split
可以正常进行)
master
下线,启用
Zookeeper
的选举机制,确定新的
master,
新
master
执行上线流程