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