- 浏览: 499011 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (502)
- Java (70)
- Linux (10)
- 数据库 (38)
- 网络 (10)
- WEB (13)
- JSP (4)
- 互联网 (71)
- JavaScript (30)
- Spring MVC (19)
- HTML (13)
- CSS (3)
- AngularJS (18)
- Redis (5)
- Bootstrap CSS (1)
- ZooKeeper (4)
- kafka (6)
- 服务器缓存 (4)
- Storm (1)
- MongoDB (9)
- Spring boot (16)
- log4j (2)
- maven (3)
- nginx (5)
- Tomcat (2)
- Eclipse (4)
- Swagger (2)
- Netty (5)
- Dubbo (1)
- Docker (7)
- Hadoop (12)
- OAuth (1)
- webSocket (4)
- 服务器性能 (7)
- Session共享 (1)
- tieye修改 (1)
- 工作 (1)
- 有用的语录 (0)
- https (2)
- common (5)
- 产品开发管理 (1)
- CDN 工作原理 (1)
- APNS、GCM (1)
- 架构图 (3)
- 功能实现分析 (1)
- JMX (1)
- 服务器相关操作命令 (1)
- img02 (0)
- 服务器环境搭建 (9)
- goodMenuBook (1)
- CEInstantPot (0)
- 有用数据 (1)
- 百度地图WEB API (2)
- 正则表达式 (1)
- 样式例子 (2)
- staticRecipePressureCooker.zip (1)
- jCanvas (1)
- 网站攻击方法原理 (1)
- 架构设计 (3)
- 物联网相关 (3)
- 研发管理 (7)
- 技术需求点 (1)
- 计划 (1)
- spring cloud (11)
- 服务器开发的一些实用工具和方法 (1)
- 每天学到的技术点 (4)
- Guava (1)
- ERP 技术注意要点 (2)
- 微信小程序 (1)
- FineRepor (1)
- 收藏夹 (1)
- temp (5)
- 服务架构 (4)
- 任职资格方案 (0)
- osno_test (1)
- jquery相关 (3)
- mybatis (4)
- ueditor (1)
- VueJS (7)
- python (10)
- Spring EL (1)
- shiro (1)
- 前端开发原理与使用 (7)
- YARN (1)
- Spark (1)
- Hbase (2)
- Pig (2)
- 机器学习 (30)
- matplotlib (1)
- OpenCV (17)
- Hystrix (1)
- 公司 (1)
- miniui (4)
- 前端功能实现 (3)
- 前端插件 (1)
- 钉钉开发 (2)
- Jenkins (1)
- elasticSearch使用 (2)
- 技术规范 (4)
- 技术实现原理 (0)
最新评论
hbase工作原理
hbase实现海量数据的存储和查询。hbase并不支持事务。
系统架构
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上进行恢复。
https://blog.csdn.net/cnbird2008/article/details/9151585
HBase -ROOT-和.META.表结构
-ROOT-和.META.。这是什么?它们是HBase的两张内置表,从存储结构和操作方法的角度来说,它们和其他HBase的表没有任何区别,
你可以认为这就是两张普通的表,对于普通表的操作对它们都适用。它们与众不同的地方是HBase用它们来存贮一个重要的系统信息
——Region的分布情况以及每个Region的详细信息。
-ROOT-和.META.表结构
每条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,则不在本文的讨论范围之内。
https://blog.csdn.net/chlaws/article/details/16918913
总结:
master只是处理表(DDL)的相关数据操,实际数据的操作是regionServer完成的,master可以做主从实现高可用性,元数据是以文件方式保存在hdfs中,由其中的regionServer进行管理,regionServer运行多个region进行文件的文件操作(region是masyer叫regionServer启动的),region只是运行才有的,region是表中行的集合的操作线程,当这个region的regionServer宕机后,master会叫其他regionServer运行region接管这个region数据的处理,
元数据和表数据在hdfs中都是以文件的方式进行存储
hbase的分布式只是为了利用分布式计算功能,分布式存储是利用了hdfs实现的
存储方式
https://www.cnblogs.com/mfmdaoyou/p/7245736.html
HBase单个RegionServer的region数目上限
https://blog.csdn.net/xinxiangsui2008/article/details/53580081/
hbase实现海量数据的存储和查询。hbase并不支持事务。
系统架构
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上进行恢复。
https://blog.csdn.net/cnbird2008/article/details/9151585
HBase -ROOT-和.META.表结构
-ROOT-和.META.。这是什么?它们是HBase的两张内置表,从存储结构和操作方法的角度来说,它们和其他HBase的表没有任何区别,
你可以认为这就是两张普通的表,对于普通表的操作对它们都适用。它们与众不同的地方是HBase用它们来存贮一个重要的系统信息
——Region的分布情况以及每个Region的详细信息。
-ROOT-和.META.表结构
每条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,则不在本文的讨论范围之内。
https://blog.csdn.net/chlaws/article/details/16918913
总结:
master只是处理表(DDL)的相关数据操,实际数据的操作是regionServer完成的,master可以做主从实现高可用性,元数据是以文件方式保存在hdfs中,由其中的regionServer进行管理,regionServer运行多个region进行文件的文件操作(region是masyer叫regionServer启动的),region只是运行才有的,region是表中行的集合的操作线程,当这个region的regionServer宕机后,master会叫其他regionServer运行region接管这个region数据的处理,
元数据和表数据在hdfs中都是以文件的方式进行存储
hbase的分布式只是为了利用分布式计算功能,分布式存储是利用了hdfs实现的
存储方式
https://www.cnblogs.com/mfmdaoyou/p/7245736.html
HBase单个RegionServer的region数目上限
https://blog.csdn.net/xinxiangsui2008/article/details/53580081/
相关推荐
这些基础知识是理解HBase工作原理的关键,对于开发者来说,能够帮助他们在设计数据模型时做出合理的选择,以满足不同业务需求。 接下来,书中深入探讨了HBase的框架设计,包括Region Server的职责、Zookeeper的角色...
描述的Hbase的原理,安装已经实现的API,是新手入门的不错教材。值得研究
里面包含HBase非关系数据库的工作原理,使用它的优点,缺点.
HBase 基本原理,出版于 2014,HBase is a NoSQL database that primarily works on top of Hadoop. HBase is based on the storage architecture followed by the BigTable. HBase inherits the storage design ...
2. `hbase-2.2.2-src.tar.gz`:这是HBase的源代码包,适合开发者进行二次开发或者想要深入理解HBase工作原理的用户。你可以编译源代码,生成自己的二进制文件,或者查看、修改源代码以满足特定需求。 安装HBase涉及...
Apache HBase是一个基于Hadoop的分布式数据库,设计用于处理大规模数据集,提供实时读写访问。...通过理解其核心原理和开发指导,开发者可以有效地构建和管理大规模数据存储解决方案,满足业务需求。
**HBase技术原理** HBase,全称是Apache HBase,是一种分布式的、基于列族的NoSQL数据库,设计用于大规模数据集(数十亿行,数百万列)的存储和检索。它构建在Hadoop文件系统(HDFS)之上,为大数据处理提供了实时...
《HBase权威指南》是一本深入探讨分布式大数据存储系统HBase的专业书籍,其源码提供了对书中各个章节涉及技术的直观展示和实践操作...对于想深入理解HBase工作原理和优化技巧的开发者来说,这份源码是一份宝贵的资源。
在“hbase-1.2.5-src.tar.gz”这个压缩包中,包含了HBase 1.2.5的源代码,这为我们提供了深入理解其内部工作原理和进行定制开发的机会。 HBase的设计灵感来源于Google的Bigtable论文,它构建于Hadoop之上,充分利用...
这本书的源代码包含了丰富的示例和实践案例,对于想要深入了解HBase工作原理和技术细节的开发者来说,无疑是一份宝贵的资源。 首先,我们来了解一下HBase的核心概念。HBase是基于列族的存储模型,这意味着数据被...
标题和描述中提到的关键知识点包括Nosql和HBase的原理,以及HBase的优缺点和适用场景。以下是对这些内容的详细分析和解释。 首先,Nosql(NoSQL,即"Not Only SQL"的缩写)是一种数据存储和管理技术,它提供了一种...
#### 五、HBase工作原理 1. **数据写入流程**:客户端提交数据后,首先写入WAL,然后写入MemStore。当MemStore达到一定大小时,数据会被flush到磁盘上的StoreFile。 2. **数据读取流程**:读取数据时,会从最新的...
总的来说,HBase-0.94.26作为一款旧版的HBase,虽然在功能上可能不如新版本全面,但它仍然是理解HBase工作原理和使用方式的重要参考。通过学习和研究这个版本,我们可以深入理解大数据环境下分布式数据库的设计与...
下面我们将深入探讨HBase的核心概念、功能、工作原理以及如何安装和使用1.2.7版本。 一、HBase核心概念 1. 表:HBase中的表由行和列族组成,每个表都有一个唯一的名称。 2. 行键(Row Key):行键是表中的主键,...
下面将详细介绍HBase的核心概念、工作原理以及如何部署和使用。 一、HBase核心概念 1. 表(Table):HBase中的基本数据组织单元,类似于传统数据库的表,但结构更灵活。 2. 行(Row):表中的数据按行存储,每行由...
源码分析是理解HBase工作原理和技术细节的重要途径。HBase在大数据领域扮演着关键角色,它能够处理海量数据并提供实时访问。下面,我们将深入探讨HBase的核心概念和源码中的关键组件。 1. **HBase架构**:HBase基于...
HBase 1.2.0是该数据库的一个稳定版本,包含了众多优化和改进,对于想要深入理解HBase工作原理或者进行大数据分析的学习者来说,研究其源码是非常有价值的。 一、HBase架构与核心概念 1. 表与Region:HBase中的...
### HDFS 命令原理介绍 #### HDFS 概述 HDFS(Hadoop Distributed File System)是一种专为大规模数据处理设计的分布式文件系统。...理解它们的工作原理和技术细节对于有效利用这些工具至关重要。
在IT行业中,HBase是一个非常重要的分布式列式存储系统,尤其...这些基本操作是理解HBase工作原理和进行实际开发的关键步骤。通过学习和实践这些操作,开发者能够更好地掌握如何在实际项目中利用HBase处理大规模数据。