海量數據處理方法歸類

海量數據，找出最熱門（頻率最高）的某一數據，或前100的數據。通常狀況下數據大小几百個G，而內存限制就1個G，完成計算。

應用場景：
　　（1）海量日誌數據，提取出某日訪問百度次數最多的那個IP；
　　（2）搜索引擎會經過日誌文件把用戶每次檢索使用的全部檢索串都記錄下來， 假設目前有一千萬個記錄（這些查詢串的重複度比較高，雖然總數是1千萬，但若是除去重複後，不超過3百萬個。一個查詢串的重複度越高，說明查詢它的用戶越多，也就是越熱門。），請你統計最熱門的10個查詢串，要求使用的內存不能超過1G。
　　解決思路：主要是內存限制。若是內存夠，那好，咱們用用排序就OK了；那內存不夠，咱們就分批次來。分批次來，那麼首先思考要怎麼分批？顯然要知足的條件就是儘可能把相同的日誌、IP分到同一個文件中去，這樣避免多個文件中還互相包含同一條日誌。瓜熟蒂落，若分爲1000個小文件，根據hash(IP) % 1000將日誌對號入座，而後分別對每一個小文件用hashMap進行頻率統計，最後再將1000個小文件中最**（前**）的日誌提取出來，利用常規的排序便可。

有10個文件，每一個文件1G，每一個文件的每一行存放的都是用戶的query，每一個文件的query均可能重複。要求你按照query的頻度排序

解決思路：典型的Top K算法。模板：先用HashMap統計頻率（或去重），維護一個K大小的堆，統計Top K就好了。

給定a、b兩個文件，各存放50億個url，每一個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url？

解決思路：能夠估計每一個文件安的大小爲5G×64=320G，遠遠大於內存限制的4G。因此不可能將其徹底加載到內存中處理。考慮採起分而治之的方法。
遍歷文件a，對每一個url求取hash(url)%1000，而後根據所取得的值將url分別存儲到1000個小文件（記爲a0,a1,...,a999）中。這樣每一個小文件的大約爲300M。
遍歷文件b，採起和a相同的方式將url分別存儲到1000小文件（記爲b0,b1,...,b999）。這樣處理後，全部可能相同的url都在對應的小文件　　　　（a0vsb0,a1vsb1,...,a999vsb999）中，不對應的小文件不可能有相同的url。而後咱們只要求出1000對小文件中相同的url便可。
求每對小文件中相同的url時，能夠把其中一個小文件的url存儲到hash_set中。而後遍歷另外一個小文件的每一個url，看其是否在剛纔構建的hash_set中，若是是，那麼就是共同的url，存到文件裏面就能夠了。

在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億個數當中？

位圖法比較適合於這種狀況，它的作法是按照集合中最大元素max建立一個長度爲max+1的新數組，而後再次掃描原數組，遇到幾就給新數組的第幾位置上1，如遇到5就給新數組的第六個元素置1，這樣下次再遇到5想置位時發現新數組的第六個元素已是1了，這說明此次的數據確定和之前的數據存在着重複。此法之內存爲代價。
方法總結：內存不夠，分治之；如何分治，取hash；想取TOP K，就用堆！