教你如何迅速秒殺99%的海量數據處理面試題

前言
一般而言,標題有“秒殺”,“史上最全/最強”等詞彙的往往都脫不了譁衆取寵之嫌,但進一步來講,如果讀者讀罷此文,卻無任何收穫,那麼,我也甘願揹負這樣的罪名,:-),同時,此文可以看做是對這篇文章:十道海量數據處理面試題與十個方法大總結的一般抽象性總結。
畢竟受文章和理論之限,本文摒棄絕大部分的細節,只談方法/模式論,且注重用最通俗最直白的語言闡述相關問題。最後,有一點必須強調的是,全文行文是基於面試題的分析基礎之上的,具體實踐過程中,還是得具體情況具體分析,且場景也遠比本文所述的任何一種場景複雜得多。
何謂海量數據處理?
所謂海量數據處理,其實很簡單,海量,海量,何謂海量,就是數據量太大,所以導致要麼是無法在較短時間內迅速解決,要麼是數據太大,導致無法一次性裝入內存。
那解決辦法呢?針對時間,我們可以採用巧妙的算法搭配合適的數據結構,如Bloom filter/Hash/bit-map/堆/數據庫或倒排索引/tire/,針對空間,無非就一個辦法:大而化小:分而治之/hash映射,你不是說規模太大嘛,那簡單啊,就把規模大化爲規模小的,各個擊破不就完了嘛。
至於所謂的單機及集羣問題,通俗點來講,單機就是處理裝載數據的機器有限(只要考慮cpu,內存,硬盤的數據交互),而集羣,機器有多輛,適合分佈式處理,並行計算(更多考慮節點和節點間的數據交互)。
再者,通過本blog內的有關海量數據處理的兩篇文章,我們已經大致知道,處理海量數據問題,無非就是:
1分而治之/hash映射 + hash統計 + 堆/快速/歸併排序;
2Bloom filter/Bitmap;
3Trie樹/數據庫/倒排索引;
4外排序;
5分佈式處理之hadoop/mapreduce。
本文接下來的部分,便針對這5種方法模式結合對應的海量數據處理面試題分別具體闡述。
密匙一、分而治之/hash映射 + hash統計 + 堆/快速/歸併排序
1、海量日誌數據,提取出某日訪問百度次數最多的那個IP。既然是海量數據處理,那麼可想而知,給我們的數據那就一定是海量的。針對這個數據的海量,我們如何着手呢?對的,無非就是分而治之/hash映射 + hash統計 + 堆/快速/歸併排序,說白了,就是先映射,而後統計,最後排序:

6分而治之/hash映射:針對數據太大,內存受限,智能是:把大文件化成(取模映射)小文件,即16字方針:大而化小,各個擊破,縮小規模,逐個解決
7hash統計:當大文件轉化了小文件,那麼我們便可以採用常規的hashmap(ip,value)來進行頻率統計。
8堆/快速排序:統計完了之後,便進行排序(可採取堆排序),得到次數最多的IP。
具體而論,則是: “首先是這一天,並且是訪問百度的日誌中的IP取出來,逐個寫入到一個大文件中。注意到IP是32位的,最多有個2^32個IP。同樣可以採用映射的方法,比如模1000,把整個大文件映射爲1000個小文件,再找出每個小文中出現頻率最大的IP(可以採用hash_map進行頻率統計,然後再找出頻率最大的幾個)及相應的頻率。然後再在這1000個最大的IP中,找出那個頻率最大的IP,即爲所求。”–十道海量數據處理面試題與十個方法大總結。

但如果數據規模比較小,能一次性裝入內存呢?比如下面的這道題,題目中說,雖然有一千萬個Query,但是由於重複度比較高,因此事實上只有300萬的 Query,每個Query255Byte,因此我們可以考慮把他們都放進內存中去,而現在只是需要一個合適的數據結構,在這裏,Hash Table絕對是我們優先的選擇。OK,請看第2題:
2、搜索引擎會通過日誌文件把用戶每次檢索使用的所有檢索串都記錄下來,每個查詢串的長度爲1-255字節。
假設目前有一千萬個記錄(這些查詢串的重複度比較高,雖然總數是1千萬,但如果除去重複後,不超過3百萬個。一個查詢串的重複度越高,說明查詢它的用戶越多,也就是越熱門。),請你統計最熱門的10個查詢串,要求使用的內存不能超過1G。
前面說了,數據比較小,摒棄分而治之/hash映射的方法,直接上hash統計,然後排序。So,

9hash 統計先對這批海量數據預處理(維護一個Key爲Query字串,Value爲該Query出現次數的HashTable,即 hashmap(Query,Value),每次讀取一個Query,如果該字串不在Table中,那麼加入該字串,並且將Value值設爲1;如果該字串在Table中,那麼將該字串的計數加一即可。最終我們在O(N)的時間複雜度內用Hash表完成了統計;
10堆排序:第二步、藉助堆這個數據結構,找出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題:
3、有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16字節,內存限制大小是1M。返回頻數最高的100個詞。
又是文件很大,又是內存受限,咋辦?還能怎麼辦呢?無非還是

11分而治之/hash映射:順序讀文件中,對於每個詞x,取hash(x)%5000,然後按照該值存到5000個小文件(記爲 x0,x1,…x4999)中。這樣每個文件大概是200k左右。如果其中的有的文件超過了1M大小,還可以按照類似的方法繼續往下分,直到分解得到的小文件的大小都不超過1M。
12hash統計:對每個小文件,採用trie樹/hash_map等統計每個文件中出現的詞以及相應的頻率。
13堆/歸併排序:取出出現頻率最大的100個詞(可以用含100個結點的最小堆),並把100個詞及相應的頻率存入文件,這樣又得到了5000個文件。最後就是把這5000個文件進行歸併(類似與歸併排序)的過程了。
4、有10個文件,每個文件1G,每個文件的每一行存放的都是用戶的query,每個文件的query都可能重複。要求你按照query的頻度排序。
直接上:

14hash映射:順序讀取10個文件,按照hash(query)%10的結果將query寫入到另外10個文件(記爲)中。這樣新生成的文件每個的大小大約也1G(假設hash函數是隨機的)。
15hash統計:找一臺內存在2G左右的機器,依次對用hash_map(query, query_count)來統計每個query出現的次數。注:hash_map(query,query_count)是用來統計每個query的出現次數,不是存儲他們的值,出現一次,則count+1。
16堆/快速/歸併排序:利用快速/堆/歸併排序按照出現次數進行排序。將排序好的query和對應的query_cout輸出到文件中。這樣得到了10個排好序的文件(記爲)。對這10個文件進行歸併排序(內排序與外排序相結合)。
除此之外,此題還有以下兩個方法:
方案2:一般query的總量是有限的,只是重複的次數比較多而已,可能對於所有的query,一次性就可以加入到內存了。這樣,我們就可以採用trie樹/hash_map等直接來統計每個query出現的次數,然後按出現次數做快速/堆/歸併排序就可以了。
方案3:
與方案1類似,但在做完hash,分成多個文件後,可以交給多個文件來處理,採用分佈式的架構來處理(比如MapReduce),最後再進行合併。
5、 給定a、b兩個文件,各存放50億個url,每個url各佔64字節,內存限制是4G,讓你找出a、b文件共同的url?
可以估計每個文件安的大小爲5G×64=320G,遠遠大於內存限制的4G。所以不可能將其完全加載到內存中處理。考慮採取分而治之的方法。

17分而治之/hash映射:遍歷文件a,對每個url求取,然後根據所取得的值將url分別存儲到1000個小文件(記爲)中。這樣每個小文件的大約爲300M。遍歷文件b,採取和a相同的方式將url分別存儲到1000小文件中(記爲)。這樣處理後,所有可能相同的url都在對應的小文件()中,不對應的小文件不可能有相同的url。然後我們只要求出1000對小文件中相同的url即可。
18hash統計:求每對小文件中相同的url時,可以把其中一個小文件的url存儲到hash_set中。然後遍歷另一個小文件的每個url,看其是否在剛纔構建的hash_set中,如果是,那麼就是共同的url,存到文件裏面就可以了。
OK,此第一種方法:分而治之/hash映射 + hash統計 + 堆/快速/歸併排序,再看最後三道題,如下:
8、怎麼在海量數據中找出重複次數最多的一個?
方案1:先做hash,然後求模映射爲小文件,求出每個小文件中重複次數最多的一個,並記錄重複次數。然後找出上一步求出的數據中重複次數最多的一個就是所求(具體參考前面的題)。
9、上千萬或上億數據(有重複),統計其中出現次數最多的錢N個數據。
方案1:上千萬或上億的數據,現在的機器的內存應該能存下。所以考慮採用hash_map/搜索二叉樹/紅黑樹等來進行統計次數。然後就是取出前N個出現次數最多的數據了,可以用第2題提到的堆機制完成。
10、一個文本文件,大約有一萬行,每行一個詞,要求統計出其中最頻繁出現的前10個詞,請給出思想,給出時間複雜度分析。
方案1:這題是考慮時間效率。用trie樹統計每個詞出現的次數,時間複雜度是O(n*le)(le表示單詞的平準長度)。然後是找出出現最頻繁的前10 個詞,可以用堆來實現,前面的題中已經講到了,時間複雜度是O(n*lg10)。所以總的時間複雜度,是O(n*le)與O(n*lg10)中較大的哪一個。

接下來,咱們來看第二種方法,Bitmap。

密匙二:Bloom filter/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的應用,直接上題,如下第6、7道:
6、在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題類似的方法,進行劃分小文件的方法。然後在小文件中找出不重複的整數,並排序。然後再進行歸併,注意去除重複的元素。

7、騰訊面試題:給40億個不重複的unsigned int的整數,沒排過序的,然後再給一個數,如何快速判斷這個數是否在那40億個數當中?
方案1:oo,申請512M的內存,一個bit位代表一個unsigned int值。讀入40億個數,設置相應的bit位,讀入要查詢的數,查看相應bit位是否爲1,爲1表示存在,爲0表示不存在。

密匙三、Trie樹/數據庫/倒排索引
Tire樹
  適用範圍:數據量大,重複多,但是數據種類小可以放入內存
  基本原理及要點:實現方式,節點孩子的表示方式
  擴展:壓縮實現。

  問題實例:
  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”將對應集合的交集。

  正向索引開發出來用來存儲每個文檔的單詞的列表。正向索引的查詢往往滿足每個文檔有序頻繁的全文查詢和每個單詞在校驗文檔中的驗證這樣的查詢。在正向索引中,文檔佔據了中心的位置,每個文檔指向了一個它所包含的索引項的序列。也就是說文檔指向了它包含的那些單詞,而反向索引則是單詞指向了包含它的文檔,很容易看到這個反向的關係。
  擴展:
  問題實例:文檔檢索系統,查詢那些文件包含了某單詞,比如常見的學術論文的關鍵字搜索。

關於倒排索引的應用,更多請參見:第二十三、四章:楊氏矩陣查找,倒排索引關鍵詞Hash不重複編碼實踐,及第二十六章:基於給定的文檔生成倒排索引的編碼與實踐。
密匙四、外排序
  適用範圍:大數據的排序,去重
  基本原理及要點:外排序的歸併方法,置換選擇敗者樹原理,最優歸併樹
  擴展:
  問題實例:
  1).有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16個字節,內存限制大小是1M。返回頻數最高的100個詞。
  這個數據具有很明顯的特點,詞的大小爲16個字節,但是內存只有1m做hash有些不夠,所以可以用外排序來排序。內存可以當輸入緩衝區使用。
關於多路歸併算法及外排序的具體應用場景,請參見此文:第十章、如何給10^7個數據量的磁盤文件排序。
密匙五、分佈式處理 Mapreduce
適用範圍:數據量大,但是數據種類小可以放入內存
  基本原理及要點:將數據交給不同的機器去處理,數據劃分,結果歸約。
  擴展:
  問題實例:
  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技術的初步瞭解與學習。
參考文獻
1十道海量數據處理面試題與十個方法大總結;
2海量數據處理面試題集錦與Bit-map詳解;
3十一、從頭到尾徹底解析Hash表算法;
4海量數據處理之Bloom Filter詳解;
5從Trie樹(字典樹)談到後綴樹;
6第三章、尋找最小的k個數;
7第十章、如何給10^7個數據量的磁盤文件排序;
8第二十三、四章:楊氏矩陣查找,倒排索引關鍵詞Hash不重複編碼實踐;
9第二十六章:基於給定的文檔生成倒排索引的編碼與實踐;
10從Hadhoop框架與MapReduce模式中談海量數據處理。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章