Hbase-之Bloom Filter布隆過濾器&Hbase

1 BloomFilter是什么？

布隆過濾器，以它的創始人Burton Howard Bloom的名字命名,首先明確一個點，它只是一個數據結構，這個數據結構最開始被設計成預測一個給定的元素在某個數據集中是否存在，它有如下特點：

• 精確的結果不一定準確，也就是返回的a存在于集合A結果不一定是準確的；
• 不精確的結果一定是對的，即a不存在與集合A那是約等于100%是準確的。

布隆過濾器很適用于類似于Hbase這樣的大數據集，如果想了解更多Bloom Filer可以參閱：布隆過濾器具體算法實現

在Hbase中，BloomFilter提供了一個輕量級的數據結構減少Disk上目標rowkey所在文件Storefiles的讀取次數，BloomFilter只能配合Get使用，不能配合Scan使用，這個東西為集群獲得了更多的并行讀取性能提升（MPP：大規模并行處理）。

BloomFilter被存儲在HFile的MetaData中，從來不需要更新，當一個HFile被open查詢的時候，這個Bloom過濾器就會和metadata一起被加載到BlockCache緩存，一般是加載在LRUBlockCache的高速JVM heap緩存中(L1),而真實data被加載到L2的BucketCache中（l2，堆外內存），具體BlockCache參考：查詢緩存BlockCache

Hbase包含一些調優策略，可以折疊BloomFilter從而減少內存占用，還能保證false精準率在一個可接受的范圍內。

從hbase-0.96 and newer的版本開始，row-based BloomFilter默認就是啟用的，

2 簡單解釋BloomFilter原理

BloomFilter使用的算法如下，看的懂的大神覺得有問題還可以在WIKI上編輯修改，成為貢獻者。

WIKI地址：https://en.wikipedia.org/wiki/Bloom_filter

簡單講解：一個空的BloomFilter實際上就是一個空的bit數組，數組中的數據初始值都是0，下面是一個簡單的BloomFilter的示例。

最開始BloomFilter的初始化長度為18，假設這里有3種基于長度18的hash散列算法，將集合{x,y,z}元素分別散列到數組中的位置，按照不同的hash算法，x,y,z分別在數組中占了3個位置，此時所占位置全都變成1，假如我需要判斷w是否在{x,y,z}中，我們就按照相同的3種hash散列方式，找到w所在的位置，發現有一個位置映射在0的位置，很明顯w不在{x,y,z}中。

假如我們將{x,y,z}當作HFile中的rowkey space，那么每個rowkey都在數組中有3個為1的位置映射，w也當作需要被get的rowkey，很明顯在布隆過濾器中已經顯示不存在w這個rowkey，就省去了到HFile中去查詢的步驟，大大減少了IO消耗和CPU消耗，提升了查詢的性能。

3 布隆過濾器在hbase中與客戶端的交互

了解了上面的section，就知道布隆過濾器大致是什么原理了，那么我們看看如何交互客戶端查詢。

• 上圖的Filter代表BloomFilter
• Storage代表HFile
• 請求從HbaseClient過來

第一次客戶端發來一個請求get(key1)，布隆過濾器回應沒有，那么Store就不會去訪問HFile了；

第二次客戶端發來一個請求get(key2),布隆過濾器回應有,那么Store就去HFile中查詢，并將查詢結果Yes返回；

第三次客戶端發來一個請求get(key2),布隆過濾器回應有，那么Store就去HFile中查詢，但是HFile中沒有，于是將正確的NO返回。

很明顯，布隆過濾器false positive是很精準的，而positive不一定精準，但是也不影響返回結果。

4 什么時候使用BloomFilter

從hbase-0.96+以來，row-based BloomFilter默認就是開啟的，我們可以選擇關閉它或者將它換成row+column的過濾器，這個需要根據你的加載到Hbase的方式以及你的數據的特征。

要確定Bloom過濾器是否可能產生積極影響，請檢查RegionServer指標中的blockCacheHitRatio的值。如果啟用了布隆過濾器，則blockCacheHitRatio的值應增加，因為布隆過濾器正在過濾出絕對不需要的Blocks。

我們可以選擇一個row或者row+column類型的布隆過濾器

• 如果你scan所有行，那么row+column的過濾器是不能帶來任何益處的；
• row類型的布隆過濾器可以適用于row+column的Get操作，反之不行；
• 如果你在一個row中插入了大量的column Put，那么這個row的數據分布在很多個storefile中，一個row類型布隆過濾器總是返回yes,這樣也是沒有起到優化作用；
• 如果你一個row只對應一個column，那么row+column的過濾器會占用更大的space，存儲更多的Keyvalue對象中的key信息，得不償失。
• 當每條rowkey對應的數據條目的數據大小為幾千字節的時候，Bloom過濾器最有效。

當你的數據存儲在少量的大的StoreFile中時，開銷將會減少，從而避免在StoreFile中掃描指定rowkey產生的額外的磁盤IO;記住，在刪除數據之后BloomFilter會自動重建，所以布隆過濾器不適合有大量刪除操作的場景

5 開啟BloomFilter

BloomFilter是啟用在每個ColumnFamily上的，我們可以使用JavaAPI

//我們可以通過ColumnDescriptor來指定開啟的BloomFilter的類型 HColumnDescriptor.setBloomFilterType() //可選NONE、ROW、ROWCOL

我們還可以在創建Table的時候指定BloomFilter

hbase> create 'mytable',{NAME => 'colfam1', BLOOMFILTER => 'ROWCOL'}

6 BloomFilter相關的配置參數

我們可以在hbase-site.xml中配置相關的參數，不想翻譯了，大家伙培養一下英文閱讀能力哈，么么噠～～

ParameterDefaultDescription

io.storefile.bloom.enabled	yes	Set to no to kill bloom filters server-wide if something goes wrong
io.storefile.bloom.error.rate	.01	The average false positive rate for bloom filters. Folding is used to maintain the false positive rate. Expressed as a decimal representation of a percentage.
io.storefile.bloom.max.fold	7	The guaranteed maximum fold rate. Changing this setting should not be necessary and is not recommended.
io.storefile.bloom.max.keys	128000000	For default (single-block) Bloom filters, this specifies the maximum number of keys.
io.storefile.delete.family.bloom.enabled	true	Master switch to enable Delete Family Bloom filters and store them in the StoreFile.
io.storefile.bloom.block.size	131072	Target Bloom block size. Bloom filter blocks of approximately this size are interleaved with data blocks.
hfile.block.bloom.cacheonwrite	false	Enables cache-on-write for inline blocks of a compound Bloom filter.

總結

以上是生活随笔為你收集整理的Hbase-之Bloom Filter布隆过滤器 hbase请求交互的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。