完整版hbase学习系统架构图.docx
- 文档编号:25708029
- 上传时间:2023-06-11
- 格式:DOCX
- 页数:16
- 大小:146.82KB
完整版hbase学习系统架构图.docx
《完整版hbase学习系统架构图.docx》由会员分享,可在线阅读,更多相关《完整版hbase学习系统架构图.docx(16页珍藏版)》请在冰豆网上搜索。
完整版hbase学习系统架构图
HBase系统架构图
组成部件说明
Client:
使用HBaseRPC机制与HMaster和HRegionServer进行通信
Client与HMaster进行通信进行管理类操作
Client与HRegionServer进行数据读写类操作
Zookeeper:
ZookeeperQuorum存储-ROOT-表地址、HMaster地址
HRegionServer把自己以Ephedral方式注册到Zookeeper中,HMaster随时感知各个HRegionServer的健康状况
Zookeeper避免HMaster单点问题
HMaster:
HMaster没有单点问题,HBase中可以启动多个HMaster,通过Zookeeper的MasterElection机制保证总有一个Master在运行
主要负责Table和Region的管理工作:
1管理用户对表的增删改查操作
2管理HRegionServer的负载均衡,调整Region分布
3RegionSplit后,负责新Region的分布
4在HRegionServer停机后,负责失效HRegionServer上Region迁移
HRegionServer:
HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写数据
HRegionServer管理一些列HRegion对象;
每个HRegion对应Table中一个Region,HRegion由多个HStore组成;
每个HStore对应Table中一个ColumnFamily的存储;
ColumnFamily就是一个集中的存储单元,故将具有相同IO特性的Column放在一个ColumnFamily会更高效
HStore:
HBase存储的核心。
由MemStore和StoreFile组成。
MemStore是SortedMemoryBuffer。
用户写入数据的流程:
Client写入->存入MemStore,一直到MemStore满->Flush成一个StoreFile,直至增长到一定阈值->触发Compact合并操作->多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除->当StoreFilesCompact后,逐步形成越来越大的StoreFile->单个StoreFile大小超过一定阈值后,触发Split操作,把当前RegionSplit成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上,使得原先1个Region的压力得以分流到2个Region上。
由此过程可知,HBase只是增加数据,有所得更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证I/O高性能。
HLog
引入HLog原因:
在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer意外退出,MemStore中的内存数据就会丢失,引入HLog就是防止这种情况
工作机制:
每个HRegionServer中都会有一个HLog对象,HLog是一个实现WriteAheadLog的类,每次用户操作写入Memstore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到StoreFile中的数据)。
当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的HLog文件,将不同region的log数据拆分,分别放到相应region目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在LoadRegion的过程中,会发现有历史HLog需要处理,因此会ReplayHLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。
HBase存储格式
HBase中的所有数据文件都存储在HadoopHDFS文件系统上,格式主要有两种:
1HFileHBase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile
2HLogFile,HBase中WAL(WriteAheadLog)的存储格式,物理上是Hadoop的SequenceFile
HFile
图片解释:
HFile文件不定长,长度固定的块只有两个:
Trailer和FileInfo
Trailer中指针指向其他数据块的起始点
FileInfo中记录了文件的一些Meta信息,例如:
AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY等
DataIndex和MetaIndex块记录了每个Data块和Meta块的起始点
DataBlock是HBaseI/O的基本单元,为了提高效率,HRegionServer中有基于LRU的BlockCache机制
每个Data块的大小可以在创建一个Table的时候通过参数指定,大号的Block有利于顺序Scan,小号Block利于随机查询
每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成,Magic内容就是一些随机数字,目的是防止数据损坏
HFile里面的每个KeyValue对就是一个简单的byte数组。
这个byte数组里面包含了很多项,并且有固定的结构。
KeyLength和ValueLength:
两个固定的长度,分别代表Key和Value的长度
Key部分:
RowLength是固定长度的数值,表示RowKey的长度,Row就是RowKey
ColumnFamilyLength是固定长度的数值,表示Family的长度
接着就是ColumnFamily,再接着是Qualifier,然后是两个固定长度的数值,表示TimeStamp和KeyType(Put/Delete)
Value部分没有这么复杂的结构,就是纯粹的二进制数据
HLogFile
HLog文件就是一个普通的HadoopSequenceFile,SequenceFile的Key是HLogKey对象,HLogKey中记录了写入数据的归属信息,除了table和region名字外,同时还包括sequencenumber和timestamp,timestamp是“写入时间”,sequencenumber的起始值为0,或者是最近一次存入文件系统中sequencenumber。
HLogSequeceFile的Value是HBase的KeyValue对象,即对应HFile中的KeyValue
结束语:
这篇文章是我专门在网上弄下来的,算是hbase部分的终极篇吧,我的服务端的源码系列也要基于这个顺序来开展。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
一、HBASE 简介
HBase是一个分布式的、面向列的开源数据库,该技术来源于 FayChang 所撰写的Google论文"Bigtable:
一个结构化数据的分布式存储系统"。
就像Bigtable利用了Google文件系统(FileSystem)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。
HBase是Apache的Hadoop项目的子项目。
HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。
另一个不同的是HBase基于列的而不是基于行的模式。
hbase是bigtable的开源山寨版本。
是建立的hdfs之上,提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。
它介于nosql和RDBMS之间,仅能通过主键(rowkey)和主键的range来检索数据,仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。
主要用来存储非结构化和半结构化的松散数据。
与hadoop一样,Hbase目标主要依靠横向扩展,通过不断增加廉价的商用服务器,来增加计算和存储能力。
HBase中的表一般有这样的特点:
1 大:
一个表可以有上亿行,上百万列
2 面向列:
面向列(族)的存储和权限控制,列(族)独立检索。
3 稀疏:
对于为空(null)的列,并不占用存储空间,因此,表可以设计的非常稀疏。
二、
逻辑视图
HBase以表的形式存储数据。
表有行和列组成。
列划分为若干个列族(rowfamily)
RowKey
column-family1
column-family2
column-family3
column1
column1
column1
column2
column3
column1
key1
t1:
abc
t2:
gdxdf
t4:
dfads
t3:
hello
t2:
world
key2
t3:
abc
t1:
gdxdf
t4:
dfads
t3:
hello
t2:
dfdsfa
t3:
dfdf
key3
t2:
dfadfasd
t1:
dfdasddsf
t2:
dfxxdfasd
t1:
RowKey
与nosql数据库们一样,rowkey是用来检索记录的主键。
访问hbasetable中的行,只有三种方式:
1 通过单个rowkey访问
2 通过rowkey的range
3 全表扫描
Rowkey行键 (Rowkey)可以是任意字符串(最大长度是 64KB,实际应用中长度一般为 10-100bytes),在hbase内部,rowkey保存为字节数组。
存储时,数据按照Rowkey的字典序(byteorder)排序存储。
设计key时,要充分排序存储这个特性,将经常一起读取的行存储放到一起。
(位置相关性)
注意:
字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。
要保持整形的自然序,行键必须用0作左填充。
行的一次读写是原子操作 (不论一次读写多少列)。
这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。
列族
hbase表中的每个列,都归属与某个列族。
列族是表的chema的一部分(而列不是),必须在使用表之前定义。
列名都以列族作为前缀。
例如courses:
history , courses:
math 都属于 courses 这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。
实际应用中,列族上的控制权限能
帮助我们管理不同类型的应用:
我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据(甚至可能因
为隐私的原因不能浏览所有数据)。
时间戳
HBase中通过row和columns确定的为一个存贮单元称为cell。
每个 cell都保存着同一份数据的多个版本。
版本通过时间戳来索引。
时间戳的类型是 64位整型。
时间戳可以由hbase(在数据写入时自动 )赋值,此时时间戳是精确到毫秒的当前系统时间。
时间戳也可以由客户显式赋值。
如果应用程序要避免数据版本冲突,就必须自己生成具有唯一性的时间戳。
每个 cell中,不同版本的数据按照时间倒序排序,即最新的数据排在最前面。
为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担,hbase提供了两种数据版本回收方式。
一是保存数据的最后n个版本,二是保存最近一段时间内的版本(比如最近七天)。
用户可以针对每个列族进行设置。
Cell
由{rowkey,column( =
cell中的数据是没有类型的,全部是字节码形式存贮。
三、
物理存储
1 已经提到过,Table中的所有行都按照rowkey的字典序排列。
2Table 在行的方向上分割为多个Hregion。
3region按大小分割的,每个表一开始只有一个region,随着数据不断插入表,region不断增大,当增大到一个阀值的时候,Hregion就会等分会两个新的Hregion。
当table中的行不断增多,就会有越来越多的Hregion。
4Hregion是Hbase中分布式存储和负载均衡的最小单元。
最小单元就表示不同的Hregion可以分布在不同的HRegionserver上。
但一个Hregion是不会拆分到多个server上的。
5HRegion虽然是分布式存储的最小单元,但并不是存储的最小单元。
事实上,HRegion由一个或者多个Store组成,每个store保存一个columnsfamily。
每个Strore又由一个memStore和0至多个StoreFile组成。
如图:
StoreFile以HFile格式保存在HDFS上。
HFile分为六个部分:
DataBlock 段–保存表中的数据,这部分可以被压缩
MetaBlock 段 (可选的)–保存用户自定义的kv对,可以被压缩。
FileInfo 段–Hfile的元信息,不被压缩,用户也可以在这一部分添加自己的元信息。
DataBlockIndex 段–DataBlock的索引。
每条索引的key是被索引的block的第一条记录的key。
MetaBlockIndex段 (可选的)–MetaBlock的索引。
Trailer–这一段是定长的。
保存了每一段的偏移量,读取一个HFile时,会首先
读取Trailer,Trailer保存了每个段的起始位置(段的MagicNumber用来做安全check),然后,DataBlockIndex会被读取到内存中,这样,当检索某个key时,不需要扫描整个HFile,而只需从内存中找到key所在的block,通过一次磁盘io将整个 block读取到内存中,再找到需要的key。
DataBlockIndex采用LRU机制淘汰。
HFile的DataBlock,MetaBlock通常采用压缩方式存储,压缩之后可以大大减少网络IO和磁盘IO,随之而来的开销当然是需要花费cpu进行压缩和解压缩。
目标Hfile的压缩支持两种方式:
Gzip,Lzo。
HLog(WALlog)
WAL 意为Writeaheadlog(http:
//en.wikipedia.org/wiki/Write-ahead_logging),类似mysql中的binlog,用来
做灾难恢复只用,Hlog记录数据的所有变更,一旦数据修改,就可以从log中进行恢复。
每个RegionServer维护一个Hlog,而不是每个Region一个。
这样不同region(来自不同table)的日志会混在一起,这样做的目的是不断追加单个
文件相对于同时写多个文件而言,可以减少磁盘寻址次数,因此可以提高对table的写性能。
带来的麻烦是,如果一台regionserver下线,为了恢复其上的region,需要将regionserver上的log进行拆分,然后分发到其它regionserver上进行恢复。
HLog文件就是一个普通的HadoopSequenceFile,SequenceFile 的Key是HLogKey对象,HLogKey中记录了写入数据的归属信息,除了table和region名字外,同时还包括 sequencenumber和timestamp,timestamp是"写入时间",sequencenumber的起始值为0,或者是最近一次存入文件系统中sequencenumber。
HLogSequeceFile的Value是HBase的KeyValue对象,即对应HFile中的KeyValue,可参见上文描述。
四、
系统架构
Client
1 包含访问hbase的接口,client维护着一些cache来加快对hbase的访问,比如regione的位置信息。
Zookeeper
1 保证任何时候,集群中只有一个master
2 存贮所有Region的寻址入口。
3 实时监控RegionServer的状态,将Regionserver的上线和下线信息实时通知给Master
4 存储Hbase的schema,包括有哪些table,每个table有哪些columnfamily
Master
1 为Regionserver分配region
2 负责regionserver的负载均衡
3 发现失效的regionserver并重新分配其上的region
4GFS上的垃圾文件回收
5 处理schema更新请求
RegionServer
1Regionserver维护Master分配给它的region,处理对这些region的IO请求
2Regionserver负责切分在运行过程中变得过大的region
可以看到,client访问hbase上数据的过程并不需要master参与(寻址访问zookeeper和regionserver,数据读写访问regioneserver),master仅仅维护者table和region的元数据信息,负载很低。
五、关键算法 / 流程
region定位
系统如何找到某个rowkey(或者某个 rowkeyrange)所在的region
bigtable 使用三层类似B+树的结构来保存region位置。
第一层是保存zookeeper里面的文件,它持有rootregion的位置。
第二层rootregion是.META.表的第一个region其中保存了.META.z表其它region的位置。
通过rootregion,我们就可以访问.META.表的数据。
.META.是第三层,它是一个特殊的表,保存了hbase中所有数据表的region 位置信息。
1rootregion永远不会被split,保证了最需要三次跳转,就能定位到任意region 。
2.META.表每行保存一个region的位置信息,rowkey 采用表名+表的最后一样编码而成。
3 为了加快访问,.META.表的全部region都保存在内存中。
假设,.META.表的一行在内存中大约占用1KB。
并且每个region限制为128MB。
那么上面的三层结构可以保存的region数目为:
(128MB/1KB)*(128MB/1KB)==2(34)个region
4client会将查询过的位置信息保存缓存起来,缓存不会主动失效,因此如果client上的缓存全部失效,则需要进行6次网络来回,才能定位到正确的region(其中三次用来发现缓存失效,另外三次用来获取位置信息)。
读写过程
上文提到,hbase使用MemStore和StoreFile存储对表的更新。
数据在更新时首先写入Log(WALlog)和内存(MemStore)中,MemStore中的数据是排序的,当MemStore累计到一定阈值时,就会创建一个新的MemStore,并
且将老的MemStore添加到flush队列,由单独的线程flush到磁盘上,成为一个StoreFile。
于此同时,系统会在zookeeper中
记录一个redopoint,表示这个时刻之前的变更已经持久化了。
(minorcompact)
当系统出现意外时,可能导致内存(MemStore)中的数据丢失,此时使用Log(WALlog)来恢复checkpoint之后的数据。
前面提到过StoreFile是只读的,一旦创建后就不可以再修改。
因此Hbase的更
新其实是不断追加的操作。
当一个Store中的StoreFile达到一定的阈值后,就会进行一次合并(majorcompact),将对同一个key的修改合并到一起,形成一个大的StoreFile,当StoreFile的大小达到一定阈值后,又会对 StoreFile进行split,等分为两个StoreFile。
由于对表的更新是不断追加的,处理读请求时,需要访问Store中全部的 StoreFile和MemStore,将他们的按照rowkey进行合并,由于StoreFile和MemStore都是经过排序的,并且StoreFile带有内存中索引,合并的过程还是比较快。
写请求处理过程
1client向regionserver提交写请求
2regionserver找到目标region
3region检查数据是否与schema一致
4 如果客户端没有指定版本,则获取当前系统时间作为数据版本
5 将更新写入WALlog
6 将更新写入Memstore
7 判断Memstore的是否需要flush为Store文件。
region分配
任何时刻,一个region只能分配给一个regionserver。
master记录了当前有哪些可用的regionserver。
以及当前哪些region分配给了哪些regionserver,哪些region还没有分配。
当存在未分配的region,并且有一个regionserver上有可用空间时,master就给这个regionserver发送一个装载请求,把region分配给这个regionserver。
regionserver得到请求后,就开始对此region提供服务。
regionserver上线
master使用zookeeper来跟踪regionserver状态。
当某个regionserver启动时,会首先在zookeeper上的server目录下建立代表自己的文件,并获得该文件的独占锁。
由于master订阅了server 目录上的变更消息,当server目录下的文件出现新增或删除操作时,master可以得到来自zookeeper的实时通知。
因此一旦regionserver上线,master能马上得到消息。
regionserver下线
当regionserver下线时,它和zookeeper的会话断开,zookeeper而自动释放代表这台server的文件上的独占锁。
而master不断轮询 server目录下文件的锁状态。
如果master发现某个regionserver丢失了它自己的独占锁,(或者master连续几次和regionserver通信都无法成功),master就是尝试去获取代表这个regionserver的读写锁,一旦获取成功,就可以确定:
1
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 完整版 hbase 学习 系统 架构
![提示](https://static.bdocx.com/images/bang_tan.gif)