HBase 架构详解
Hbase框架介绍
HBase是一个分布式的、面向列的开源数据库。
不同点:
l 和一般的关系数据库不同,hbase是一个适合于非结构化数据存储的数据库。
l Hbase是基于列而不是基于行的模式。
在分布式的生产环境中,HBase 需要运行在 HDFS 之上,以 HDFS 作为其基础的存储设施。HBase上层提供了访问的数据的 Java API 层,供应用访问存储在 HBase 的数据。在 HBase 的集群中主要由 Master 和 Region Server 组成,以及 Zookeeper,具体模块如下图所示:
Hbase表的逻辑视图
基本概念:
l RowKey
是Byte array,是表中每条记录的“主键”,方便快速查找,Rowkey的设计非常重要;
l Timestamp
版本号,类型为Long,默认值是系统时间戳,可由用户自定义
l ColumnFamily
列族,拥有一个名称(string),包含一个或者多个相关列
l Column
属于某一个columnfamily,familyName:columnName,每条记录可动态添加
l Value(Cell)
单元格由行键、列族、时间戳唯一决定
单元格的数据是没有类型的,全部以字节码形式存储
Hbase组成
示意图
l Master
Hmaster用于调整多个regionServer,侦测各个regionServer之间的状态,并平衡regionServer之间的负载。Hmaster还有一个职责就是分配region给regionServer。
Hmaster允许多个Hmaster节点共存,但是这需要Zookeeper的协助。不过当多个Hmaster节点共存时,只有一个Hmaster是提供服务的,其它的Hmaster节点处于待命的状态。当正在工作的Hmaster节点宕机时,其它的Hmaster则会接管Hbase集群。
l RegionServer
对于一个regionServer而言,其包括了多个region。regionServer的作用只是管理表格,以及实现读写操作。Client直接连接regionServer,并通信获取Hbase中的数据。
l Region
Region是hbase中分布式存储和负载均衡的最小单位,但不是最小的存储单元。如个一个表格很大,并由多个CF组成时,那个表的数据将存放在多个region中,并且每个region会关联多个存储单元store。表在行方向分割为多个region,region是按大小分割的,随着region不断增大,当增大到一个阀值的时候,region就会分成两个region。
l Store
每个region中包含了多个store对象,一个store包含一个memstore和若干个storefile,storefile中包含一个或多个hfile。Memstore存放在内存中,storefile存放在hdfs上。
l Hfile
Hfile由很多个数据块(block)组成,并且有一个固定的结尾块。其中的数据块是由一个header和多个key-value的键值对组成。在结尾块中包含了数据相关的索引信息,系统也是通过结尾块的索引信息找到hfile中的数据。
Hbase读写流程
写数据
Hbase使用memstore和storefile存储对表的更新。数据在更新时首先写入hlog和memstore,memstore中的数据是排序的,当memstore累计到一定的阀值时,就会创建一个新的memstore,并将老的memstore添加到flush队列,由单独的线程flush到磁盘上,成为一个filestore。与此同时,系统会在zookeeper中记录一个checkpoint,表示这个时刻之前的数据变更已经持久化了。当系统出现意外时,可能导致memstore中的数据丢失,此时使用hlog来恢复checkpoint之后的数据。
Storefile是只读的,一旦创建之后就不可修改。因此hbase的更新就是不断追加的操作。当一个store的storefile达到一定的阀值后,就会进行一次合并操作,将对同一个key的修改合并到一起,同时进行版本合并和数据删除,形成一个大的storefile。当storefile的大小达到一定的阀值后,又会对storefile进行切分操作,等分为两个storefile。
Hbase中只有增添数据,所有的更新和删除操作都是在后续的合并中进行的,使得用户的写操作只要进入内存就可以立刻返回,实现了hbase的高速存储。
(1) Client通过Zookeeper的调度,向RegionServer发出写数据请求,在Region中写数据。
(2) 数据被写入Region的MemStore,直到MemStore达到预设阈值。
(3) MemStore中的数据被Flush成一个StoreFile。
(4) 随着StoreFile文件的不断增多,当其数量增长到一定阈值后,触发Compact合并操作,将多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除。
(5) StoreFiles通过不断的Compact合并操作,逐步形成越来越大的StoreFile。
(6) 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个新的Region。父Region会下线,新Split出的2个子Region会被HMaster分配到相应的RegionServer上,使得原先1个Region的压力得以分流到2个Region上。
读操作
Hbase的所有region元数据被存储在.META表中,随着region的增多,.META表中的数据也会增大,并分裂成多个新的region。为了定位.META表中各个region的位置,把.META表中的所有region的元数据保存在-ROOT-表中,最后由zookeeper记录-ROOT-表的位置信息。所有的客户端访问数据之前,需要首先访问zookeeper获取-ROOT-的位置,然后访问-ROOT-表获得.META表的位置,最后根据.META表中的信息确定用户数据存放的位置。
-ROOT-表永远不会被分割,它只有一个region,这样可以保证最多只需要三次跳转就可以定位任意一个region。为了加快访问速度,.META表的所有region全部保存在内存中。客户端会将查询过的位置信息缓存起来,且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据,则询问相关.META表的region服务器,试图获取数据的位置,如果还是失败,则询问-ROOT-表相关的.META表在哪里。最后,如果前面的信息全部失效,则通过zookeeper重新定位region的信息。所以如果客户端上的缓存全部失效,则需要进行6次网络来定位,才能定位到正确的region。
client–>Zookeeper–>-ROOT-表–>.META.表–>RegionServer–>Region–>client
(1) Client访问Zookeeper,查找-ROOT-表,获取.META.表信息。
(2) 从.META.表查找,获取存放目标数据的Region信息,从而找到对应的RegionServer。
(3) 通过RegionServer获取需要查找的数据。
(4) Regionserver的内存分为MemStore和BlockCache两部分,MemStore主要用于写数据,BlockCache主要用于读数据。读请求先到MemStore中查数据,查不到就到BlockCache中查,再查不到就会到StoreFile上读,并把读的结果放入BlockCache。
高可用性
Write-Ahead-Log(WAL)保障数据高可用
我们理解下HLog的作用。HBase中的HLog机制是WAL的一种实现,而WAL(一般翻译为预写日志)是事务机制中常见的一致性的实现方式。每个RegionServer中都会有一个HLog的实例,RegionServer会将更新操作(如 Put,Delete)先记录到 WAL(也就是HLog)中,然后将其写入到Store的MemStore,最终MemStore会将数据写入到持久化的HFile中(MemStore 到达配置的内存阀值)。这样就保证了HBase的写的可靠性。如果没有 WAL,当RegionServer宕掉的时候,MemStore 还没有写入到HFile,或者StoreFile还没有保存,数据就会丢失。或许有的读者会担心HFile本身会不会丢失,这是由 HDFS 来保证的。在HDFS中的数据默认会有3份。因此这里并不考虑 HFile 本身的可靠性。
组件高可用
Master容错:Zookeeper重新选择一个新的Master。如果无Master过程中,数据读取仍照常进行,但是,region切分、负载均衡等无法进行;
RegionServer容错:定时向Zookeeper汇报心跳,如果一旦时间内未出现心跳,Master将该RegionServer上的Region重新分配到其他RegionServer上,失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer;
Zookeeper容错:Zookeeper是一个可靠地服务,一般配置3或5个
HBase 架构详解相关推荐
- java调用webservice_笃学私教:Java开发网站架构演变过程-从单体应用到微服务架构详解...
原标题:笃学私教:Java开发网站架构演变过程-从单体应用到微服务架构详解 Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构.集群架构.分布式架构.SOA架构和微服务架构.下 ...
- 《大数据架构详解:从数据获取到深度学习》第八次重印
第八次重印: 个人去年十月份出版的<大数据架构详解:从数据获取到深度学习>卖的还不错,京东,当当,亚马逊一直在热销榜上,一直排在前列,榜首常客! 既上个月重印之后,本月又重印了一次,累计八 ...
- 《大数据架构详解》一书第16次重印
又收到编辑寄的样书,看了下<大数据架构详解:从数据获取到深度学习>一书从16年10月出版以来,第16次重印. 京东评价超过2万条: 作者手上有少量全新样书,有想要签名样书的同学可以加作者微 ...
- 《大数据架构详解》读后感
<大数据架构详解> -- 读后感 作者:朱洁 罗华霖 出版商:中国工信出版社 电子工业出版社 版次:2016年10月第1版 印数:7001 ~ 12000册 定价:69.00元 本书花了大 ...
- Oracle Golden Gate体系架构详解(原创) - CzmMiao的博客生活 - ITeye技术网站
Oracle Golden Gate体系架构详解(原创) - CzmMiao的博客生活 - ITeye技术网站
- 支付系统整体架构详解
2019独角兽企业重金招聘Python工程师标准>>> 支付系统整体架构详解 http://www.dataguru.cn/article-11263-1.html http://w ...
- NLP:Transformer的架构详解之详细攻略(持续更新)
NLP:Transformer的架构详解之详细攻略(持续更新) 目录 Transformer的架构详解 1. Encoder 1.1.Positional Encoding-数据预处理的部分 1.2. ...
- NLP:Transformer的简介(优缺点)、架构详解之详细攻略
NLP:Transformer的简介(优缺点).架构详解之详细攻略 目录 Transformer的简介(优缺点).架构详解之详细攻略 1.Transformer的简介 (1).Transforme的四 ...
- DL之AlexNet:AlexNet算法的架构详解、损失函数、网络训练和学习之详细攻略
DL之AlexNet:AlexNet算法的架构详解.损失函数.网络训练和学习之详细攻略 相关文章 Dataset:数据集集合(CV方向数据集)--常见的计算机视觉图像数据集大集合(建议收藏,持续更新) ...
最新文章
- java中使用akka手记三 cluster详例
- Gradle project xxx refresh failed Error:Unable to tunnel through proxy. Proxy returns HTTP/...
- memcached系列之二
- jQuery 选择器 (基础恶补之二)
- 电子科技大学格拉斯哥学院英文教材使用效果
- Mac好用的截图软件,这就来了!
- Introspective Distillation for Robust Question Answering 论文笔记
- html调微信加好友,个人微信加好友的四个实用方法
- 每日持续签到,累计签到,送积分
- 计算机本科 很多很多科目的总结
- Java中 关键字abstract(抽像)的定义
- 给王凌打Call的,原来是神奇的智能湖仓
- 电路分析 笔记整理(模拟电子电路)
- sp工具中最疼的是_OnRobot推出小型壁虎单垫(SP)夹持器,扩展创新的壁虎夹持器系列...
- 会话及会话技术、Cookie对象、Session对象 详解
- android实现短信自动转发
- Qt入门(零)——Qt概述
- PF_RING 安装及测试(并行下载jdk)
- pytorch 一两张数据GPU测试,dataload速度慢的原因
- DeCAF: A Deep Convolutional Activation Featurefor Generic Visual Recognition阅读报告(1)