@Author  : Spinach | GHB
@Link    : http://blog.csdn.net/bocai8058

文章目录

HBase架构图

-ROOT-和.META.结构

从存储结构和操作方法的角度来说,-ROOT-、.META.与其他表没有任何区别。它们与众不同的地方是HBase用它们来存贮一个重要的系统信息:

  • -ROOT-:记录.META.表的Region信息。
  • .META.:记录用户表的Region信息。

其中-ROOT-表本身只会有一个region,也就只会存放在一台RegionServer上。,这样保证了只需要三次跳转,就能定位到任意region。

-ROOT-和.META.均存储在HBase中,可通过以下命令查看scan '-ROOT-'和scan ‘.META.’,存放-ROOT-的所处region的地址放在zookeeper中,路径为/hbase/root-region-server。

-ROOT-和.META.均存储在HBase中,可通过以下命令查看scan ‘hbase:meta’,存放.META.的所处region的地址放在zookeeper中,路径为/hbase/meta-region-server。

-ROOT-

当用户表特别大时,用户表的region也会非常多。.META.表存储了这些region信息,也变得非常大,这时.META.自己也需要划分成多个Region,托管到多个RegionServer上。这时就出现了一个问题:当.META.被托管在多个RegionServer上,如何去定位.META.呢?HBase的做法是用另外一个表来记录.META.的Region信息,就和.META.记录用户表的Region信息一样,这个表就是-ROOT-表。

除了没有historian列族之外,-ROOT-表的结构与.META.表的结构是一样的。另外,-ROOT-表的 RowKey 没有采用时间戳,也没有Encoded值,而是直接指定一个数字。

.META.

hbase(main):018:0> scan 'hbase:meta'
ROW                                                               COLUMN+CELL  
 CallLog,,1528959142280.21bd88f3409aed49228d3b9dd9f8d7c0.         column=info:regioninfo, timestamp=1538750384211, value={ENCODED => 21bd88f3409aed49228d3b9dd9f8d7c0, NAME => 'CallLog,,1528959142280.21bd88f3409aed49228d3b9dd9f8d7c0.', STARTKEY => '', ENDKE
                                                                  Y => ''}     
 CallLog,,1528959142280.21bd88f3409aed49228d3b9dd9f8d7c0.         column=info:seqnumDuringOpen, timestamp=1538750384211, value=\x00\x00\x00\x00\x00\x00\x00(                                           
 CallLog,,1528959142280.21bd88f3409aed49228d3b9dd9f8d7c0.         column=info:server, timestamp=1538750384211, value=centos6:16201              
 CallLog,,1528959142280.21bd88f3409aed49228d3b9dd9f8d7c0.         column=info:serverstartcode, timestamp=1538750384211, value=1538750349345     
 hbase:namespace,,1528879579816.45aa5ea87654b8e16223ca82c351473f. column=info:regioninfo, timestamp=1538750384222, value={ENCODED => 45aa5ea87654b8e16223ca82c351473f, NAME => 'hbase:namespace,,1528879579816.45aa5ea87654b8e16223ca82c351473f.', STARTKEY => '
                                                                  ', ENDKEY => ''}                                     
 hbase:namespace,,1528879579816.45aa5ea87654b8e16223ca82c351473f. column=info:seqnumDuringOpen, timestamp=1538750384222, value=\x00\x00\x00\x00\x00\x00\x00=                                           
 hbase:namespace,,1528879579816.45aa5ea87654b8e16223ca82c351473f. column=info:server, timestamp=1538750384222, value=centos6:16201              
 hbase:namespace,,1528879579816.45aa5ea87654b8e16223ca82c351473f. column=info:serverstartcode, timestamp=1538750384222, value=1538750349345     
 ns1:calllogs,,1532873264166.bd62c4d5567f7d1533cb48fa517d9721.    column=info:regioninfo, timestamp=1538750384217, value={ENCODED => bd62c4d5567f7d1533cb48fa517d9721, NAME => 'ns1:calllogs,,1532873264166.bd62c4d5567f7d1533cb48fa517d9721.', STARTKEY => '', 
                                                                  ENDKEY => ''}
 ns1:calllogs,,1532873264166.bd62c4d5567f7d1533cb48fa517d9721.    column=info:seqnumDuringOpen, timestamp=1538750384217, value=\x00\x00\x00\x00\x00\x00\x00\x0C                                        
 ns1:calllogs,,1532873264166.bd62c4d5567f7d1533cb48fa517d9721.    column=info:server, timestamp=1538750384217, value=centos6:16201              
 ns1:calllogs,,1532873264166.bd62c4d5567f7d1533cb48fa517d9721.    column=info:serverstartcode, timestamp=1538750384217, value=1538750349345     3 row(s) in 0.0200 seconds


hbase(main):020:0> desc 'hbase:meta'
Table hbase:meta is ENABLED                                                    
hbase:meta, {TABLE_ATTRIBUTES => {IS_META => 'true', REGION_REPLICATION => '1', coprocessor$1 => '|org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint|536870911|'}                                                                  
COLUMN FAMILIES DESCRIPTION                                                 
{NAME => 'info', BLOOMFILTER => 'NONE', VERSIONS => '10', IN_MEMORY => 'true', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', CACHE_DATA_IN_L1 => 'true', MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLO
CKSIZE => '8192', REPLICATION_SCOPE => '0'}                                    
1 row(s) in 0.0210 seconds

.META.表中每一行记录了一个Region的信息。

结构说明

  • rowkey

RowKey就是Region Name,它的命名形式是TableName,StartKey,TimeStamp.Encoded.。
第一个region的startKey是空字符串;

CallLog,,1528959142280.21bd88f3409aed49228d3b9dd9f8d7c0.

其中 Encoded 是TableName,StartKey,TimeStamp的md5值。

  • Column Family

.META.表有两个Column Family:info和historian。其中info包含了三个Column:

1. regioninfo:region的详细信息,包括StartKey、EndKey以及Table信息等等。
   a. startKey,region的开始key,第一个region的startKey是空字符串;
   b. endKey,region的结束key,最后一个region的endKey是空字符串;
2. server:管理该region的 RegionServer 的地址。
3. serverstartcode:RegionServer 开始托管该region的时间。

两表关系(hbase0.96版本之前,之后删除了-ROOT-表)

HBase的所有Region元数据被存储在.META.表中2.1,随着Region的增多,.META.表中的数据也会增大,并分裂成多个新的Region。为了定位.META.表中各个Region的位置,把.META.表中所有Region的元数据保存在-ROOT-表中,最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前,需要首先访问Zookeeper获得-ROOT-的位置,然后访问-ROOT-表获得.META.表的位置,最后根据.META.表中的信息确定用户数据存放的位置,

-ROOT-表永远不会被分割,它只有一个Region,也就只会存放在一台RegionServer上。这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度,.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来,且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据,则询问相关.META.表的Region服务器,试图获取数据的位置,如果还是失败,则询问-ROOT-表相关的.META.表在哪里。最后,如果前面的信息全部失效,则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效,则需要进行6次网络来回,才能定位到正确的Region。

写数据过程

  • Client通过Zookeeper的调度,向RegionServer发出写数据请求,zk存储了-ROOT-表(记录.META.表的Region信息),从-ROOT-表中找到.META.表(记录用户表的Region信息)。
  • 根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息找到对应的regionserver;
  • 把数据被写入Region的MemStore,并写到HLog中,直到MemStore达到预设阈值,MemStore中的数据被Flush成一个StoreFile。
  • 随着StoreFile文件的不断增多,当其数量增长到一定阈值后,触发Compact合并操作,将多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除。
  • StoreFiles通过不断的Compact合并操作,逐步形成越来越大的StoreFile。
  • 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个新的Region。父Region会下线,新Split出的2个子Region会被HMaster分配到相应的RegionServer上,使得原先1个Region的压力得以分流到2个Region上。

可以看出HBase只有增添数据,所有的更新和删除操作都是在后续的Compact历程中举行的,使得用户的写操作只要进入内存就可以立刻返回,实现了HBase I/O的高性能。

  • zookeeper中存储了meta表的region信息,从meta表获取相应region信息,然后找到meta表的数据;
  • 根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息找到对应的regionserver;
  • 把数据被写入Region的MemStore,并写到HLog中,直到MemStore达到预设阈值,MemStore中的数据被Flush成一个StoreFile。
  • 随着StoreFile文件的不断增多,当其数量增长到一定阈值后,触发Compact合并操作,将多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除。
  • StoreFiles通过不断的Compact合并操作,逐步形成越来越大的StoreFile。
  • 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个新的Region。父Region会下线,新Split出的2个子Region会被HMaster分配到相应的RegionServer上,使得原先1个Region的压力得以分流到2个Region上。

读数据过程

  • Client访问Zookeeper,查找-ROOT-表,获取.META.表信息。
  • 从.META.表查找,获取存放目标数据的Region信息,从而找到对应的RegionServer。
  • 通过RegionServer获取需要查找的数据。
  • Regionserver的内存分为MemStore和BlockCache两部分,MemStore主要用于写数据,BlockCache主要用于读数据。读请求先到MemStore中查数据,查不到就到BlockCache中查,再查不到就会到StoreFile上读,并把读的结果放入BlockCache。

寻址过程:client–>Zookeeper–>-ROOT-表–>META表–>RegionServer–>Region–>client

  • zookeeper中存储了meta表的region信息,所以先从zookeeper中找到meta表region的位置,然后读取meta表中的数据。meta中又存储了用户表的region信息;
  • 根据namespace、表名和rowkey在meta表中找到对应的region信息;
  • 找到这个region对应的regionserver
  • 查找对应的region;
  • 先从MemStore找数据,如果没有,再到StoreFile上读(为了读取的效率)。

寻址过程:client–>Zookeeper–>META表–>RegionServer–>Region–>client

HBase各个模块功能

Client

  • 整个HBase集群的访问入口;
  • 使用HBase RPC机制与HMaster和HRegionServer进行通信;
  • 与HMaster进行通信进行管理表的操作;
  • 与HRegionServer进行数据读写类操作;
  • 包含访问HBase的接口,并维护cache来加快对HBase的访问

Zookeeper

  • 保证任何时候,集群中只有一个HMaster;
  • 存贮所有HRegion的寻址入口;
  • 实时监控HRegion Server的上线和下线信息,并实时通知给HMaster;
  • 存储HBase的schema和table元数据;
  • Zookeeper Quorum存储表地址、HMaster地址。

HMaster

  • HMaster没有单点问题,HBase中可以启动多个HMaster,通过Zookeeper的Master Election机制保证总有一个Master在运行,主负责Table和Region的管理工作。
  • 管理用户对表的创建、删除等操作;
  • 管理HRegionServer的负载均衡,调整Region分布;
  • Region Split后,负责新Region的分布;
  • 在HRegionServer停机后,负责失效HRegionServer上Region迁移工作。

HRegion Server

  • 维护HRegion,处理对这些HRegion的IO请求,向HDFS文件系统中读写数据;
  • 负责切分在运行过程中变得过大的HRegion。
  • Client访问hbase上数据的过程并不需要master参与(寻址访问Zookeeper和HRegion Server,数据读写访问HRegione Server),HMaster仅仅维护这table和Region的元数据信息,负载很低。

引用:https://blog.csdn.net/yyl424525/article/details/77505749 | https://www.jianshu.com/p/e2bbf23f1ba2 | https://blog.csdn.net/lw_ghy/article/details/60778843 | https://blog.csdn.net/WYpersist/article/details/80220654 | https://blog.csdn.net/map_lixiupeng/article/details/40857825


10-07 11:07