HBase中的Scan操作

最新推荐文章于 2023-04-14 16:49:26 发布

jdr0212

最新推荐文章于 2023-04-14 16:49:26 发布

阅读量2.7k

点赞数

分类专栏： Hadoop&HBase 文章标签： hbase scan 翻译

Hadoop&HBase 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

之前翻译的两篇文章，第一次尝试，留作参考

http://hadoop-hbase.blogspot.com/2012/01/scanning-in-hbase.html

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版，真勤奋啊~