處理海量數據問題,無非就是:面試
分而治之/hash映射 + hash統計 + 堆/快速/歸併排序;算法
Bloom filter/Bitmap;數據庫
Trie樹/數據庫/倒排索引;數組
外排序;數據結構
分佈式處理之hadoop/mapreduce。架構
本文接下來的部分,便針對這5種方法模式結合對應的海量數據處理面試題分別具體闡述。app
密匙1、分而治之/hash映射 + hash統計 + 堆/快速/歸併排序
框架
一、海量日誌數據,提取出某日訪問百度次數最多的那個IP。 分佈式
既然是海量數據處理,那麼可想而知,給咱們的數據那就必定是海量的。針對這個數據的海量,咱們如何着手呢?對的,無非就是分而治之/hash映射 + hash統計 + 堆/快速/歸併排序,說白了,就是先映射,然後統計,最後排序:函數
分而治之/hash映射:針對數據太大,內存受限,智能是:把大文件化成(取模映射)小文件,即16字方針:大而化小,各個擊破,縮小規模,逐個解決
hash統計:當大文件轉化了小文件,那麼咱們即可以採用常規的hashmap(ip,value)來進行頻率統計。
堆/快速排序:統計完了以後,便進行排序(可採起堆排序),獲得次數最多的IP。
具體而論,則是: 「首先是這一天,而且是訪問百度的日誌中的IP取出來,逐個寫入到一個大文件中。注意到IP是32位的,最多有個2^32個IP。一樣能夠採用映射的方法,好比模1000,把整個大文件映射爲1000個小文件,再找出每一個小文中出現頻率最大的IP(能夠採用hash_map進行頻率統計,而後再找出頻率最大的幾個)及相應的頻率。而後再在這1000個最大的IP中,找出那個頻率最大的IP,即爲所求。」--十道海量數據處理面試題與十個方法大總結。
但若是數據規模比較小,能一次性裝入內存呢?好比下面的這道題,題目中說,雖然有一千萬個Query,可是因爲重複度比較高,所以事實上只有300萬的Query,每一個Query255Byte,所以咱們能夠考慮把他們都放進內存中去,而如今只是須要一個合適的數據結構,在這裏,Hash Table絕對是咱們優先的選擇。OK,請看第2題:
二、搜索引擎會經過日誌文件把用戶每次檢索使用的全部檢索串都記錄下來,每一個查詢串的長度爲1-255字節。
假設目前有一千萬個記錄(這些查詢串的重複度比較高,雖然總數是1千萬,但若是除去重複後,不超過3百萬個。一個查詢串的重複度越高,說明查詢它的用戶越多,也就是越熱門。),請你統計最熱門的10個查詢串,要求使用的內存不能超過1G。
前面說了,數據比較小,摒棄分而治之/hash映射的方法,直接上hash統計,而後排序。So,
hash統計先對這批海量數據預處理(維護一個Key爲Query字串,Value爲該Query出現次數的HashTable,即hashmap(Query,Value),每次讀取一個Query,若是該字串不在Table中,那麼加入該字串,而且將Value值設爲1;若是該字串在Table中,那麼將該字串的計數加一便可。最終咱們在O(N)的時間複雜度內用Hash表完成了統計;
堆排序:第二步、藉助堆這個數據結構,找出Top K,時間複雜度爲N‘logK。即藉助堆結構,咱們能夠在log量級的時間內查找和調整/移動。所以,維護一個K(該題目中是10)大小的小根堆,而後遍歷300萬的Query,分別和根元素進行對比因此,咱們最終的時間複雜度是:O(N) + N'*O(logK),(N爲1000萬,N’爲300萬)。
別忘了這篇文章中所述的堆排序思路:「維護k個元素的最小堆,即用容量爲k的最小堆存儲最早遍歷到的k個數,並假設它們便是最大的k個數,建堆費時O(k),並調整堆(費時O(logk))後,有k1>k2>...kmin(kmin設爲小頂堆中最小元素)。繼續遍歷數列,每次遍歷一個元素x,與堆頂元素比較,若x>kmin,則更新堆(用時logk),不然不更新堆。這樣下來,總費時O(k*logk+(n-k)*logk)=O(n*logk)。此方法得益於在堆中,查找等各項操做時間複雜度均爲logk。」--第三章、尋找最小的k個數。
固然,你也能夠採用trie樹,關鍵字域存該查詢串出現的次數,沒有出現爲0。最後用10個元素的最小推來對出現頻率進行排序。
由上面這兩個例題,分而治之 + hash統計 + 堆/快速排序這個套路,咱們已經開始有了屢試不爽的感受。下面,再拿幾道再多多驗證下。請看第3題:
三、有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16字節,內存限制大小是1M。返回頻數最高的100個詞。
又是文件很大,又是內存受限,咋辦?還能怎麼辦呢?無非仍是
分而治之/hash映射:順序讀文件中,對於每一個詞x,取hash(x)%5000,而後按照該值存到5000個小文件(記爲x0,x1,...x4999)中。這樣每一個文件大概是200k左右。若是其中的有的文件超過了1M大小,還能夠按照相似的方法繼續往下分,直到分解獲得的小文件的大小都不超過1M。
hash統計:對每一個小文件,採用trie樹/hash_map等統計每一個文件中出現的詞以及相應的頻率。
堆/歸併排序:取出出現頻率最大的100個詞(能夠用含100個結點的最小堆),並把100個詞及相應的頻率存入文件,這樣又獲得了5000個文件。最後就是把這5000個文件進行歸併(相似與歸併排序)的過程了。
四、有10個文件,每一個文件1G,每一個文件的每一行存放的都是用戶的query,每一個文件的query均可能重複。要求你按照query的頻度排序。
直接上:
hash映射:順序讀取10個文件,按照hash(query)%10的結果將query寫入到另外10個文件(記爲)中。這樣新生成的文件每一個的大小大約也1G(假設hash函數是隨機的)。
hash統計:找一臺內存在2G左右的機器,依次對用hash_map(query, query_count)來統計每一個query出現的次數。注:hash_map(query,query_count)是用來統計每一個query的出現次數,不是存儲他們的值,出現一次,則count+1。
堆/快速/歸併排序:利用快速/堆/歸併排序按照出現次數進行排序。將排序好的query和對應的query_cout輸出到文件中。這樣獲得了10個排好序的文件(記爲)。對這10個文件進行歸併排序(內排序與外排序相結合)。
除此以外,此題還有如下兩個方法:
方案2:通常query的總量是有限的,只是重複的次數比較多而已,可能對於全部的query,一次性就能夠加入到內存了。這樣,咱們就能夠採用trie樹/hash_map等直接來統計每一個query出現的次數,而後按出現次數作快速/堆/歸併排序就能夠了。
方案3:與方案1相似,但在作完hash,分紅多個文件後,能夠交給多個文件來處理,採用分佈式的架構來處理(好比MapReduce),最後再進行合併。
五、 給定a、b兩個文件,各存放50億個url,每一個url各佔64字節,內存限制是4G,讓你找出a、b文件共同的url?
能夠估計每一個文件安的大小爲5G×64=320G,遠遠大於內存限制的4G。因此不可能將其徹底加載到內存中處理。考慮採起分而治之的方法。
分而治之/hash映射:遍歷文件a,對每一個url求取,而後根據所取得的值將url分別存儲到1000個小文件(記爲)中。這樣每一個小文件的大約爲300M。遍歷文件b,採起和a相同的方式將url分別存儲到1000小文件中(記爲)。這樣處理後,全部可能相同的url都在對應的小文件()中,不對應的小文件不可能有相同的url。而後咱們只要求出1000對小文件中相同的url便可。
hash統計:求每對小文件中相同的url時,能夠把其中一個小文件的url存儲到hash_set中。而後遍歷另外一個小文件的每一個url,看其是否在剛纔構建的hash_set中,若是是,那麼就是共同的url,存到文件裏面就能夠了。
OK,此第一種方法:分而治之/hash映射 + hash統計 + 堆/快速/歸併排序,再看最後三道題,以下:
八、怎麼在海量數據中找出重複次數最多的一個?
方案1:先作hash,而後求模映射爲小文件,求出每一個小文件中重複次數最多的一個,並記錄重複次數。而後找出上一步求出的數據中重複次數最多的一個就是所求(具體參考前面的題)。
九、上千萬或上億數據(有重複),統計其中出現次數最多的錢N個數據。
方案1:上千萬或上億的數據,如今的機器的內存應該能存下。因此考慮採用hash_map/搜索二叉樹/紅黑樹等來進行統計次數。而後就是取出前N個出現次數最多的數據了,能夠用第2題提到的堆機制完成。
十、一個文本文件,大約有一萬行,每行一個詞,要求統計出其中最頻繁出現的前10個詞,請給出思想,給出時間複雜度分析。
方案1:這題是考慮時間效率。用trie樹統計每一個詞出現的次數,時間複雜度是O(n*le)(le表示單詞的平準長度)。而後是找出出現最頻繁的前10個詞,能夠用堆來實現,前面的題中已經講到了,時間複雜度是O(n*lg10)。因此總的時間複雜度,是O(n*le)與O(n*lg10)中較大的哪個。
接下來,我們來看第二種方法,Bitmap。
關於什麼是Bloom filter,請參看此文:海量數據處理之Bloom Filter詳解。
適用範圍:能夠用來實現數據字典,進行數據的判重,或者集合求交集
基本原理及要點:
對於原理來講很簡單,位數組+k個獨立hash函數。將hash函數對應的值的位數組置1,查找時若是發現全部hash函數對應位都是1說明存在,很明顯這個過程並不保證查找的結果是100%正確的。同時也不支持刪除一個已經插入的關鍵字,由於該關鍵字對應的位會牽動到其餘的關鍵字。因此一個簡單的改進就是 counting Bloom filter,用一個counter數組代替位數組,就能夠支持刪除了。
還有一個比較重要的問題,如何根據輸入元素個數n,肯定位數組m的大小及hash函數個數。當hash函數個數k=(ln2)*(m/n)時錯誤率最小。在錯誤率不大於E的狀況下,m至少要等於n*lg(1/E)才能表示任意n個元素的集合。但m還應該更大些,由於還要保證bit數組裏至少一半爲0,則m應該>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2爲底的對數)。
舉個例子咱們假設錯誤率爲0.01,則此時m應大概是n的13倍。這樣k大概是8個。
注意這裏m與n的單位不一樣,m是bit爲單位,而n則是以元素個數爲單位(準確的說是不一樣元素的個數)。一般單個元素的長度都是有不少bit的。因此使用bloom filter內存上一般都是節省的。
擴展:
Bloom filter將集合中的元素映射到位數組中,用k(k爲哈希函數個數)個映射位是否全1表示元素在不在這個集合中。Counting bloom filter(CBF)將位數組中的每一位擴展爲一個counter,從而支持了元素的刪除操做。Spectral Bloom Filter(SBF)將其與集合元素的出現次數關聯。SBF採用counter中的最小值來近似表示元素的出現頻率。
問題實例:給你A,B兩個文件,各存放50億條URL,每條URL佔用64字節,內存限制是4G,讓你找出A,B文件共同的URL。若是是三個乃至n個文件呢?
根據這個問題咱們來計算下內存的佔用,4G=2^32大概是40億*8大概是340億,n=50億,若是按出錯率0.01算須要的大概是650億個bit。如今可用的是340億,相差並很少,這樣可能會使出錯率上升些。另外若是這些urlip是一一對應的,就能夠轉換成ip,則大大簡單了。
同時,上文的第5題:給定a、b兩個文件,各存放50億個url,每一個url各佔64字節,內存限制是4G,讓你找出a、b文件共同的url?若是容許有必定的錯誤率,可使用Bloom filter,4G內存大概能夠表示340億bit。將其中一個文件中的url使用Bloom filter映射爲這340億bit,而後挨個讀取另一個文件的url,檢查是否與Bloom filter,若是是,那麼該url應該是共同的url(注意會有必定的錯誤率)。
至於什麼是Bitmap,請看此文:http://blog.csdn.net/v_july_v/article/details/6685962。下面關於Bitmap的應用,直接上題,以下第六、7道:
六、在2.5億個整數中找出不重複的整數,注,內存不足以容納這2.5億個整數。
方案1:採用2-Bitmap(每一個數分配2bit,00表示不存在,01表示出現一次,10表示屢次,11無心義)進行,共需內存2^32 * 2 bit=1 GB內存,還能夠接受。而後掃描這2.5億個整數,查看Bitmap中相對應位,若是是00變01,01變10,10保持不變。所描完過後,查看bitmap,把對應位是01的整數輸出便可。
方案2:也可採用與第1題相似的方法,進行劃分小文件的方法。而後在小文件中找出不重複的整數,並排序。而後再進行歸併,注意去除重複的元素。
七、騰訊面試題:給40億個不重複的unsigned int的整數,沒排過序的,而後再給一個數,如何快速判斷這個數是否在那40億個數當中?
方案1:oo,申請512M的內存,一個bit位表明一個unsigned int值。讀入40億個數,設置相應的bit位,讀入要查詢的數,查看相應bit位是否爲1,爲1表示存在,爲0表示不存在。
Trie樹
適用範圍:數據量大,重複多,可是數據種類小能夠放入內存
基本原理及要點:實現方式,節點孩子的表示方式
擴展:壓縮實現。
問題實例:
1).有10個文件,每一個文件1G,每一個文件的每一行都存放的是用戶的query,每一個文件的query均可能重複。要你按照query的頻度排序。
2).1000萬字符串,其中有些是相同的(重複),須要把重複的所有去掉,保留沒有重複的字符串。請問怎麼設計和實現?
3).尋找熱門查詢:查詢串的重複度比較高,雖然總數是1千萬,但若是除去重複後,不超過3百萬個,每一個不超過255字節。
更多有關Trie樹的介紹,請參見此文:從Trie樹(字典樹)談到後綴樹。
數據庫索引
適用範圍:大數據量的增刪改查
基本原理及要點:利用數據的設計實現方法,對海量數據的增刪改查進行處理。
倒排索引(Inverted index)
適用範圍:搜索引擎,關鍵字查詢
基本原理及要點:爲什麼叫倒排索引?一種索引方法,被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。
以英文爲例,下面是要被索引的文本:
T0 = "it is what it is"
T1 = "what is it"
T2 = "it is a banana"
咱們就能獲得下面的反向文件索引:
"a": {2}
"banana": {2}
"is": {0, 1, 2}
"it": {0, 1, 2}
"what": {0, 1}
檢索的條件"what","is"和"it"將對應集合的交集。
正向索引開發出來用來存儲每一個文檔的單詞的列表。正向索引的查詢每每知足每一個文檔有序頻繁的全文查詢和每一個單詞在校驗文檔中的驗證這樣的查詢。在正向索引中,文檔佔據了中心的位置,每一個文檔指向了一個它所包含的索引項的序列。也就是說文檔指向了它包含的那些單詞,而反向索引則是單詞指向了包含它的文檔,很容易看到這個反向的關係。
擴展:
問題實例:文檔檢索系統,查詢那些文件包含了某單詞,好比常見的學術論文的關鍵字搜索。
關於倒排索引的應用,更多請參見:第二十3、四章:楊氏矩陣查找,倒排索引關鍵詞Hash不重複編碼實踐,及第二十六章:基於給定的文檔生成倒排索引的編碼與實踐。
適用範圍:大數據的排序,去重
基本原理及要點:外排序的歸併方法,置換選擇敗者樹原理,最優歸併樹
擴展:
問題實例:
1).有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16個字節,內存限制大小是1M。返回頻數最高的100個詞。
這個數據具備很明顯的特色,詞的大小爲16個字節,可是內存只有1m作hash有些不夠,因此能夠用來排序。內存能夠當輸入緩衝區使用。
關於多路歸併算法及外排序的具體應用場景,請參見此文:第十章、如何給10^7個數據量的磁盤文件排序。
適用範圍:數據量大,可是數據種類小能夠放入內存
基本原理及要點:將數據交給不一樣的機器去處理,數據劃分,結果歸約。
擴展:
問題實例:
1).The canonical example application of MapReduce is a process to count the appearances of each different word in a set of documents:
2).海量數據分佈在100臺電腦中,想個辦法高效統計出這批數據的TOP10。
3).一共有N個機器,每一個機器上有N個數。每一個機器最多存O(N)個數並對它們操做。如何找到N^2個數的中數(median)?
更多具體闡述請參見:從Hadhoop框架與MapReduce模式中談海量數據處理,及MapReduce技術的初步瞭解與學習。