一、Hbase原理
逻辑视图
Hbase 表的特点
image.png
LSM三层存储
hbase会将数据先写到内存中,内存满了会将数据刷写到文件中。
image.png但是如果数据量大的话,时间一长,就会有很多次的刷写,带来大量的磁盘操作的IO。这个问题怎么解?
Hbase会定期将磁盘上的小文件进行合并,合并成大文件。这样的话,小文件会慢慢变成大文件,这样的大文件就适合存储在HDFS中了。
就跟洗袜子一样,袜子先放盆里,盆满了放桶里面,桶满了才去洗衣机洗;Hbase是数据先写内存,到一定大小写到文件中,将多个小文件合并成大文件后再写入到HDFS中进行实际存储。
image.pngimage.png数据一开始存在内存中,如果机器突然挂了,数据不就丢失了么,这个问题Hbase是怎么解的?
这里Hbase采用了跟HDFS类似的原理,他运用到了wal预写日志的思想:hbase也会将数据的操作先写日志,然后存到内存,哪天机器挂了,内存丢了,还能从WAL日志中将数据恢复。
Hbase的WAL机制通过日志恢复策略,保证了内存中的数据不会丢失。
Hbase集群架构
一个 HBase 集群一般由一个 Master 和多个 RegionServer 组成。
- 客户端库:可以通过 HBase 提供的各式语言API 库访问集群。
- API 库也会维护一个本地缓存来加快对 HBase 对访问,比如缓存中记录着 Region 的位置信息。
- Maste 节点:主要为各个 RegionServer 分配 Region,负责 RegionServer 对负载均衡,管理用户对于 Table 对 CRUD 操作。
- RegionServer:维护 Region,处理对这些 Region 对IO 请求,负责切分在运行过程中变过大的 Region。
下图是Hbase集群中的组件图:
image.png
下图是Hbase的架构图,双HMaster组成高可用,HRegionServer存储数据。
image.png
hbase的架构似乎也是master-slave架构,和hdfs有点像,HMaster是用来管理集群,HRegionServer是真正存储数据的地方。
Hbase在数据查询和写入的时候,其实并不是像hdfs那样询问HMaster。在hbase中,每一张表都会有元信息,这些信息也是被存储为hbase表,称为元信息表,也叫meta表,这是一种系统表。所以hbase总是先查询meta表,然后就知道数据存储在哪个HRegionServer上了。
既然meta表也是存储在hbase上,那么hbase又如何知道meta表存在哪个HRegionServer上呢?这岂不是一个鸡生蛋蛋生鸡的问题?
meta表是hbase表,是指meta表也是用rowkey和value的键值存储,但是并没有说meta表在hbase上啊。其实meta表不是存储在HRegionServer上,而是存储在那个分布式协调服务zookeeper上面。
所以meta表其实是在一个固定地方读取,然后根据meta表就知道数据在哪个HRegionServer上。但是zookeeper又是啥呢?
zookeeper是分布式系统中非常重要的组件,主要用于分布式系统间的协调选主,还有一些公共的集群元信息的存储。
Hbase 中的Master有什么作用?
HMaster的任务相对不繁重,但是却比较重要,它主要是通过调整和管理Region分布来实现HRegionServer的负载均衡。
HRegionServer架构
Region是hbase在rowkey上的切分,每个Region都可以通过startKey和endKey来确定rowkey的范围,一个HRegionServer上可能会有多个Region。
把Rowkey分成几块,每一块会形成一个Region,每一个Region分布在一个RegionServer上。
image.png表的横向切分
- Table中所有的行都是按照row key的字典序排列的。例如,rowkey 1,2,10的排列顺序为1,10,2。
- Table在行的方向上分为多个region。
- Region具有最大值,达到阈值会等分为两个region。
- Region是Hbase实现横向扩展和负载均衡功能的基本单元,不同的Region分布到不同的RegionServer,Region与RegionServer之间是多对多的关系。
数据是根据rowkey和一定的哈希规则,分散到不同的Region上面,而Region又是属于某一个HRegionServer上的。通过这里其实可以得出rowkey设计的另一个原则,就是散列性,rowkey的头几个字母,最好不要是一样的,不然会分布在同一个HRegionServer上面,导致这个HRegionServer的负载非常高,累死累活,其他HRegionServer却没事干。一般可以根据一定规则算一个数据的摘要,比如md5,把md5的头几位拼在rowkey的前面。
下图是RegionServer中的主要组件及其架构图:
image.png image.png
一个 Region 是由一个或多个 Store 组成。每一个 Store 其实就是一个列族。每个Store 又是由一个 memStore 和 0 个或者多个 storeFile 组成。memStore 是存储在内存中,是LSM中的第一层,storeFile 是存储在 HDFS 中,这里StoreFile只是一个名字,它是以HFile的格式存储在hdfs上,HFile是一个存储格式,在新版本的HFile存储格式中,它就是一个类似B+树的索引索引形式。数据都会先写入memStore,一旦 memStore 超过给的的最大值之后,HBase 就会将memStore 持久化为 storeFile。Hlog是借鉴了之前提到的WAL的思想,防止机器挂掉以后,memStore内存中的文件丢失。
Hbase读写流程
Hbase写流程
1、hbase client要写输入了,先从zookeeper中拿到meta表信息,根据数据的rowkey找到应该往哪个RegionServer写
2、然后hbase会将数据写入对应RegionServer的内存MemStore中,同时记录操作日志WAL
3、当MemStore超过一定阈值,就会将内存MemStore中的数据刷写到硬盘上,形成StoreFile
4、在触发了一定条件的时候,小的StoreFile会进行合并,变成大的StoreFile,有利于hdfs存储
Hmaster的作用是什么?
当大量rowkey相近的数据都被分配到一个Region中,导致这个Region数据过大的时候,Region进行拆分,HMaster会对拆分后的Region重新分配RegionServer,这是HMaster的负载均衡策略。
Hbase读流程
1、hbase client要读数据了,先从zookeeper中拿到meta表信息,根据要查的rowkey找到对应的数据在哪些RegionServer上
2、分别在这些RegionServer上根据列簇进行StoreFile和MemStore的查找,得到很多key-value结构的数据
3、根据数据的版本找到最新数据进行返回
image.png
二、Hbase的优缺点与适用场景分析
优点:
- 十万行、百万类的海量数据存储
- 支持百万级别高并发写入
- 支持实时查询
- 适合稀疏数据的存储
缺点:
- Hbase对于事务的支持比mysql差多了。
OLAP VS OLTP
- OLTP应用做联机事务处理应用,就是类似银行转账类的业务,对于事务要求比较高,适合mysql这一类的数据库;
- OLAP应用叫联机分析处理应用,比如推荐系统,是在收集了大量用户行为后进行分析,再得出结论的应用,主要侧重分析,对事务要求非常低,适合hbase这一类的数据库。
三、总结
1、hbase是列式存储,和mysql的行式存储不一样
2、hbase中有列簇概念,同一个列簇下的列存储在一起,在Region的一个StoreFile中
3、hbase是按照rowkey进行查找,要查询的字段要想办法放到rowkey中
4、hbase内部使用LSM三层模型进行存储,数据先写到内存MemStore中,内存达到一定阈值再刷写到硬盘StoreFile中,再满足一定条件时,小的StoreFile会合并为大的StoreFile
5、hbase适合OLAP类的应用
网友评论