來吧騷年,看看海量數據處理方面的面試題吧。html
原文:(Link, 其實引自這裏 Link, 而這個又是 Link 的總結)mysql
另外還有一個系列,挺好的:http://blog.csdn.net/v_july_v/article/category/1106578面試
另:算法
Given 1 billion number, get the largest 1 million. Large dataset means you cannot store all of them and sort. sql
注:由於1 million太大了。我以爲用Heap不行。以爲能夠先分治,按照高位劃分紅各塊,而後看各塊的分佈比例。數據庫
所謂海量數據處理,無非就是基於海量數據上的存儲、處理、操做。何謂海量,就是數據量太大,因此致使要麼是沒法在較短期內迅速解決,要麼是數據太大,致使沒法一次性裝入內存。windows
那解決辦法呢?數組
針對時間,咱們能夠採用巧妙的算法搭配合適的數據結構,如Bloom filter/Hash/bit-map/堆/數據庫或倒排索引/trie樹,數據結構
針對空間,無非就一個辦法:大而化小,分而治之(hash映射),你不是說規模太大嘛,那簡單啊,就把規模大化爲規模小的,各個擊破不就完了嘛。架構
關於BloomFilter,能夠看 http://www.cnblogs.com/charlesblc/p/6138417.html
至於所謂的單機及集羣問題,通俗點來說,單機就是處理裝載數據的機器有限(只要考慮cpu,內存,硬盤的數據交互),
而集羣,機器有多輛,適合分佈式處理,並行計算(更多考慮節點和節點間的數據交互)。
經過本blog內的有關海量數據處理的文章:Big Data Processing,咱們已經大體知道,處理海量數據問題,無非就是:
STL容器分兩種,
所謂關聯式容器,相似關聯式數據庫,每筆數據或每一個元素都有一個鍵值(key)和一個實值(value),即所謂的Key-Value(鍵-值對)。當元素被插入到關聯式容器中時,容器內部結構(RB-tree/hashtable)便依照其鍵值大小,以某種特定規則將這個元素放置於適當位置。
至於multiset/multimap,他們的特性及用法和set/map徹底相同,惟一的差異就在於它們容許鍵值重複,即全部的插入操做基於RB-tree的insert_equal()而非insert_unique()。
此外,
一、海量日誌數據,提取出某日訪問百度次數最多的那個IP。
無非就是分而治之/hash映射 + hash統計 + 堆/快速/歸併排序,說白了,就是先映射,然後統計,最後排序:
二、尋找熱門查詢,300萬個查詢字符串中統計最熱門的10個查詢
針對此類典型的TOP K問題,採起的對策每每是:hashmap + 堆。
三、有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16字節,內存限制大小是1M。返回頻數最高的100個詞。
由上面那兩個例題,分而治之 + hash統計 + 堆/快速排序這個套路,咱們已經開始有了屢試不爽的感受。下面,再拿幾道再多多驗證下。請看此第3題:又是文件很大,又是內存受限,咋辦?還能怎麼辦呢?無非仍是:
分而治之/hash映射:順序讀文件中,對於每一個詞x,取hash(x)%5000,而後按照該值存到5000個小文件(記爲x0,x1,...x4999)中。這樣每一個文件大概是200k左右。若是其中的有的文件超過了1M大小,還能夠按照相似的方法繼續往下分,直到分解獲得的小文件的大小都不超過1M。
hash_map統計:對每一個小文件,採用trie樹/hash_map等統計每一個文件中出現的詞以及相應的頻率。
堆/歸併排序:取出出現頻率最大的100個詞(能夠用含100個結點的最小堆)後,再把100個詞及相應的頻率存入文件,這樣又獲得了5000個文件。最後就是把這5000個文件進行歸併(相似於歸併排序)的過程了。
四、海量數據分佈在100臺電腦中,想個辦法高效統計出這批數據的TOP10。
若是不一樣機器的數字不重複,簡單。
若是重複:
五、有10個文件,每一個文件1G,每一個文件的每一行存放的都是用戶的query,每一個文件的query均可能重複。要求你按照query的頻度排序。
方案1:直接上:按照hash直接分文件,而後堆/快排/歸併排序。
方案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映射 + hash統計 + 堆/快速/歸併排序,再看最後4道題,以下:
七、怎麼在海量數據中找出重複次數最多的一個?
方案:先作hash,而後求模映射爲小文件,求出每一個小文件中重複次數最多的一個,並記錄重複次數。而後找出上一步求出的數據中重複次數最多的一個就是所求(具體參考前面的題)。
八、上千萬或上億數據(有重複),統計其中出現次數最多的前N個數據。
方案:上千萬或上億的數據,如今的機器的內存應該能存下。因此考慮採用hash_map/搜索二叉樹/紅黑樹等來進行統計次數。而後利用堆取出前N個出現次數最多的數據。
九、一個文本文件,大約有一萬行,每行一個詞,要求統計出其中最頻繁出現的前10個詞,請給出思想,給出時間複雜度分析。
方案1:若是文件比較大,沒法一次性讀入內存,能夠採用hash取模的方法,將大文件分解爲多個小文件,對於單個小文件利用hash_map統計出每一個小文件中10個最常出現的詞,而後再進行歸併處理,找出最終的10個最常出現的詞。
方案2:經過hash取模將大文件分解爲多個小文件後,除了能夠用hash_map統計出每一個小文件中10個最常出現的詞,也能夠用trie樹統計每一個詞出現的次數,時間複雜度是O(n*le)(le表示單詞的平準長度),最終一樣找出出現最頻繁的前10個詞(可用堆來實現),時間複雜度是O(n*lg10)。
10. 1000萬字符串,其中有些是重複的,須要把重複的所有去掉,保留沒有重複的字符串。請怎麼設計和實現?
因此,小數據量時用map,構造快,大數據量時用hash_map。
rbtree PK hashtable
紅黑樹和hash table的性能測試中發現:當數據量基本上int型key時,hash table是rbtree的3-4倍,但hash table通常會浪費大概一半內存。
關於B樹系列,請參考此篇文章:從B樹、B+樹、B*樹談到R 樹。
多層劃分----其實本質上仍是分而治之的思想,重在「分」的技巧上!
適用範圍:第k大,中位數,不重複或重複的數字
基本原理及要點:由於元素範圍很大,不能利用直接尋址表,因此經過屢次劃分,逐步肯定範圍,而後最後在一個能夠接受的範圍內進行。
1三、2.5億個整數中找出不重複的整數的個數,內存空間不足以容納這2.5億個整數。
有點像鴿巢原理,整數個數爲2^32,也就是,咱們能夠將這2^32個數,劃分爲2^8個區域(好比用單個文件表明一個區域),而後將數據分離到不一樣的區域,而後不一樣的區域在利用bitmap就能夠直接解決了。也就是說只要有足夠的磁盤空間,就能夠很方便的解決。
1四、5億個int找它們的中位數。
思路一
思路一:這個例子比上面那個更明顯。首先咱們將int劃分爲2^16個區域,而後讀取數據統計落到各個區域裏的數的個數,以後咱們根據統計結果就能夠判斷中位數落到那個區域,同時知道這個區域中的第幾大數恰好是中位數。而後第二次掃描咱們只統計落在這個區域中的那些數就能夠了。
實際上,若是不是int是int64,咱們能夠通過3次這樣的劃分便可下降到能夠接受的程度。便可以先將int64分紅2^24個區域,而後肯定區域的第幾大數,在將該區域分紅2^20個子區域,而後肯定是子區域的第幾大數,而後子區域裏的數的個數只有2^20,就能夠直接利用direct addr table進行統計了。
思路二
思路二:一樣須要作兩遍統計,若是數據存在硬盤上,就須要讀取2次。 方法同基數排序有些像,開一個大小爲65536的Int數組,第一遍讀取,統計Int32的高16位的狀況,也就是0-65535,都算做0,65536 - 131071都算做1。就至關於用該數除以65536。Int32 除以 65536的結果不會超過65536種狀況,所以開一個長度爲65536的數組計數就能夠。每讀取一個數,數組中對應的計數+1,考慮有負數的狀況,須要將結果加32768後,記錄在相應的數組內。 第一遍統計以後,遍歷數組,逐個累加統計,看中位數處於哪一個區間,好比處於區間k,那麼0- k-1的區間裏數字的數量sum應該<n/2(2.5億)。而k+1 - 65535的計數和也<n/2,第二遍統計同上面的方法相似,但此次只統計處於區間k的狀況,也就是說(x / 65536) + 32768 = k。統計只統計低16位的狀況。而且利用剛纔統計的sum,好比sum = 2.49億,那麼如今就是要在低16位裏面找100萬個數(2.5億-2.49億)。此次計數以後,再統計一下,看中位數所處的區間,最後將高位和低位組合一下就是結果了。
關於什麼是Bloom filter,請參看blog內此文:
當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個。
但 Bloom Filter的缺點,是有錯誤率。
下面關於Bitmap的應用,能夠看下上文中的第13題,以及另一道新題:
「1三、在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題相似的方法,進行劃分小文件的方法。而後在小文件中找出不重複的整數,並排序。而後再進行歸併,注意去除重複的元素。」
1五、給40億個不重複的unsigned int的整數,沒排過序的,而後再給一個數,如何快速判斷這個數是否在那40億個數當中?
方案1:frome oo,用位圖/Bitmap的方法,申請512M的內存,一個bit位表明一個unsigned int值。讀入40億個數,設置相應的bit位,讀入要查詢的數,查看相應bit位是否爲1,爲1表示存在,爲0表示不存在。
可是,我總以爲bloom filter有錯誤率,不建議用。
Trie樹
適用範圍:數據量大,重複多,可是數據種類小能夠放入內存
基本原理及要點:實現方式,節點孩子的表示方式
擴展:壓縮實現。
問題實例:
更多有關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"將對應集合的交集。 正向索引開發出來用來存儲每一個文檔的單詞的列表。正向索引的查詢每每知足每一個文檔有序頻繁的全文查詢和每一個單詞在校驗文檔中的驗證這樣的查詢。在正向索引中,文檔佔據了中心的位置,每一個文檔指向了一個它所包含的索引項的序列。也就是說文檔指向了它包含的那些單詞,而反向索引則是單詞指向了包含它的文檔,很容易看到這個反向的關係。
問題實例:文檔檢索系統,查詢那些文件包含了某單詞,好比常見的學術論文的關鍵字搜索。
關於倒排索引的應用,更多請參見:
適用範圍:大數據的排序,去重
基本原理及要點:外排序的歸併方法,置換選擇敗者樹原理,最優歸併樹
問題實例:
1).有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16個字節,內存限制大小是1M。返回頻數最高的100個詞。
這個數據具備很明顯的特色,詞的大小爲16個字節,可是內存只有1M作hash明顯不夠,因此能夠用來排序。內存能夠當輸入緩衝區使用。
關於多路歸併算法及外排序的具體應用場景,請參見blog內此文:
說白了,Mapreduce的原理就是一個歸併排序。
問題實例:
更多具體闡述請參見blog內:
題目:
很是大的文件,裝不進內存。每行一個int類型數據,如今要你隨機取100個數。
背景知識:
物理內存分頁,一個物理頁的大小爲4K字節,第0個物理頁從物理地址 0x00000000 處開始。因爲頁的大小爲4KB,就是0x1000字節,因此第1頁從物理地址 0x00001000 處開始。
操做系統中的方法,先生成4G的地址表,在把這個表劃分爲小的4M的小文件作個索引,二級索引。30位前十位表示第幾個4M文件,後20位表示在這個4M文件的第幾個,等等,基於key value來設計存儲,用key來建索引。
更多海里數據處理面試題,請參見此文第一部分:http://blog.csdn.net/v_july_v/article/details/6685962。