hbase 底层原理
- 1.hbase 架构
- 2.物理存储
- 3.Rowkey设计三原则
- 4.数据热点
- 5. hbase读写流程
- 6.Region的Split和Compact
- 7.直接将时间戳作为行健,在写入单个 region 时候会发生热点问题,为什么呢?
- 8.hbase 与mysql 区别?
- 9.讲一下Hbase,Hbase二级索引用过吗?
- 10.Hbase热点(数据倾斜)问题 读写请求会集中到某一个RegionServer上 如何处理。
- 11.Hbase的原理 regionserver挂了 如何恢复数据 ?新的数据从Hlog里读出来是如何恢复的?
- 12.hbase 优化
1.hbase 架构
Client职责
HBase有两张特殊表:
.META.:记录了用户所有表拆分出来的的Region映射信息,.META.可以有多个Regoin
-ROOT-:记录了.META.表的Region信息,-ROOT-只有一个Region,无论如何不会分裂。
ZooKeeper职责
1.ZooKeeper为HBase提供Failover机制,选举Master,避免单点Master单点故障问题
2.存储所有Region的寻址入口:-ROOT-表在哪台服务器上。-ROOT-这张表的位置信息
3.实时监控RegionServer的状态,将RegionServer的上线和下线信息实时通知给Master。
4.存储HBase的Schema。
Master职责:
1.为RegionServer分配Region
2、负责RegionServer的负载均衡
3、发现失效的RegionServer并重新分配其上的Region
4、处理Schema更新请求(表的创建,删除,修改,列簇的增加等等)RegionServer职责。如果设计的表的创建操作master宕机没有办法做。但是表的插入和查询可以用。
RegionServer职责:
1.RegionServer维护Master分配给它的Region,处理对这些Region的IO请求
2.负责和底层的文件系统HDFS的交互,存储数据到HDFS
3.RegionServer负责Split在运行过程中变得过大的Region,负责Compact操作
4.负责Store中的HFile的合并工作。
2.物理存储
2.1整体物理结构
hbase新的Region寻址方式
第1步:Client请求ZooKeeper获取.META.所在的RegionServer的地址。
第2步:Client请求.META.所在的RegionServer获取访问数据所在的RegionServer地址,Client会将.META.的相关信息cache下来,以便下一次快速访问。
第3步:Client请求数据所在的RegionServer,获取所需要的数据。
其一:提高性能
其二:2层结构已经足以满足集群的需求。
3.Rowkey设计三原则
一、rowkey长度原则
不要超过16个字节。过长会影响hfile和MemStore存储。
二、rowkey散列原则
三、rowkey唯一原则
4.数据热点
rowkey设计不合理是热点的源头。 热点发生在大量的client直接访问集群的一个或极少数个节点。
防止数据热点的有效措施:
1.加盐
rowkey的前面增加随机数
2.哈希
3.反转
反转固定长度或者数字格式的rowkey,手机号反转后的字符串作为rowkey
4.时间戳反转.
5. hbase读写流程
读:
1.client向zk发送获取元数据的请求,zk返回meta表所在的位置的regionserver。
2.客户端向发请求发送到对应的meta表的regionserver位置,获取真正数据的regionserver。
3.数据的regionserver查找对应的region,在region中寻找列族,先找memstore,找不到去blockcache中寻找,在找不到就进行storefile遍历
4.找到数据先缓存到blockcache中,再将结果返回
写:
1.Client访问zookeeper,获取元数据存储所在的regionserver
2.通过刚刚获取的地址访问对应的regionserver,数据表存储的regionserver
3.去表所在的regionserver,找对应的region,在region中寻找列族,先向memstore中写入数据
4.当memstore写入的值变多,触发溢写操作(flush),进行文件的溢写,成为一个StoreFile.
5.当溢写的文件过多时,会触发文件的合并(Compact)操作,合并有两种方式(major,minor)
6.Region的Split和Compact
合并和拆分:
当一个Store中的StoreFile达到一定的阈值后,就会进行一次合并(minor_compact, major_compact),将对同一个key的修改合并到一起,形成一个大的StoreFile,当StoreFile的大小达到一定阈值后,又会对StoreFile进行split,等分为两个StoreFile。
minor compaction:小范围合并,默认是3-10个文件进行合并,不会删除其他版本的数据。
major compaction:将当前目录下的所有文件全部合并,一般手动触发,会删除其他版本的数据(不同时间戳的)
Compact 的作用:
① 合并文件
② 清除过期,多余版本的数据
③ 提高读写数据的效率
7.直接将时间戳作为行健,在写入单个 region 时候会发生热点问题,为什么呢?
region 中的 rowkey 是有序存储,若时间比较集中。就会存储到一个 region 中,这样一个 region 的数据变多,其它的 region 数据很少,加载数据就会很慢,直到 region 分裂,此问题才会得到缓解。
8.hbase 与mysql 区别?
1.mysql 面向行存储,一整行是一个整体,hbase面向列存储,一整列是一个整体。
2.mysql 存储关系型数据,hbase存储关系型和非关系型数据
3.mysql 有事务概念,hbase 数据库没有事务
4.hbase 存储容量比mysql 存储容量大。
9.讲一下Hbase,Hbase二级索引用过吗?
默认情况下,Hbase只支持rowkey的查询,二级索引其实就是创建新的表,并建立各列值(family:column)与行键(rowkey)之间的映射关系。
10.Hbase热点(数据倾斜)问题 读写请求会集中到某一个RegionServer上 如何处理。
产生原因:1.rowkey设计不合理 2.创建表的时候没有预先分区(默认是一个分区)
热点问题解决:1.解决rowkey设计不合理()2.根据数据量预先分区。
11.Hbase的原理 regionserver挂了 如何恢复数据 ?新的数据从Hlog里读出来是如何恢复的?
一旦RegionServer发生宕机,HBase都会马上检测到这种宕机,并且在检测到宕机之后会将宕机RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去,再根据HLog进行丢失数据恢复,恢复完成之后就可以对外提供服务,整个过程都是自动完成的
12.hbase 优化
12.1其他优化方法:
1.减少数据量
开启BloomFilter,是列族级别的过滤,提高查询速度
使用压缩snappy
2.合理设计rowkey
3.减少列族个数(多个列族更有可能导致数据倾斜)
4.减少启停:对于HBase会有compact机制,会合并HFile,但是我们可以手动关闭compact,减少I/O。如果是批量数据的写入,我们可以用BulkLoad来批量插入数据。