基本概念
布隆過濾器［1］Bloom Filter是由布隆（Burton Howard Bloom）在1970年提出的。它實際上是由一個很長的二進制向量和一系列隨機映射函數組成，布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率（假正例False positives，即Bloom Filter報告某一元素存在於某集合中，但是實際上該元素並不在集合中）和刪除困難，但是沒有識別錯誤的情形（即假反例False negatives，如果某個元素確實沒有在該集合中，那麼Bloom Filter 是不會報告該元素存在於集合中的，所以不會漏報）。
在日常生活中，包括在設計計算機軟件時，我們經常要判斷一個元素是否在一個集合中。比如在字處理軟件中，需要檢查一個英語單詞是否拼寫正確（也就是要判斷 它是否在已知的字典中）；在 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 的內存。除非是超級計算機，一般服務器是無法存儲的［2］。（該段引用谷歌數學之美：http://www.google.com.hk/ggblog/googlechinablog/2007/07/bloom-filter_7469.html）
如果想判斷一個元素是不是在一個集合裏，一般想到的是將所有元素保存起來，然後通過比較確定。鏈表，樹等等數據結構都是這種思路. 但是隨着集合中元素的增加，我們需要的存儲空間越來越大，檢索速度也越來越慢。不過世界上還有一種叫作散列表（又叫哈希表，Hash table）的數據結構。它可以通過一個Hash函數將一個元素映射成一個位陣列（Bit Array）中的一個點。這樣一來，我們只要看看這個點是不是 1 就知道可以集合中有沒有它了。這就是布隆過濾器的基本思想。
Hash面臨的問題就是衝突。假設 Hash 函數是良好的，如果我們的位陣列長度爲 m 個點，那麼如果我們想將衝突率降低到例如 1%, 這個散列表就只能容納 m/100 個元素。顯然這就不叫空間有效了（Space-efficient）。解決方法也簡單，就是使用多個 Hash，如果它們有一個說元素不在集合中，那肯定就不在。如果它們都說在，雖然也有一定可能性它們在說謊，不過直覺上判斷這種事情的概率是比較低的。
簡單的說，bloom算法有點類似於hashset，用來判斷某個元素（key）是否在某個集合中。
和一般的HashSet不同的是，這個算法無需存儲key的值，對於每個key，只需要k個比特位，每個存儲一個標誌，用來判斷key是否在集合中。
優點
相比於其它的數據結構，布隆過濾器在空間和時間方面都有巨大的優勢。布隆過濾器存儲空間和插入/查詢時間都是常數。另外, Hash 函數相互之間沒有關係，方便由硬件並行實現。布隆過濾器不需要存儲元素本身，在某些對保密要求非常嚴格的場合有優勢。
布隆過濾器可以表示全集，其它任何數據結構都不能；
k 和 m 相同，使用同一組 Hash 函數的兩個布隆過濾器的交併差運算可以使用位操作進行。
缺點
但是布隆過濾器的缺點和優點一樣明顯。誤算率（False Positive）是其中之一。隨着存入的元素數量增加，誤算率隨之增加。但是如果元素數量太少，則使用散列表足矣。
另外，一般情況下不能從布隆過濾器中刪除元素. 我們很容易想到把位列陣變成整數數組，每插入一個元素相應的計數器加1, 這樣刪除元素時將計數器減掉就可以了。然而要保證安全的刪除元素並非如此簡單。首先我們必須保證刪除的元素的確在布隆過濾器裏面. 這一點單憑這個過濾器是無法保證的。另外計數器迴繞也會造成問題。
典型的應用場景：
假設現在有一家搜索公司，有30億個URL，但是，有些URL是非法的，需要將某些URL拉入"黑名單"，即是用戶訪問“黑名單”中的url的時候，不會返回對應的頁面 。
在業務中分析中，只需要在訪問“黑名單”的時候，返回一個true即可。
【解決方案一】：
搭建分佈式處理系統，使用hash函數的性質，首先對每個URL計算出HASH值，使其根據HASH值取餘操作在不同的服務器進行處理。此時HASH函數主要作用爲數據分流 。 對服務器無法處理的樣本量，用同種方式採用分流的方法一直到服務器能夠處理的地步。
【解決方案二】：
使用布隆過濾器，對每個URL作爲HASH函數的輸入，對每一個URL分別用不同並相對獨立的HASH函數來計算出對應的hash值，對計算出的hash值用數組的長度取餘，並將相應的bit數組中的元素的值置爲1 . 如圖1.
如何判斷URL是否有效，同樣對需要判斷的URL使用K個hash函數計算出相應的hash值，如果每個都爲1,說明此次的URL爲黑名單中的元素。反之，則不是。
爲什麼說會有錯誤率？
對一個URL計算hash值，找出bit數組對應位置值時，可能bit數組中對應位置值已經被其他URL在進入過濾器的時候置爲了1 .
產生這種情況可能又兩種原因：
- hash函數個數過少
- bit數組長度較小
根據上面的示例，讓我們上升到理論層面：
即使錯誤率和hash函數個數，和bit數組長度有關，他們的關係是？
False positives 概率推導
假設 Hash 函數以等概率條件選擇並設置 Bit Array 中的某一位，m 是該位數組的大小，k 是 Hash 函數的個數，那麼位數組中某一特定的位在進行元素插入時的 Hash 操作中沒有被置位的概率是：
那麼在所有 k 次 Hash 操作後該位都沒有被置 “1” 的概率是：
如果我們插入了 n 個元素，那麼某一位仍然爲 “0” 的概率是：
因而該位爲 "1"的概率是：
現在檢測某一元素是否在該集合中。標明某個元素是否在集合中所需的 k 個位置都按照如上的方法設置爲 “1”，但是該方法可能會使算法錯誤的認爲某一原本不在集合中的元素卻被檢測爲在該集合中（False Positives），該概率由以下公式確定：
其實上述結果是在假定由每個 Hash 計算出需要設置的位（bit） 的位置是相互獨立爲前提計算出來的，不難看出，隨着 m （位數組大小）的增加，假正例（False Positives）的概率會下降，同時隨着插入元素個數 n 的增加，False Positives的概率又會上升，對於給定的m，n，如何選擇Hash函數個數 k 由以下公式確定：
此時False Positives的概率爲：
而對於給定的False Positives概率 p，如何選擇最優的位數組大小 m :
上式表明，位數組的大小最好與插入元素的個數成線性關係，對於給定的 m，n，k，假正例概率最大爲：
下圖是布隆過濾器假正例概率 p 與位數組大小 m 和集合中插入元素個數 n 的關係圖，假定 Hash 函數個數選取最優數目：
典型用例
Google 著名的分佈式數據庫 Bigtable 使用了布隆過濾器來查找不存在的行或列，以減少磁盤查找的IO次數[3]。
Squid 網頁代理緩存服務器在 cache digests 中使用了也布隆過濾 [4]。
Venti 文檔存儲系統也採用布隆過濾器來檢測先前存儲的數據[5]。
SPIN 模型檢測器也使用布隆過濾器在大規模驗證問題時跟蹤可達狀態空間[6]。
Google Chrome瀏覽器使用了布隆過濾器加速安全瀏覽服務[7]。
總結
【算法】：
- 首先需要k個hash函數，每個函數可以把key散列成爲1個整數
- 初始化時，需要一個長度爲n比特的數組，每個比特位初始化爲0
- 某個key加入集合時，用k個hash函數計算出k個散列值，並把數組中對應的比特位置爲1
- 判斷某個key是否在集合時，用k個hash函數計算出k個散列值，並查詢數組中對應的比特位，如果所有的比特位都是1，認爲在集合中。
優點：不需要存儲key，節省空間
缺點：
- 算法判斷key在集合中時，有一定的概率key其實不在集合中
- 無法刪除
參考：
https://www.cnblogs.com/liyulong1982/p/6013002.html
［1］維基百科：布隆過濾器：http://zh.wikipedia.org/zh/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8
［2］數學之美二十一：布隆過濾器（Bloom Filter）：http://www.google.com.hk/ggblog/googlechinablog/2007/07/bloom-filter_7469.html
[3］Chang, Fay; Dean, Jeffrey; Ghemawat, Sanjay; Hsieh, Wilson; Wallach, Deborah; Burrows, Mike; Chandra, Tushar; Fikes, Andrew et al. (2006), “Bigtable: A Distributed Storage System for Structured Data”, Seventh Symposium on Operating System Design and Implementation
［4］Wessels, Duane (January 2004), “10.7 Cache Digests”, Squid: The Definitive Guide (1st ed.), O’Reilly Media, p. 172, ISBN 0-596-00162-2, “Cache Digests are based on a technique first published by Pei Cao, called Summary Cache. The fundamental idea is to use a Bloom filter to represent the cache contents.”
［5］http://plan9.bell-labs.com/magic/man2html/8/venti
［6］http://spinroot.com/
［7］http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/safe_browsing/bloom_filter.h?view=markup