Co2y's Blog

hbase源码阅读

最近在学习hbase之上的索引,趁机阅读了一下hbase的源码。从网上收集了一些资料,记录如下。第一部分是关于数据写入和读取的。

写入

Client写入 -> 存入MemStore,一直到MemStore满 -> Flush成一个StoreFile,直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除 -> 当StoreFiles Compact后,逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer 上,使得原先1个Region的压力得以分流到2个Region上由此过程可知,HBase只是增加数据,有所得更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证I/O高性能。

补充1

HStore存储是HBase存储的核心,其中由两部分组成,一部分是MemStore,一部分是StoreFiles。

补充2

HLog的功能:

在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer以外退出,

MemStore中的内存数据就会丢失,引入HLog就是防止这种情况。

工作机制:每个HRegionServer中都会有一个HLog对象,HLog是一个实现Write Ahead Log的类,每次用户操作写入Memstore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到 StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的 HLog文件,将不同region的log数据拆分,分别放到相应region目录下,然后再将失效的region(带有刚刚拆分的log)重新分配,领取到这些region的 HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。

补充3

Region就是StoreFiles,一个CF对应一个storefile, StoreFiles里由HFile构成,Hfile里由hbase的data块构成,一个data块里面又有很多keyvalue对,每个keyvalue里存了我们需要的值。

读过程

client->zookeeper->.ROOT->.META->用户数据表zookeeper记录了.ROOT的路径信息(root只有一个region),.ROOT里记录了.META的region信息,(.META可能有多个region),.META里面记录了region的信息。

  • 首先,无论是GET还是scan的读数据,都是从RegionScanner的next接口中获取

  • 第二,scanner可分为两种InternalScanner和KeyValueScanner,区别如下:

    1. InternalScanner,可以理解为包含其他scanner的scanner,它的主要接口为next(),作用是从其包含的scanner中获取下一个KeyValue,它的角色可以理解为雇佣KeyValueScanner

    2. KeyValueScanner,从内存或文件中获取KeyValue的scanner,它的主要接口有peek(),seek(KeyValue key),next()等,其中next和peek都能获取scanner中的下一个KeyValue,但是next会移动iterator,peek不会,而seek就是将iterator定位到指定的KeyValue,如果不存在该KeyValue则定位到其后面的那个KeyValue,在scanner初始化的时候都会调用下seek接口,它的角色可以理解为服务InternalScanner

  • 第三,KeyValue 和 KeyValueScanner是可以比较大小的,即他们在优先队列里是排序存放的

    1. KeyValue的大小比较规则,优先级从大到小依次为RowKey cf+cq timestamp type,
      具体点比如说,在比较2个KeyValue时,先比较RowKey的大小(‘a’ < ‘b’),相同的情况下比较cf+cq的大小(‘cf1:q1’<’cf2:q1’<’cf2:q2’),如果还是相同的话就比较时间戳(3042211081<3042211080,注意 我没写错,你没看错,时间戳的long值越大,表示数据越新,在从小到大的队列中越靠前),如果上述仍然还相同则比较TYPE(‘DeleteFamily’ < ‘DeleteColumn’ < ‘Delete’ < Put)

    2. KeyValueScanner的大小比较规则:其大小有peek()获取到KeyValue大小决定,即
      KeyValueScanner1.peek() < KeyValueScanner2.peek() 则KeyValueScanner1 < KeyValueScanner2

看明白以上3点后,则读的流程就比较好懂了,

  1. RegionScanner中有一个scanner的优先队列,当然里面放的是StoreScanner
  2. StoreScanner中也有一个scanner的优先队列,里面放着地是MemStoreScanner和StoreFileScanner,
  3. RegionScanner通过调用next()获取数据时,其实际是从他的scanner队列中poll出一个StoreScanner,然后调用StoreScanner.next()来获取数据,最后再将该StoreScanner继续添加进优先队列中,从而保证队列中的scanner是一直正确有序的
  4. 3中的StoreScanner.next(),其实际是从他的scanner队列中poll出一个StoreFileScanner或者是MemStoreScanner,然后调用next(),再将该scanner添加进队列中

Scan

下面具体介绍具体Scan过程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
+--------------+
| |
+-----------+ RegionScanner+----------+
| +------+-------+ |
| | |
| | |
+-----v+-------+ +------v-------+ +------v+------+
| | | | | |
| StoreScanner | | StoreScanner | | StoreScanner |
| | | | | |
+--------------+ +--+---+-----+-+ +--------------+
| | |
+-----------------------+ | +----------+
| | |
| | |
+-------v---------+ +-------------v----+ +---------v------+
| | | | | |
|StoreFileScanner | |StoreFileScanner | | MemStoreScanner|
| | | | | |
+-------+---------+ +--------+---------+ +-------+--------+
| | |
| | |
| | |
| | |
+-------v---------+ +--------v---------+ +-------v--------+
| | | | | |
| HFileScanner | | HFileScanner | | HFileScanner |
| | | | | |
+-----------------+ +------------------+ +----------------+

RegionScanner、StoreScanner属于InternalScanner, 而MemstoreScanner、StoreFileScanner、StoreScanner属于KeyValueScanner

在HBase中,一张表可以有多个Column Family,在一次Scan的流程中,每个Column Family(后续叫Store)的数据读取由一个StoreScanner对象负责。每个Store的数据由一个内存中的MemStore和磁盘上的HFile文件组成,相对应的,StoreScanner对象雇佣一个MemStoreScanner和N个StoreFileScanner来进行实际的数据读取。

从逻辑上看,读取一行的数据需要

  1. 按照顺序读取出每个Store
  2. 对于每个Store,合并Store下面的相关的HFile和内存中的MemStore
    实现上,这两步都是通过堆完成。RegionScanner的读取通过下面的多个StoreScanner组成的堆
    完成,使用RegionScanner的成员变量KeyValueHeap storeHeap表示

组成StoreScanner的多个Scanner在RegionScannerImpl构造函数中获得:

1
2
3
4
5
6
7
8
9
10
11
12
for (Map.Entry<byte[], NavigableSet<byte[]>> entry :
scan.getFamilyMap().entrySet()) {
Store store = stores.get(entry.getKey());
// 实际是StoreScanner类型
KeyValueScanner scanner = store.getScanner(scan, entry.getValue(), this.readPt);
if (this.filter == null || !scan.doLoadColumnFamiliesOnDemand()
|| this.filter.isFamilyEssential(entry.getKey())) {
scanners.add(scanner);
} else {
joinedScanners.add(scanner);
}
}

store.getScanner(scan, entry.getValue(), this.readPt)内部就是new 一个StoreScanner,逻辑都在StoreScanner的构造函数中

构造函数内部其实就是找到相关的HFile和MemStore,然后建堆,注意,这个堆是StoreScanner级别的,一个StoreScanner一个堆,堆中的元素就是底下包含的HFile和MemStore对应的StoreFileScanner和MemStoreScanner
得到相关的HFile和MemStore逻辑在StoreScanner::getScannersNoCompaction()中,内部会根据请求指定的TimeRange,KeyRange过滤掉不需要的HFile,同时也会利用bloom filter过滤掉不需要的HFIle.接着,调用

1
2
seekScanners(scanners, matcher.getStartKey(), explicitColumnQuery && lazySeekEnabledGlobally,
isParallelSeekEnabled);

对这些StoreFileScanner和MemStoreScanner分别进行seek,seekKey是matcher.getStartKey(),
如下构造

1
2
return new KeyValue(row, family, null, HConstants.LATEST_TIMESTAMP,
Type.DeleteFamily);

补充1

在HBase中,所有的存储文件都被划分成了若干个小存储块,这些小存储块在get或scan操作时会加载到内存中,他们类似于RDBMS中的存储单元页。这个参数的默认大小是64K。通过以上方式设置:void setBlocksize(int s);(HBase中Hfile的默认大小就是64K跟HDFS的块是64M没关系)HBase顺序地读取一个数据块到内存缓存中,其读取相邻的数据时就可以再内存中读取而不需要从磁盘中再次读取,有效地减少了磁盘I/O的次数。这个参数默认为TRUE,这意味着每次读取的块都会缓存到内存中。但是,如果用户顺序读取某个特定的列族,最好将这个属性设置为FALSE,从而禁止使用缓存快。上面这样描述的原因:如果我们访问特定的列族,但是我们还是启用了这个功能,这个时候我们的机制会把我们其它不需要的列族的数据也加载到了内存中,增加了我们的负担,我们使用的条件是,我们获取相邻数据。

参考资料

  1. http://www.cnblogs.com/foxmailed/p/3958546.html
  2. http://my.oschina.net/u/1464779/blog/265137
  3. http://zjushch.iteye.com/blog/1235925