解釋一下布隆過濾器原理

鎖屏面試題百日百刷，每個作業日堅持更新面試題，請看到最后就能獲取你想要的,接下來的是今日的面試題：

1.解釋一下布隆過濾器原理

在日常生活中，包括在設計計算機軟體時，我們經常要判斷一個元素是否在一個集合中，比如在字處理軟體中，需要檢查一個英語單詞是否拼寫正確（也就是要判斷它是否在已知的字典中）；在 FBI，一個嫌疑人的名字是否已經在嫌疑名單上；在網路爬蟲里，一個網址是否被訪問過等等，最直接的方法就是將集合中全部的元素存在計算機中，遇到一個新元素時，將它和集合中的元素直接比較即可，一般來講，計算機中的集合是用哈希表（hash table）來存盤的，它的好處是快速準確，缺點是費存盤空間，當集合比較小時，這個問題不顯著，但是當集合巨大時，哈希表存盤效率低的問題就顯現出來了，比如說，一個象 Yahoo,Hotmail 和 Gmai 那樣的公眾電子郵件（email）提供商，總是需要過濾來自發送垃圾郵件的人（spamer）的垃圾郵件，一個辦法就是記錄下那些發垃圾郵件的 email地址，由于那些發送者不停地在注冊新的地址，全世界少說也有幾十億個發垃圾郵件的地址，將他們都存起來則需要大量的網路服務器，如果用哈希表，每存盤一億個 email 地址， 就需要 1.6GB 的記憶體（用哈希表實作的具體辦法是將每一個 email 地址對應成一個八位元組的資訊指紋googlechinablog.com/2006/08/blog-post.html，然后將這些資訊指紋存入哈希表，由于哈希表的存盤效率一般只有 50%，因此一個 email 地址需要占用十六個位元組，

一億個地址大約要 1.6GB， 即十六億位元組的記憶體），因此存貯幾十億個郵件地址可能需要上百 GB 的記憶體，除非是超級計算機，一般服務器是無法存盤的，

布隆過濾器只需要哈希表 1/8 到 1/4 的大小就能解決同樣的問題，

Bloom Filter是一種空間效率很高的隨機資料結構，它利用位陣列很簡潔地表示一個集合，并能判斷一個元素是否屬于這個集合，Bloom Filter的這種高效是有一定代價的：在判斷一個元素是否屬于某個集合時，有可能會把不屬于這個集合的元素誤認為屬于這個集合（false positive），因此，Bloom Filter不適合那些“零錯誤”的應用場合，

而在能容忍低錯誤率的應用場合下，Bloom Filter通過極少的錯誤換取了存盤空間的極大節省，

下面我們具體來看Bloom Filter是如何用位陣串列示集合的，初始狀態時，Bloom Filter是一個包含m位的位陣列，每一位都置為0，

為了表達S={x1, x2,…,xn}這樣一個n個元素的集合，Bloom Filter使用k個相互獨立的哈希函式（Hash Function）， 它們分別將集合中的每個元素映射到{1,…,m}的范圍中，對任意一個元素x，第i個哈希函式映射的位置hi(x)就會被置 為1（1≤i≤k），注意，如果一個位置多次被置為1，那么只有第一次會起作用，后面幾次將沒有任何效果，在下圖中， k=3，且有兩個哈希函式選中同一個位置（從左邊數第五位），

在判斷y是否屬于這個集合時，我們對y應用k次哈希函式，如果所有hi(y)的位置都是1（1≤i≤k），那么我們就認為y是集合中的元素，否則就認為y不是集合中的元素，下圖中y1就不是集合中的元素，y2或者屬于這個集合，或者剛好是一個false positive，

· 為了add一個元素，用k個hash function將它hash得到bloom filter中k個bit位，將這k個bit位置1，

· 為了query一個元素，即判斷它是否在集合中，用k個hash function將它hash得到k個bit位，若這k bits全為1，則此元素在集合中；若其中任一位不為1，則此元素比不在集合中（因為如果在，則在add時已經把對應的k個bits位置為1），

· 不允許remove元素，因為那樣的話會把相應的k個bits位置為0，而其中很有可能有其他元素對應的位，因此remove會引入false negative，這是絕對不被允許的，

布隆過濾器決不會漏掉任何一個在黑名單中的可疑地址，但是，它有一條不足之處，也就是它有極小的可能將一個不在黑名單中的電子郵件地址判定為在黑名單中，因為有可能某個好的郵件地址正巧對應個八個都被設定成一的二進制位，好在這種可能性很小，我們把它稱為誤識概率，

布隆過濾器的好處在于快速，省空間，但是有一定的誤識別率，常見的補救辦法是在建立一個小的白名單，存盤那些可能別誤判的郵件地址，

2.如何實作HBase的二級索引?

方案一: 通常情況下,較原生方式,我們可以采用ES或者Solr來實作hbase的二級索引的操作, 當用戶要寫入資料時候, 基于hbase的observer協處理器攔截下來, 使用es或者Solr來構建hbase的索引資料, 這樣當查詢hbase中資料時候, 可以先去ES中查詢到對應的資料, 然后根據結果, 在從hbase中獲取最終的完整的結果

方案二: 基于Phoenix實作, Phoenix是一款基于hbase的SQL客戶端, 可以使用SQL的方式來操作hbase, 同時為了提升整體的查詢性能, Phoenix中提供了各種索引(全域索引, 本地索引, 覆寫索引以及函式索引), 這些索引都是基于Hbase的協處理器(主要是ObServer協處理器)而實作的, 二基于索引的查詢方案, 也是Phoenix實作hbase二級索引的方式

3.Hbase的storeFile(compact)合并機制是什么?

compact合并機制:

指的memStore中不斷進行flush重繪操作, 就會產生多個storeFile的檔案, 當storeFile的文

件達到一定閾值后, 就會觸發compact的合并機制, 將多個storeFile合并為一個大的HFile檔案

閾值: 達到3個及以上

整個合并程序分為兩大階段:

minor :

作用: 將多個小的storeFile合并為一個較大的Hfile操作

閾值: 達到3個及以上

注意: 此合并程序, 僅僅將多個合并為一個, 對資料進行排序操作, 如果此時資料有過期, 或者有標記為洗掉資料, 此時不做任何的處理 (類似于 記憶體合并中基礎型)

所以說, 此合并操作, 效率比較高

major:

作用: 將較大的HFile 和 之前的大的Hfile進行合并形成一個更大的Hfile檔案 (全域合并)

閾值: 默認 7天

注意: 此合并程序, 會將那些過期的資料, 或者已經標記洗掉的資料, 在這次合并中, 全部

都清除掉，由于這是一種全域合并操作, 對性能影響比較大, 在實際生產中, 建議 關閉掉自動合并, 采用手動觸發的方案

4.Hbase的flush重繪機制?

flush重繪機制(溢寫合并機制):

流程: 客戶端不斷將資料寫入到memStore記憶體中, 當記憶體中資料達到一定閾值后, 需要

將資料溢寫重繪的HDFS中 形成一個storeFile檔案

閾值: 128M 或者 1小時 滿足了那個都會觸發flush機制

內部詳細流程: hbase 2.0架構 以上流程

1. 客戶端不斷向memStore中寫入資料, 當memStore只資料達到閾值后, 就會啟動flush操作

2. 首先hbase會先關閉掉當前這個已經達到閾值的記憶體空間, 然后開啟一個新的memStore的空間,用于繼續寫入作業

3. 將這個達到閾值的記憶體空間資料放入到 記憶體佇列中, 此佇列的特性是只讀, 在hbase 2.0架構中, 可以設定此佇列的資料盡可能晚的重繪到HDFS中, 當這個佇列中資料達到某個閾值后(記憶體不足), 這個時候觸發flush重繪操作 (佇列中可能存盤了多個memStore的資料)

4. flush執行緒會將佇列中所有的資料全部讀取出來, 然后對資料進行排序合并操作, 將合并后資料存盤到HDFS中, 形成一個storeFile的檔案

注意: 在 hbase2.0以下的架構中, 不存在推遲重繪功能, 同樣也不存在 合并資料的

操作當memStore資料達到閾值后, 放入到佇列中, 專門有一個flush重繪監控佇列, 一旦有資料直接重繪到HDFS上

注意說明:

hbase 2.0 只是提供了基于記憶體的合并功能, 但是默認情況下 不開啟的, 所以 在默認情況

下 整個flush機制基本和2.0以下的版本是一致的, 但是一旦開啟了, 就是剛剛描述流程

合并方案: 三種基礎型(basic): 直接將多個memStore資料合并在一起直接重繪到HDFS上,如果資料存在過期的資料, 或者是已經標記為洗掉的資料, 基礎型不做任何處理

饑渴型(eager): 在將多個memStore合并的程序中, 積極判斷資料是否存在過期, 或者是否已經標記洗掉, 如果有, 直接過濾掉這些標記洗掉和過期的資料即可

適應性(adaptive): 檢查資料是否有過期資料, 如果過期資料量達到一定閾值后, 就會自動使

用饑渴型, 否則就使用基礎型

5.如何解決hbase中資料熱點問題?

所謂資料熱點, 指的是大量的資料寫到hbase的某一個或者某幾個region中, 導致其余的region沒有資料, 其他region對應regionServer的節點承受了大量的并發請求, 此時就出現了熱點問題

解決方案: 通過預磁區和設計良好的rowkey來解決

1)加鹽處理(加亂數) : 可以在rowkey前面動態添加一些亂數, 從而保證資料可以均勻落在不同region中

n 基本保證資料落在不同region

n 將相關性比較強的資料分散在不同的額region中, 導致查詢的效率有一定降低

2)hash處理: 根據rowkey計算其hash值, 在rowkey前面hash計算值即可 (MD5 HASH)

n 讓相關性比較強的資料可以被放置到同一個region中

n 如果相關資料比較多, 依然會導致熱點問題

3)反轉策略: 比如說手機號反轉 或者 時間戳的反轉

n 好處: 基本保證資料落在不同region

n 弊端: 將相關性比較強的資料分散在不同的region中, 導致查詢的效率有一定降低

全部內容在git上,了解更多請點我頭像或到我的主頁去獲得，謝謝

標籤：其他

上一篇：sql 截取表中指定欄位

下一篇：大資料 + VR 全景技術重塑“二手車買車場景”