HBase数据架构
HBase数据架构
牧师-Panda 发表于3个月前
HBase数据架构
  • 发表于 3个月前
  • 阅读 18
  • 收藏 2
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

1、数据结构

 

关系数据库一般用B+树,HBASE用的是LSM树。MYSQL所用类B+树一般深度不超过3层,数据单独存放,在B+树的叶节点存储指向实际数据的指针,叶节点之间也相互关联,类似双向链表。这种结构的特点是数据更新或写入导致数据页表分散,不利于顺序访问。LSM存储中,各个文件的结构类似于B+树,但是分多个存在内存或磁盘中,更新和写入变成了磁盘的顺序写,只在合并时去掉重复或过时的数据。也就是说,LSM树将B+树种的随机写变成顺序写,从而提高写吞吐量

 

2、存储

 

存储对象:HregionServer对应多个HRegion,Region的每个列族对应一个Store,每个Store对应多个StoreFile,以及一个memstore。当然,数据刷写时,一个Region只要有一个列族的memStore需要刷写磁盘,则该region的所有列族的memstore都会刷写磁盘。

 

数据访问流程:客户端联系zookeeper集群查找-ROOT-表所在Region服务器,通过-ROOT- Region服务器查找.Meta.表中含有数据region的服务器,然后在.META.表中定位到实际数据对应region的服务器,最后连接这个服务器读写数据。

 

写路径:客户端发起put等请求,交给HRegion实例来处理。HRegion根据put设置决定是否要预写日志,日志写完后数据被写入memstore中。若memstore已满,则数据被刷写到磁盘,同时在文件中保存最后写入的序列号(跟Hlog中的序列号一样,用于决定日志重做起始位置)。

hbase在hadoop上的文件:分为根级文件和表级文件。第一组是WAL文件,对应/hbase/.logs/目录,每个region服务器在该目录下对应一个子目录,里面包含多个日志文件(日志滚动产生:hbase.regionserver.logroll.period)。当日志对应的所有修改被刷写到磁盘,则该日志文件会被转到/hbase/.oldlogs/目录中,再过一段时间(对应配置hbase.master.logcleaner.interval)会被master删除。另外,/hbase/hbase.id和/hbase/hbase.version分别对应集群的唯一ID和文件格式的版本信息。此外,/hbase/splitlog/和/hbase/.corrupt/分别对应存储日志拆分过程中产生的中间拆分文件和损坏的日志。

表级文件,每张表对应/hbase/tableName/目录,该目录包含.tableinfo文件,用来存储HTableDescriptor的序列化信息。

 

表级目录下每个region对应一个子目录,目录中包含一个.regioninfo文件,对应HRegionInfo的序列化信息。日志拆分完成后会在对应Region目录下创建recovered.edits目录,用来存放需要恢复的日志。当region被打开时,region服务器会看到需要回复的文件并重做。region拆分时,关闭该region,在该region目录下创建spits目录,包括新的region目录和引用文件,然后将两个目录移到表目录下,.META.表中父region被更新,增加splitA列和splitB列以标志该region正被更新。之后同时打开两个子region,更新.META.表,增加子region的条目。最后在region目录下的.tmp目录拷贝父region的文件数据。

 

合并:合并分为minor和并和major和并。minor合并的文件最小数量控制:hbase.hstore.compaction.min或hbase.htore.compactionThreshold,最大数量控制:hbase.hstore.compaction.max,被合并文件最大尺寸控制:hbase.hstore.compaction.max.size,最小尺寸:hbase.hstore.compaction.min.size表示所有小于该值的文件都将参与合并,直到达到合并文件最大数量限制。major合并检查的触发条件:memstore被刷写,shell执行compact或major_compact,或相应API调用。除非执行major_compact或majorCompact API,否则不会绕过检查阶段的。

HFILE:HFile由块组成包括数据块,FileInfo块和Trailer块。值得注意的块的大小,太小会增加块间索引空间,太大会导致每次get操作读入内存的数据量过大,影响IO性能。顺序读多的情况下设置块较大,随机读多的情况下减小块配置,建议8k-1M。对于带压缩的表,每块实际大小会比设置的块大小要小。

 

3、WAL

实现WAL的类叫Hlog,如果是在大批量导入数据的mapreduce,建议关闭写日志。Hlog维护一个序列号,要么从零开始,要么从每一个数据文件storefile中取出序列号,取其最大值,最中数据文件中的序列号和日志中的序列号完全对应,以便日志重做。一个region服务器上所有region共享一个hlog实例,意味着所有日志顺序写入日志文件,在日志重做时会产生日志拆分带来的额外开销。WAL用hadoop的SequenceFile存日志,其中key对应类HLogKey包含(表名和region)。客户端的每个修改被封装为一个WALEdit实例。LogSyncer提供了日志延迟刷写的特性,通过hbase.regionserver.optionallogflushinterval设置刷写间隔。

普通的hadoop文件是一读多写,在写入过程中其他用户不可见这个文件。但如果在写日志过程中服务器崩溃,是不是会出问题呢?幸好hadoop新版本添加了append属性,用户可以读到上次崩溃的日志位置。

 

4、读路径

get即scan:hbase中没有索引文件,hFile中最小的单元是块,所以regionserver和底层的Store必须定位到块后把块载入内存然后遍历这个块,才能确定所需数据。这就是scan做的事情,get也必须这么做。

查询数据时,首先是用时间戳或布隆过滤器去掉那些绝对不包含keyvalue的文件。然后加载剩余所有文件的可能数据块。最终还要把keyvalue排序,取得合适的数目的版本数据,以及判断是否有墓碑标记覆盖的过时记录。

 

5、region查找

一般情况是3次网络往返定位到特定region:请求zookeeper查找-ROOT-表,请求-ROOT-表所在region服务器查找.META.表对应的region,再从上一步结果对应的region服务器查找正真的数据region。但是当缓存的region位置信息过期,或者region服务器发生了拆分、合并、移动或负载均衡等操作,最坏情况下定位region服务器需要6次网络往返请求。这是因为客户端采用的是回退迭代的思路,即第一次直接访问发现region不在了,接着会去用缓存的-ROOT-信息定位.META.表位置,发现.META.数据失效,从zookeeper请求-ROOT-表信息,则回到3次网络请求的步骤。

 

6、zookeeper

zookeeper用来跟踪region服务器,保存-ROOT-表地址等。加入zookeeper后,region服务器发送给master的心跳信息交给了zookeeper。hbase集群的跟节点:/hbase,由属性zookeeper.znode.parent参数控制。

/hbase/hbaseid:集群ID

/hbase/master:master的服务器名和端口

/hbase/replication:副本信息

/hbase/root-region-server:包含-ROOT-表所在region服务器的机器名。

/hbase/rs:region服务器的根节点,集群用来跟踪服务器异常。每个region服务器有一个以region服务器名为名称的znode临时节点。

 

共有 人打赏支持
粉丝 24
博文 146
码字总数 180044
×
牧师-Panda
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: