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]