HBASE 的存储机制:
region(区域):表上的一块数据
store:逻辑上的列簇
memstore列簇缓冲区:保存热数据(最近浏览,更新等操作的数据)
region server的工作职责:
管理region 和 响应io请求
数据可靠性的体现:
1、如果一个region server挂了 :
写日志 HLOG()
一个server只有一个HLOG,
对数据的操作 根据rowkey属于哪个region就转发到哪个rejoin日志存放在hdfs中
处理方法:再起一个regoin server继承那个挂掉的rejoin server
2、新的region server的启动过程:
向外声明挂掉的regoin server的东西归我继承,io请求由我响应
已刷新的数据存在hdfs上,未刷新到磁盘的数据根据HLOG的时间顺序重新执行来加载
memstore里的必然是最新的数据,如果没找到就到hdfs中找(HLOG)
memstore 的数据落地:
memstore写到128m的时候就会落地
写入hdfs,生成一个HFile的文件
写在storefile中
hbase的路由机制:
region 的膨胀
region 的撕裂
rowkey 按照字典顺序排序,所以数据的量会很大
当数据量达到10G 时, region server 会对 region 进行撕裂。
刚开始还是该 server 管理这两个 region.
master 接到报告,进行负载均衡,重新分配 region 到其他 server 上。
查找数据
memstore 生成的文件那么多,怎么查找数据?
如何在 hdfs 上找到文件 01998 。还要注意版本号
BOOLMFILTER 布隆过滤器(损耗正确率来提高速度),设置在列簇上,他会记录文件中存储了多少rowkey,
数据的查找机制(二级索引)
怎么样确定客户端与哪个 region server 交互才能找到数据?
增加一层 —— meta 索引表 (位置在系统表里边)
meta 表记录的内容:(哪个表,区间信息,是哪个region ,属于哪个regionserver等。。)
meta 表放在哪里由谁管理?
zookeeper 中有个节点 /hbase/meta
只有一层 meta 表时寻找数据文件的过程:
例:get 000198
从 zk 查询 meta表在哪里,从 meta表里边得到要去的 region 的信息
二级索引(meta 和 root)
meta 表也会分给多个 region ,也存储在不同的 region server 上
当 meta 表大于 10 G 时,也会撕裂,那还怎么在寻找的时候使用?
设置一层 root ,他的数据量基本上可保证由一个 region 来管理就足够
在 zk 上有一个节点记录 root 的信息
寻找数据位置的过程
1、到zk 上找 root表的位置 ,
2、跟 root 表交互,对region server 请求获得 meta表的位置,即 在哪个 region上 .
3、查找 meta 表,确定 rowkey 所在的 region 以及 region server 所在的位置。(到 meta 表,连接到后得到 region server 和 属于哪个 region .)
4、跟数据所在的 region server 进行交互
5、region server转发 请求给 region
6、在 region 中的 memstore 中查找 判断有没有需要的数据信息,若没有,则与HDFS 交互,通过HDFS 的 API 读取数据
7、返回结果,首先把结果写入到 memstore
8、返回结果给客户端
客户端还会缓存 rowkey 属于哪个 region 和 region server 的信息。在寻址之前会先查看缓存,如果缓存中没有要找的数据文件,再去执行以上寻址过程。
如果缓存中有数据文件的位置信息,则直接连接到该文件的机器
会出现的问题:
region 发生撕裂后位置信息的改变,使缓存的位置信息错误?
三次冗余后执行以上寻址过程。
region server挂掉怎么办?
三次冗余。每次都会路由到位置中的机器中(rs)寻找。三次失败后,正确找到后更改客户端的缓存。
总结:客户端做 IO 请求一共有6次机会。