HBase框架简介(整理)

 

图1  HBase存储架构图

Table & Region

Table逻辑上以Region的形式保存在RegionServer中。当Table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startkey, endkey]表示，不同的region会被Master分配给相应的RegionServer进行管理：

 

-ROOT- && .META. Table

HBase中有两张特殊的Table，-ROOT-和.META.

ü  .META.：记录了用户表的Region信息，.META.可以分裂成多个regoin

ü  -ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region

ü  Zookeeper中记录了-ROOT-表的location

META 表存储了所有的用户Region的信息，同时包括HReginServer对象的信息，其中有每一个行值的开始到结束的键值，一个表是否有效或失效，每一个HReginServer的地址，等等。META 表的大小随着用户Region的增加而增加。

ROOT表被限制在一个区域中，它指定了所有的META表信息。这些信息包括每一个META所处的区域和HReginServer信息。

ROOT表和META表每一行的大小大概是1KB左右。每一个区域的大小是256MB，这意味着ROOT表可以装载2.6 x 10⁵ META区域，转化成用户区域就是6.9 x 10¹⁰，转化成可以存储的字节数就是1.8 x 10¹⁹  。

Zookeeper

Zookeeper是Hadoop的正式子项目，应该不属于HBase，Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点问题，当HMaster挂了之后能协调产生新的HMaster，假如没有配置Zookeeper，Zookeeper的部分功能由Master自己完成，HBase还是存在单点问题。

 

Hbase Client

HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC。

假如配置中存在Zookeeper，Client访问用户数据之前需要首先访问zookeeper，一旦ROOT区域被找到以后，Client就可以通过扫描ROOT区域找到相应的META区域去定位实际提供数据的HReginServer。

当定位到提供数据的HReginServer以后，Client就可以通过这个HReginServer找到需要的数据了。

这些信息将会被Client缓存起来，当下次请求的时候，就不需要重复查找。

当这些区域中的某个区域不可用的时候，Client将会逆向执行上面的过程，直到找到实际提供数据的HReginServer为止。

Hbase Master

主要负责Table和Region的管理工作：

1)        管理用户对Table的增、删、改、查操作

2)        管理HRegionServer的负载均衡，调整Region分布

3)        在Region Split后，负责新Region的分配

4)        在HRegionServer停机后，负责失效HRegionServer 上的Regions迁移

同时HBaseMaster还含有一个指向包含有ROOT区域的HReginServer地址。同时，HBaseMaster会监控每一台HReginServer的健康状况，如果某一台HReginServer不可用，它将会把不可用的HReginServer来提供服务的HLog和表由其他HReginServer来提供。

与 Bigtable不同的是，如果没有Zookeeper，HBaseMaster失效了，整个集群就会关闭。在Bigtable中，即使Master机器失效了，Tabletserver还是可以提供服务的。Bigtable使用了而外的锁管理机制，而我们的HBase使用的单点访问模式：所有的HReginServer都访问HBaseMaster。

HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。。HReginServer通过与HBaseMaster通信获取自己需要服务的数据表，并向HBaseMaster反馈自己的运行状况。

HRegionServer

HRegionServer管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个Column Family的存储，因此最好将具备共同IO特性的column放在同一个Column Family中，这样最高效。

HStore存储是HBase存储的核心，由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。下图描述了Compaction和Split的过程：

Write Requests

当一个写的请求到来的时候，它首先会写到一个叫做HLog的write-ahead-log中，再写入MemStore。每一个HStore只能有一个MemStore。

Read Requests

当一起读取的请求到来的时候，HReginServer会先在MemStore中寻找该数据，当找不到的时候，才会去在StoreFile中寻找。

Cache Flushes

当MemStore到达配置的大小以后，将会创建一个HFile，将其写到磁盘中去。这将减少HReginServer的内存压力。

在读和写的过程中，Cache flushes将会经常发生。当创建一个新的StoreFile的时候，读和写的操作会被挂起，知道新的StoreFile创建好，并被加入到HStroe的管理中后才可以使用。

Compactions

当一定数量的StoreFile超过一个配置的阀值之后，压缩操作就会开始执行。压缩操作的主要工作就是周期性地将一些StoreFile合并成一个StoreFile。

在执行压缩操作的过程中，HReginServer的读和写操作将被挂起，直到操作执行完毕。

Region Splits

当一个HStore所管理的StoreFile超过一个配置（当前是256MB）的值以后，将会执行Region的切分操作。Region的切分操作将原先的Region对半分割为2个新的Region。

在进行Region切分的操作过程中，读和写的操作将被挂起，直到完成为止。

转载请注明源：http://asyty.iteye.com/blog/1250273

评论

2 楼 leibnitz 2014-07-17  

另外，你计算公式：

引用

ROOT表和META表每一行的大小大概是1KB左右。每一个区域的大小是256MB，这意味着ROOT表可以装载2.6 x 105 META区域，转化成用户区域就是6.9 x 1010，转化成可以存储的字节数就是1.8 x 1019  。

是针对 92.x吧？
而且你这个把256M看作是一个region的max size了，感觉也不对。它只是一个store file max size,如果 有多个呢？进一步，如果 有多个store呢？
waiting for u...

1 楼 leibnitz 2014-01-23  

引用

在进行Region切分的操作过程中，读和写的操作将被挂起，直到完成为止。

hbase不是有parent吗，觉得读过程无须block?

同理，compaction也是。

只是在flush时读写是要block

all right?