对HBase bloom Filter的一些讨论

在工作中大家对hbase的bloom filter是否能作用于scan展开讨论。在没讨论前，我还真没想过这个问题，想当然的以为bloom filter肯定可以为scan剔除掉不需要的hfile。但Google了下才发现事实不是如此！

首先，学习了以下2篇文章：

hbase对bf的理解和使用

http://zjushch.iteye.com/blog/1530143

hbase的主要代码提交者对hbase Bloomfilter的解释

http://blog.csdn.net/macyang/article/details/6182629

大概对BloomFilter有了一些了解，然后找到了hbase中对有bloomfilter的table查询的2个优化：

1.get操作会enable bloomfilter帮助剔除掉不会用到的Storefile

在scan初始化时（get会包装为scan）对于每个storefile会做shouldSeek的检查，如果返回false，则表明该storefile里没有要找的内容，直接跳过

[java]  view plain copy

1. <span style="font-size:14px;"> if (memOnly == false  
2.             && ((StoreFileScanner) kvs).shouldSeek(scan, columns)) {  
3.           scanners.add(kvs);  
4.         }</span>  

shouldSeek方法：如果是scan直接返回true表明不能跳过，然后根据bloomfilter类型检查。

[java]  view plain copy

1. <span style="font-size:14px;"> if (!scan.isGetScan()) {  
2.         return true;  
3.       }  
4.   
5.       byte[] row = scan.getStartRow();  
6.       switch (this.bloomFilterType) {  
7.         case ROW:  
8.           return passesBloomFilter(row, 0, row.length, null, 0, 0);  
9.   
10.         case ROWCOL:  
11.           if (columns != null && columns.size() == 1) {  
12.             byte[] column = columns.first();  
13.             return passesBloomFilter(row, 0, row.length, column, 0,   
14.                 column.length);  
15.           }  
16.   
17.           // For multi-column queries the Bloom filter is checked from the  
18.           // seekExact operation.  
19.           return true;  
20.   
21.         default:  
22.           return true;</span>  

2.指明qualified的scan在配了rowcol的情况下会剔除不会用掉的StoreFile。

对指明了qualify的scan或者get进行检查：seekExactly

[java]  view plain copy

1. <span style="font-size:14px;"> // Seek all scanners to the start of the Row (or if the exact matching row  
2.     // key does not exist, then to the start of the next matching Row).  
3.     if (matcher.isExactColumnQuery()) {  
4.       for (KeyValueScanner scanner : scanners)  
5.         scanner.seekExactly(matcher.getStartKey(), false);  
6.     } else {  
7.       for (KeyValueScanner scanner : scanners)  
8.         scanner.seek(matcher.getStartKey());  
9.     }</span>  

如果bloomfilter没命中，则创建一个很大的假的keyvalue，表明该storefile不需要实际的scan

[java]  view plain copy

1. <span style="font-size:14px;">public boolean seekExactly(KeyValue kv, boolean forward)  
2.       throws IOException {  
3.     if (reader.getBloomFilterType() != StoreFile.BloomType.ROWCOL ||  
4.         kv.getRowLength() == 0 || kv.getQualifierLength() == 0) {  
5.       return forward ? reseek(kv) : seek(kv);  
6.     }  
7.   
8.     boolean isInBloom = reader.passesBloomFilter(kv.getBuffer(),  
9.         kv.getRowOffset(), kv.getRowLength(), kv.getBuffer(),  
10.         kv.getQualifierOffset(), kv.getQualifierLength());  
11.     if (isInBloom) {  
12.       // This row/column might be in this store file. Do a normal seek.  
13.       return forward ? reseek(kv) : seek(kv);  
14.     }  
15.   
16.     // Create a fake key/value, so that this scanner only bubbles up to the top  
17.     // of the KeyValueHeap in StoreScanner after we scanned this row/column in  
18.     // all other store files. The query matcher will then just skip this fake  
19.     // key/value and the store scanner will progress to the next column.  
20.     cur = kv.createLastOnRowCol();  
21.     return true;  
22.   }</span>  

这边为什么是rowcol才能剔除storefile纳，很简单，scan是一个范围，如果是row的bloomfilter不命中只能说明该rowkey不在此storefile中，但next rowkey可能在。而rowcol的bloomfilter就不一样了，如果rowcol的bloomfilter没有命中表明该qualifiy不在这个storefile中，因此这次scan就不需要scan此storefile了！

结论如下：

1.任何类型的get（基于rowkey和基于row+col）bloomfilter都能生效，关键是get的类型要匹配bloomfilter的类型

2.基于row的scan是没办法优化的

3.row+col+qualify的scan可以去掉不存在此qualify的storefile，也算是不错的优化了，而且指明qualify也能减少流量，因此scan尽量指明qualify。