hbase工作原理

hbase工作原理


hbase实现海量数据的存储和查询。hbase并不支持事务。


[img]http://dl2.iteye.com/upload/attachment/0130/6308/d7ddca55-b794-39fc-abc5-abe9f209d4cc.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0130/6310/041b9bb3-2e75-3b2f-8c3a-46eb518f1830.png[/img]


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

Zookeeper
保证任何时候,集群中只有一个master
存贮所有Region的寻址入口。
实时监控Region Server的状态,将Region server的上线和下线信息实时通知给Master
存储Hbase的schema,包括有哪些table,每个table有哪些column family


Master
为Region server分配region
负责region server的负载均衡
发现失效的region server并重新分配其上的region
处理schema更新请求


Region Server
Region server维护Master分配给它的region,处理对这些region的IO请求
Region server负责切分在运行过程中变得过大的region

client访问hbase上数据的过程并不需要master参与(寻址访问zookeeper和region server,数据读写访问regione server),
master仅仅维护者table和region的元数据信息,负载很低。


关键算法/流程
region定位
第一层是保存在zookeeper里面的文件,它持有root region的位置。
第二层root region是.META.表的第一个region其中保存了.META.z表其它region的位置。通过root region,我们就可以访问.META.表的数据。
.META.是第三层,它是一个特殊的表,保存了hbase中所有数据表的region 位置信息。

1 root region永远不会被split,保证了最需要三次跳转,就能定位到任意region 。
2 META.表每行保存一个region的位置信息,row key 采用表名+表的最后一样编码而成。
3 为了加快访问,.META.表的全部region都保存在内存中。
4 client会将查询过的位置信息保存缓存起来,缓存不会主动失效,因此如果client上的缓存全部失效,则需要进行6次网络来回,
才能定位到正确的region(其中三次用来发现缓存失效,另外三次用来获取位置信息)。


写请求处理过程
1 client向region server提交写请求
2 region server找到目标region
3 region检查数据是否与schema一致
4 如果客户端没有指定版本,则获取当前系统时间作为数据版本
5 将更新写入WAL log
6 将更新写入Memstore
7 判断Memstore的是否需要flush为Store文件。


region分配
任何时刻,一个region只能分配给一个region server。
master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server,哪些region还没有分配。
当存在未分配的region,并且有一个region server上有可用空间时,master就给这个region server发送一个装载请求,把region分配给这个region server。
region server得到请求后,就开始对此region提供服务。


region server下线
region server和zookeeper之间的网络断开了。region server挂了。
无论哪种情况,region server都无法继续为它的region提供服务了,此时master会删除server目录下代表这台region server的文件,并将这台region server的region分配给其它还活着的同志。


master上线
master启动进行以下步骤:
1 从zookeeper上获取唯一一个代码master的锁,用来阻止其它master成为master。
2 扫描zookeeper上的server目录,获得当前可用的region server列表。
3 和2中的每个region server通信,获得当前已分配的region和region server的对应关系。
4 扫描.META.region的集合,计算得到当前还未分配的region,将他们放入待分配region列表。


master下线
由 于master只维护表和region的元数据,而不参与表数据IO的过程,master下线仅导致所有元数据的修改被冻结(无法创建删除表,无法修改表 的schema,无法进行region的负载均
衡,无法处理region上下线,无法进行region的合并,唯一例外的是region的split可以 正常进行,因为只有region server参与),表的数据读写还可以正常进行。因此master下线短
时间内对整个hbase集群没有影响。


物理存储
Table中的所有行都按照row key的字典序排列。

Table 在行的方向上分割为多个Hregion。

region按大小分割的,每个表一开始只有一个region,随着数据不断插入表,region不断增大,当增大到一个阀值的时候,
Hregion就会等分会两个新的Hregion。当table中的行不断增多,就会有越来越多的Hregion。

HRegion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。
但一个Hregion是不会拆分到多个server上的。

HRegion虽然是分布式存储的最小单元,但并不是存储的最小单元。
事实上,HRegion由一个或者多个Store组成,每个store保存一个columns family。
每个Strore又由一个memStore和0至多个StoreFile组成。
StoreFile以HFile格式保存在HDFS上。

HLog(WAL log)类似mysql中的binlog,用来 做灾难恢复只用,Hlog记录数据的所有变更,一旦数据修改,就可以从log中进行恢复。

每 个Region Server维护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起,这样做的目的是不
断追加单个 文件相对于同时写多个文件而言,可以减少磁盘寻址次数,因此可以提高对table的写性能。带来的麻烦是,如果一台region server下线,
为了恢复其上的region,需要将region server上的log进行拆分,然后分发到其它region server上进行恢复。


[url]https://blog.csdn.net/cnbird2008/article/details/9151585[/url]


HBase -ROOT-和.META.表结构
-ROOT-和.META.。这是什么?它们是HBase的两张内置表,从存储结构和操作方法的角度来说,它们和其他HBase的表没有任何区别,
你可以认为这就是两张普通的表,对于普通表的操作对它们都适用。它们与众不同的地方是HBase用它们来存贮一个重要的系统信息
——Region的分布情况以及每个Region的详细信息。


-ROOT-和.META.表结构


[img]http://dl2.iteye.com/upload/attachment/0130/6312/9dc25d2c-5c4e-38eb-a2c6-47808b3fdbd8.jpg[/img]


每条Row记录了一个Region的信息。
首先是RowKey,RowKey由三部分组成:TableName, StartKey 和 TimeStamp。RowKey存储的内容我们又称之为Region的Name。
哦,还记得吗?我们在前面的文章中提到的,用来存放Region的文件夹的名字是RegionName的Hash值,因为RegionName可能包含
某些非法字符。现在你应该知道为什么RegionName会包含非法字符了吧,因为StartKey是被允许包含任何值的。将组成RowKey的
三个部分用逗号连接就构成了整个RowKey,这里TimeStamp使用十进制的数字字符串来表示的。这里有一个RowKey的例子:
Table1,RK10000,12345678

然后是表中最主要的Family:info,info里面包含三个Column:regioninfo, server, serverstartcode。其中regioninfo就是Region的详细信息,包括StartKey, EndKey 以及每个Family的信息等等。
server存储的就是管理这个Region的RegionServer的地址。

所以当Region被拆分、合并或者重新分配的时候,都需要来修改这张表的内容。

每个Region就是一个记录

.META.也是一张普通的表,我们需要先知道哪个RegionServer管理了.META.表,怎么办?有一个方法,我们把管理.META.表的
RegionServer的地址放到ZooKeeper上面不久行了,这样大家都知道了谁在管理.META.。

貌似问题解决了,但对于这个例子我们遇到了一个新问题。因为Table1实在太大了,它的Region实在太多了,.META.为了存储这些Region信息,花费了大量的空间,自己也需要划分成多个Region。这就意味着可能有多个RegionServer在管理.META.。
怎么办?在ZooKeeper里面存储所有管理.META.的RegionServer地址让Client自己去遍历?HBase并不是这么做的。
HBase的做法是用另外一个表来记录.META.的Region信息,就和.META.记录用户表的Region信息一模一样。这个表就是-ROOT-表。这也解释了为什么-ROOT-和.META.拥有相同的表结构,因为他们的原理是一模一样的。

-ROOT-行记录结构
这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是:
/hbase/root-region-server

HBase认为-ROOT-表不会大到那个程度,因此-ROOT-只会有一个Region,这个Region的信息也是被存在HBase内部的。

最后要提醒大家注意两件事情:
1. 在整个路由过程中并没有涉及到MasterServer,也就是说HBase日常的数据操作并不需要MasterServer,不会造成MasterServer的负担。
2. Client端并不会每次数据操作都做这整个路由过程,很多数据都会被Cache起来。至于如何Cache,则不在本文的讨论范围之内。

[url]https://blog.csdn.net/chlaws/article/details/16918913[/url]


总结:
master只是处理表(DDL)的相关数据操,实际数据的操作是regionServer完成的,master可以做主从实现高可用性,元数据是以文件方式保存在hdfs中,由其中的regionServer进行管理,regionServer运行多个region进行文件的文件操作(region是masyer叫regionServer启动的),region只是运行才有的,region是表中行的集合的操作线程,当这个region的regionServer宕机后,master会叫其他regionServer运行region接管这个region数据的处理,

元数据和表数据在hdfs中都是以文件的方式进行存储


hbase的分布式只是为了利用分布式计算功能,分布式存储是利用了hdfs实现的


存储方式
[url]https://www.cnblogs.com/mfmdaoyou/p/7245736.html[/url]


HBase单个RegionServer的region数目上限
[url]https://blog.csdn.net/xinxiangsui2008/article/details/53580081/[/url]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

jie310600

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值