HBase中的Scan操作

Lars
Hofhansl
HBASE-5268提出一个”prefix
delete marker”的建议,大概的思想是

如果数据如下:

row column family:qualifier value

r1 cf1:101 XX

r1 cf1:102 XX

r1 cf1:103 XX
r1 cf1:201 XX

r1 cf1:202 XX

如果我们想删除qualifier 101~103的数据,那么在当前hbase中只能一个接一个删除,即打入三个delete
marker。Lars想引入一个前缀删除机制,即删除某个family下面所有以XX开头的qualifier,这样有一个比较明显的好处就是只需要加一次delete
marker,在一些inner row很多的schema下,要进行range
delete时,这样节省的开销还是很大的。然而这个fix和get的一些逻辑有一定的冲突,后来并未引入到新版本中,Lars也写了一篇博客解释了原因。结合这篇博客和https://issues.apache.org/jira/browse/HBASE-5268的comments
list可以对hbase的scan和delete机制有进一步的了解。

在HBase的Delete操作一文中,已经对HBase的删除做了介绍,文中有一点没有提到就是delete marker的位置。column delete marker和他们影响的KV对保存在一起,而family delete marker永远置顶。

hbase(main):001:0> scan ‘x2’, {RAW=>true, VERSIONS=>10}
ROW COLUMN+CELL
r1 column=f:c, timestamp=1323323611106, value=v3
r1 column=f:c, timestamp=1323323609988, type=DeleteColumn
r1 column=f:c, timestamp=1323323609988, value=v2
r1 column=f:c, timestamp=1323323608554, value=v1
r2 column=f:c, timestamp=1323323617759, value=v3
r2 column=f:c, timestamp=1323323616226, value=v2
r2 column=f:c, timestamp=1323323614496, value=v1
2 row(s) in 0.6380 seconds

上图中,r1对f:c的删除标记是和kv排在一起的,按照timestamp时间戳的先后排序

hbase(main):005:0> scan ‘x1’, {RAW=>true, VERSIONS=>10}
ROW COLUMN+CELL
r2 column=f:, timestamp=1323323616226, type=DeleteFamily
r2 column=f:c, timestamp=1323323617759, value=v3
r2 column=f:c, timestamp=1323323616226, value=v2
r2 column=f:c, timestamp=1323323614496, value=v1
2 row(s) in 0.0500 seconds
上图中,删除column family f的操作是排在最前面的,尽管从时间顺序上它是发生在v2之后,插入v3之前。
在HBase的存储结构中,每个Column family对应的是一个Store,数据存储在数个Storefile中。Scan在Hbase中类似于由RegionScanner进行的MergeSort,由StoreFileScanner,StoreScanner和RegionScanner将结果一级一级汇总。

                                              RegionScanner                                                    /                     \                               StoreScanner                      StoreScanner                               /                   \                      /                  \        StoreFileScanner   StoreFileScanner   StoreFileScanner  StoreFileScanner                   |                             |                            |                          |             StoreFile                  StoreFile                StoreFile              StoreFile

当我们进行如下一系列操作时:

put: row1, family, col1, value1, T
delete family: row1, family, T+1
put: row1, family, col1, value2, T+2
delete columns: row1, family, col1, T+3
put: row1, family, col1, value3, T+4

实际上,存下来的数据格式类似于

family-delete row1, T+1

row1,col1,value3, T+4

column-delete row1,col1, T+3

row1,col1,value2, T+2

row1,col1,value1, T

family delete marker在最前面是因为它会影响到很多行数据,所以Hbase进行了优化,让Scanner一开始就可以知道它,然后继续向下扫。这就带来了如下结果:

就算我们想找到一个特定的Qualifier对应的Value,我们也需要先seek到这行的开始来看看是否有family delete marker,他们的时间戳是否大于等于我们感兴趣的那个qualifier-value的version。

Lars对Prefix delete marker一开始的设计是让它处于kv对之间,如同column delete marker一样,但是这样的设计会带来如下问题:

一个row或者一个Qualifier的开始是一个定点,然而一个Qualifier
prefix不一定。如当前qualifier有1013,102,103,我们可以认为Qualifier
prefix为10的点在1013前面,然而如果我们加入一个新的Qualifier1012,那么这个点就要在1012前面,为了确定某个qualifier是否被删掉,scanner必须扫描所有可能影响到他的prefix
marker,而这个很可能需要进行全表扫描,开销太大。

然后Lars改变了prefix delete
marker的位置,把他等同于family delete
marker,也就是在行内置顶,这样做可以work,不过会有一些潜在的问题。因为对于每一个row,delete
family的次数不会太多,因为一个storefile只有一个column
family,所以对于scanner来说,它只需要记住这个family delete发生的时间戳,而prefix
delete可能会很多,组合也会比较复杂,如果每扫到一行KV,都要对delete
marker集合进行判断,scan开销就会较大,也就达不到一开始设计的初衷了。于是最后他们决定won‘t
fix,不过patch做好了,只是不会加入新版本中。如果业务中有这样的需求:需要对某些具有共同前缀的qualifier进行删除,然而这种删除操作不太频繁(每两次major
compaction之间这样的操作在少数几次),那么可以考虑加入这个patch,这样可以优化下存储和删除的效率。

PS:在jira里面,他们讨论的还是很热烈的,差不多一天内lars改了6版,真勤奋啊~

    原文作者:虾米在海飘
    原文地址: https://www.jianshu.com/p/f4ea2f0d9b94
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞