Hbase读写数据过程详解(hbase0.96版本之前与hbase0.96版本之后对比)

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

文章目录

HBase架构图
-ROOT-和.META.结构
- -ROOT-
- .META.
- 两表关系(hbase0.96版本之前，之后删除了-ROOT-表)
写数据过程
读数据过程
HBase各个模块功能

HBase架构图

-ROOT-和.META.结构

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

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

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

hbase0.96版本之前

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

hbase0.96版本之后

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

-ROOT-

hbase0.96版本后删除了root表，新增了namespace，现在是讲解hbase0.96版本之前的版本。

当用户表特别大时，用户表的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 => '', ENDKEY => ''}     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 secondshbase(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-表)

hbase0.96版本后删除了root表，新增了namespace，现在是讲解hbase0.96版本之前的版本。

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。

写数据过程

hbase0.96版本之前

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的高性能。

hbase0.96版本之后，新增了namespace

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上。

读数据过程

hbase0.96版本之前

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

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

hbase0.96版本之后，新增了namespace

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