原文:http://blog.csdn.net/v_july_v/article/details/7382693
前言
何謂海量數據處理?
- 分而治之/hash映射 + hash統計 + 堆/快速/歸併排序;
- 雙層桶劃分
- Bloom filter/Bitmap;
- Trie樹/數據庫/倒排索引;
- 外排序;
- 分佈式處理之Hadoop/Mapreduce。
第一部分、從set/map談到hashtable/hash_map/hash_set
- 序列式容器(vector/list/deque/stack/queue/heap),
- 關聯式容器。關聯式容器又分爲set(集合)和map(映射表)兩大類,以及這兩大類的衍生體multiset(多鍵集合)和multimap(多鍵映射表),這些容器均以RB-tree完成。此外,還有第3類關聯式容器,如hashtable(散列表),以及以hashtable爲底層機制完成的hash_set(散列集合)/hash_map(散列映射表)/hash_multiset(散列多鍵集合)/hash_multimap(散列多鍵映射表)。也就是說,set/map/multiset/multimap都內含一個RB-tree,而hash_set/hash_map/hash_multiset/hash_multimap都內含一個hashtable。
{ "name" : "July",
set/map/multiset/multimap
hash_set/hash_map/hash_multiset/hash_multimap
- 關於什麼hash,請看blog內此篇文章:http://blog.csdn.net/v_JULY_v/article/details/6256463;
- 關於紅黑樹,請參看blog內系列文章:http://blog.csdn.net/v_july_v/article/category/774945,
- 關於hash_map的具體應用:http://blog.csdn.net/sdhongjun/article/details/4517325,關於hash_set:http://blog.csdn.net/morewindows/article/details/7330323。
第二部分、處理海量數據問題之六把密匙
密匙一、分而治之/Hash映射 + Hash統計 + 堆/快速/歸併排序
- 分而治之/hash映射:針對數據太大,內存受限,只能是:把大文件化成(取模映射)小文件,即16字方針:大而化小,各個擊破,縮小規模,逐個解決
- hash統計:當大文件轉化了小文件,那麼我們便可以採用常規的hash_map(ip,value)來進行頻率統計。所謂邊映射邊統計,在映射成小文件的同時完成hash_map頻率的統計。
- 堆/快速排序:統計完了之後,便進行排序(可採取堆排序),得到次數最多的IP。
2、尋找熱門查詢:搜索引擎會通過日誌文件把用戶每次檢索使用的所有檢索串都記錄下來,每個查詢串的長度爲1-255字節。
- hash統計:先對這批海量數據預處理(維護一個Key爲Query字串,Value爲該Query出現次數的HashTable,即hash_map(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萬)。
3、有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16字節,內存限制大小是1M。返回頻數最高的100個詞。
- 分而治之/hash映射:順序讀文件中,對於每個詞x,取hash(x)P00,然後按照該值存到5000個小文件(記爲x0,x1,...x4999)中。這樣每個文件大概是200k左右。如果其中的有的文件超過了1M大小,還可以按照類似的方法繼續往下分,直到分解得到的小文件的大小都不超過1M。
- hash統計:對每個小文件,採用trie樹/hash_map等統計每個文件中出現的詞以及相應的頻率。
- 堆/歸併排序:取出出現頻率最大的100個詞(可以用含100個結點的最小堆),並把100個詞及相應的頻率存入文件,這樣又得到了5000個文件。最後就是把這5000個文件進行歸併(類似於歸併排序)的過程了。
- 堆排序:在每臺電腦上求出TOP10,可以採用包含10個元素的堆完成(TOP10小,用最大堆,TOP10大,用最小堆)。比如求TOP10大,我們首先取前10個元素調整成最小堆,如果發現,然後掃描後面的數據,並與堆頂元素比較,如果比堆頂元素大,那麼用該元素替換堆頂,然後再調整爲最小堆。最後堆中的元素就是TOP10大。
- 求出每臺電腦上的TOP10後,然後把這100臺電腦上的TOP10組合起來,共1000個數據,再利用上面類似的方法求出TOP10就可以了。
上述第4題的此解法,經讀者反應有問題,如舉個例子如求2個文件中的top2,照上述算法,如果第一個文件裏有: a49次 b50次 c2次 d1次 第二個文件裏有: a9次 b1次 c11次 d10次 雖然第一個文件裏出來top2是b(50次),a(49次),第二個文件裏出來top2是c(11次),d(10次),然後2個top2:b(50次)a(49次)與c(11次)d(10次)歸併,則算出所有的文件的top2是b(50 次),a(49 次),但實際上是a(58 次),b(51 次)。是否真是如此呢?若真如此,那作何解決呢? 正如老夢所述: 首先,先把所有的數據遍歷一遍做一次hash(保證相同的數據條目劃分到同一臺電腦上進行運算),然後根據hash結果重新分佈到100臺電腦中,接下來的算法按照之前的即可。 最後由於a可能出現在不同的電腦,各有一定的次數,再對每個相同條目進行求和(由於上一步驟中hash之後,也方便每臺電腦只需要對自己分到的條目內進行求和,不涉及到別的電腦,規模縮小)。
- hash映射:順序讀取10個文件,按照hash(query)的結果將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個文件進行歸併排序(內排序與外排序相結合)。
6、 給定a、b兩個文件,各存放50億個url,每個url各佔64字節,內存限制是4G,讓你找出a、b文件共同的url?
- 分而治之/hash映射:遍歷文件a,對每個url求取,然後根據所取得的值將url分別存儲到1000個小文件(記爲)中。這樣每個小文件的大約爲300M。遍歷文件b,採取和a相同的方式將url分別存儲到1000小文件中(記爲)。這樣處理後,所有可能相同的url都在對應的小文件()中,不對應的小文件不可能有相同的url。然後我們只要求出1000對小文件中相同的url即可。
- hash統計:求每對小文件中相同的url時,可以把其中一個小文件的url存儲到hash_set中。然後遍歷另一個小文件的每個url,看其是否在剛纔構建的hash_set中,如果是,那麼就是共同的url,存到文件裏面就可以了。
7、怎麼在海量數據中找出重複次數最多的一個?
8、上千萬或上億數據(有重複),統計其中出現次數最多的錢N個數據。
9、一個文本文件,大約有一萬行,每行一個詞,要求統計出其中最頻繁出現的前10個詞,請給出思想,給出時間複雜度分析。
- 方案1:這題用trie樹比較合適,hash_map也行。
- 方案2:from xjbzju:,1000w的數據規模插入操作完全不現實,以前試過在stl下100w元素插入set中已經慢得不能忍受,覺得基於hash的實現不會比紅黑樹好太多,使用vector+sort+unique都要可行許多,建議還是先hash成小文件分開處理再綜合。
-
1、hash_set在千萬級數據下,insert操作優於set? 這位blog:http://t.cn/zOibP7t
給的實踐數據可靠不? - 2、那map和hash_map的性能比較呢? 誰做過相關實驗?
- 3、那查詢操作呢,如下段文字所述?
rbtree PK hashtable
密匙二、雙層桶劃分
雙層桶劃分----其實本質上還是分而治之的思想,重在“分”的技巧上!
適用範圍:第k大,中位數,不重複或重複的數字
基本原理及要點:因爲元素範圍很大,不能利用直接尋址表,所以通過多次劃分,逐步確定範圍,然後最後在一個可以接受的範圍內進行。可以通過多次縮小,雙層只是一個例子。
擴展:
問題實例:
11、2.5億個整數中找出不重複的整數的個數,內存空間不足以容納這2.5億個整數。
有點像鴿巢原理,整數個數爲2^32,也就是,我們可以將這2^32個數,劃分爲2^8個區域(比如用單個文件代表一個區域),然後將數據分離到不同的區域,然後不同的區域在利用bitmap就可以直接解決了。也就是說只要有足夠的磁盤空間,就可以很方便的解決。
12、5億個int找它們的中位數。
這個例子比上面那個更明顯。首先我們將int劃分爲2^16個區域,然後讀取數據統計落到各個區域裏的數的個數,之後我們根據統計結果就可以判斷中位數落到那個區域,同時知道這個區域中的第幾大數剛好是中位數。然後第二次掃描我們只統計落在這個區域中的那些數就可以了。
實際上,如果不是int是int64,我們可以經過3次這樣的劃分即可降低到可以接受的程度。即可以先將int64分成2^24個區域,然後確定區域的第幾大數,在將該區域分成2^20個子區域,然後確定是子區域的第幾大數,然後子區域裏的數的個數只有2^20,就可以直接利用direct addr table進行統計了。
密匙三:Bloom filter/Bitmap
Bloom filter
關於什麼是Bloom filter,請參看blog內此文:
基本原理及要點:
對於原理來說很簡單,位數組+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中的最小值來近似表示元素的出現頻率。
13、給你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,則大大簡單了。
Bitmap
- 關於什麼是Bitmap,請看blog內此文:http://blog.csdn.net/v_july_v/article/details/6685962。
密匙四、Trie樹/數據庫/倒排索引
Trie樹
適用範圍:數據量大,重複多,但是數據種類小可以放入內存
基本原理及要點:實現方式,節點孩子的表示方式
擴展:壓縮實現。
問題實例:
-
上面的第2題:尋找熱門查詢:查詢串的重複度比較高,雖然總數是1千萬,但如果除去重複後,不超過3百萬個,每個不超過255字節。
- 上面的第5題:有10個文件,每個文件1G,每個文件的每一行都存放的是用戶的query,每個文件的query都可能重複。要你按照query的頻度排序。
- 1000萬字符串,其中有些是相同的(重複),需要把重複的全部去掉,保留沒有重複的字符串。請問怎麼設計和實現?
- 上面的第8題:一個文本文件,大約有一萬行,每行一個詞,要求統計出其中最頻繁出現的前10個詞。其解決方法是:用trie樹統計每個詞出現的次數,時間複雜度是O(n*le)(le表示單詞的平準長度),然後是找出出現最頻繁的前10個詞。
數據庫索引
適用範圍:大數據量的增刪改查
基本原理及要點:利用數據的設計實現方法,對海量數據的增刪改查進行處理。
- 關於數據庫索引及其優化,更多可參見此文:http://www.cnblogs.com/pkuoliver/archive/2011/08/17/mass-data-topic-7-index-and-optimize.html;
- 關於MySQL索引背後的數據結構及算法原理,這裏還有一篇很好的文章:http://www.codinglabs.org/html/theory-of-mysql-index.html;
- 關於B 樹、B+ 樹、B* 樹及R 樹,本blog內有篇絕佳文章:http://blog.csdn.net/v_JULY_v/article/details/6530142。
倒排索引(Inverted index)
適用範圍:搜索引擎,關鍵字查詢
基本原理及要點:爲何叫倒排索引?一種索引方法,被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。
以英文爲例,下面是要被索引的文本:
檢索的條件"what","is"和"it"將對應集合的交集。
正向索引開發出來用來存儲每個文檔的單詞的列表。正向索引的查詢往往滿足每個文檔有序頻繁的全文查詢和每個單詞在校驗文檔中的驗證這樣的查詢。在正向索引中,文檔佔據了中心的位置,每個文檔指向了一個它所包含的索引項的序列。也就是說文檔指向了它包含的那些單詞,而反向索引則是單詞指向了包含它的文檔,很容易看到這個反向的關係。
擴展:
問題實例:文檔檢索系統,查詢那些文件包含了某單詞,比如常見的學術論文的關鍵字搜索。
密匙五、外排序
適用範圍:大數據的排序,去重
基本原理及要點:外排序的歸併方法,置換選擇敗者樹原理,最優歸併樹
擴展:
問題實例:
1).有一個1G大小的一個文件,裏面每一行是一個詞,詞的大小不超過16個字節,內存限制大小是1M。返回頻數最高的100個詞。
這個數據具有很明顯的特點,詞的大小爲16個字節,但是內存只有1M做hash明顯不夠,所以可以用來排序。內存可以當輸入緩衝區使用。
密匙六、分佈式處理之Mapreduce
基本原理及要點:將數據交給不同的機器去處理,數據劃分,結果歸約。
擴展:
問題實例:
- The canonical example application of MapReduce is a process to count the appearances of each different word in a set of documents:
- 海量數據分佈在100臺電腦中,想個辦法高效統計出這批數據的TOP10。
- 一共有N個機器,每個機器上有N個數。每個機器最多存O(N)個數並對它們操作。如何找到N^2個數的中數(median)?
其它模式/方法論,結合操作系統知識
-
物理地址 (physical address): 放在尋址總線上的地址。放在尋址總線上,如果是讀,電路根據這個地址每位的值就將相應地址的物理內存中的數據放到數據總線中傳輸。如果是寫,電路根據這個 地址每位的值就將相應地址的物理內存中放入數據總線上的內容。物理內存是以字節(8位)爲單位編址的。
-
虛擬地址 (virtual address): 4G虛擬地址空間中的地址,程序中使用的都是虛擬地址。
使用了分頁機制之後,4G的地址空間被分成了固定大小的頁,每一頁或者被映射到物理內存,或者被映射到硬盤上的交換文件中,或者沒有映射任何東西。對於一 般程序來說,4G的地址空間,只有一小部分映射了物理內存,大片大片的部分是沒有映射任何東西。物理內存也被分頁,來映射地址空間。對於32bit的 Win2k,頁的大小是4K字節。CPU用來把虛擬地址轉換成物理地址的信息存放在叫做頁目錄和頁表的結構裏。
參考文獻
-
十道海量數據處理面試題與十個方法大總結;
-
海量數據處理面試題集錦與Bit-map詳解;
-
十一、從頭到尾徹底解析Hash表算法;
- 海量數據處理之Bloom Filter詳解;
- 從Trie樹(字典樹)談到後綴樹;
-
第三章續、Top
K算法問題的實現;
-
第十章、如何給10^7個數據量的磁盤文件排序;
-
從B樹、B+樹、B*樹談到R
樹;
- 第二十三、四章:楊氏矩陣查找,倒排索引關鍵詞Hash不重複編碼實踐;
- 第二十六章:基於給定的文檔生成倒排索引的編碼與實踐;
- 從Hadhoop框架與MapReduce模式中談海量數據處理;
-
第十六~第二十章:全排列,跳臺階,奇偶排序,第一個只出現一次等問題;
- http://blog.csdn.net/v_JULY_v/article/category/774945;
- STL源碼剖析第五章,侯捷著。