1.給定a、b兩個文件，各存放50億個url，每個url各占64字節，內存限制是4G，讓你找出a、b文件共同的url?
假如每個url大小為10bytes，那么可以估計每個文件的大小為50G×64=320G，遠遠大於內存限制的4G，所以不可能將其完全加載到內存中處理，可以采用分治的思想來解決。
Step1：遍歷文件a，對每個url求取hash(url)%1000，然后根據所取得的值將url分別存儲到1000個小文件(記為a0,a1,...,a999，每個小文件約300M);
Step2:遍歷文件b，采取和a相同的方式將url分別存儲到1000個小文件(記為b0,b1,...,b999);
巧妙之處：這樣處理后，所有可能相同的url都被保存在對應的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不對應的小文件不可能有相同的url。然后我們只要求出這個1000對小文件中相同的url即可。
Step3：求每對小文件ai和bi中相同的url時，可以把ai的url存儲到hash_set/hash_map中。然后遍歷bi的每個url，看其是否在剛才構建的hash_set中，如果是，那么就是共同的url，存到文件里面就可以了。
草圖如下(左邊分解A，右邊分解B，中間求解相同url)：
2.有一個1G大小的一個文件，里面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M，要求返回頻數最高的100個詞。
Step1：順序讀文件中，對於每個詞x，取hash(x)%5000，然后按照該值存到5000個小文件(記為f0,f1,...,f4999)中，這樣每個文件大概是200k左右，如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續往下分，直到分解得到的小文件的大小都不超過1M;
Step2：對每個小文件，統計每個文件中出現的詞以及相應的頻率(可以采用trie樹/hash_map等)，並取出出現頻率最大的100個詞(可以用含100個結點的最小堆)，並把100詞及相應的頻率存入文件，這樣又得到了5000個文件;
Step3：把這5000個文件進行歸並(類似與歸並排序);
草圖如下(分割大問題，求解小問題，歸並)：
3.現有海量日志數據保存在一個超級大的文件中，該文件無法直接讀入內存，要求從中提取某天出訪問百度次數最多的那個IP。
Step1：從這一天的日志數據中把訪問百度的IP取出來，逐個寫入到一個大文件中;
Step2：注意到IP是32位的，最多有2^32個IP。同樣可以采用映射的方法，比如模1000，把整個大文件映射為1000個小文件;
Step3：找出每個小文中出現頻率最大的IP(可以采用hash_map進行頻率統計，然后再找出頻率最大的幾個)及相應的頻率;
Step4：在這1000個最大的IP中，找出那個頻率最大的IP，即為所求。
草圖如下：
4.LVS和HAProxy相比，它的缺點是什么?
之前，的確是用LVS進行過MySQL集群的負載均衡，對HAProxy也有過了解，但是將這兩者放在眼前進行比較，還真沒試着了解過。面試中出現了這么一題，面試官給予的答案是LVS的配置相當繁瑣，后來查找了相關資料，對這兩種負載均衡方案有了更進一步的了解。LVS的負載均衡性能之強悍已經達到硬件負載均衡的F5的百分之60了，而HAproxy的負載均衡和Nginx負載均衡，均為硬件負載均衡的百分之十左右。由此可見，配置復雜，相應的效果也是顯而易見的。在查找資料的過程中，試着將LVS的10種調度算法了解了一下，看似數量挺多的10種算法其實在不同的算法之間，有些只是有着一些細微的差別。在這10種調度算法中，靜態調度算法有四種，動態調度算法有6種。
靜態調度算法：
①RR輪詢調度算法
這種調度算法不考慮服務器的狀態，所以是無狀態的，同時也不考慮每個服務器的性能，比如我有1-N台服務器，來N個請求了，第一個請求給第一台，第二個請求給第二台，，，第N個請求給第N台服務器，就醬紫。
②加權輪詢
這種調度算法是考慮到服務器的性能的，你可以根據不同服務器的性能，加上權重進行分配相應的請求。
③基於目的地址的hash散列
這種調度算法和基於源地址的hash散列異曲同工，都是為了維持一個session，基於目的地址的hash散列，將記住同一請求的目的地址，將這類請求發往同一台目的服務器。簡而言之，就是發往這個目的地址的請求都發往同一台服務器。而基於源地址的hash散列，就是來自同一源地址的請求都發往同一台服務器。
④基於源地址的hash散列
上述已講，不再贅述。
動態調度
①最少連接調度算法
這種調度算法會記錄響應請求的服務器上所建立的連接數，每接收到一個請求會相應的將該服務器的所建立連接數加1，同時將新來的請求分配到當前連接數最少的那台機器上。
②加權最少連接調度算法
這種調度算法在最少連接調度算法的基礎上考慮到服務器的性能。當然，做這樣子的考慮是有其合理性存在的，如果是同一規格的服務器，那么建立的連接數越多，必然越增加其負載，那么僅僅根據最少連接數的調度算法，必然可以實現合理的負載均衡。但如果，服務器的性能不一樣呢?比如我有一台服務器，最多只能處理10個連接，現在建立了3個，還有一台服務器最多能處理1000條連接，現在建立了5個，如果單純地按照上述的最少連接調度算法，妥妥的前者嘛，但前者已經建立了百分之三十的連接了，而后者連百分之一的連接還沒有建立，試問，這合理嗎?顯然不合理。所以加上權重，才算合理。相應的公式也相當簡單：active*256/weight。
③最短期望調度算法
這種算法，是避免出現上述加權最少連接調度算法中的一種特殊情況，導致即使加上權重，調度器也無差別對待了，舉個栗子：
假設有三台服務器ABC，其當前所建立的連接數相應地為1,2,3，而權重也是1,2,3。那么如果按照加權最少連接調度算法的話，算出來是這樣子的：
A:1256/1=256
B:2256/2=256
C:3256/3=256
我們會發現，即便加上權重，A、B、C，經過計算還是一樣的，這樣子調度器會無差別的在A、B、C中任選一台，將請求發過去。
而最短期望將active256/weight的算法改進為(active+1)256/weight
那么還是之前的例子：
A:(1+1)256/1=2/1256=2256
B:(2+1)256/2=3/2256=1.5256
C:(3+1)256、3=4/3256≈1.3256
顯然C
④永不排隊算法
將請求發給當前連接數為0的服務器上。
⑤基於局部的最少連接調度算法
這種調度算法應用於Cache系統，維持一個請求到一台服務器的映射，其實我們仔細想想哈，之前做的一系列最少連接相關的調度算法。考慮到的是服務器的狀態與性能，但是一次請求並不是單向的，就像有一個從未合作過的大牛，他很閑，你讓他去解決一個之前碰到過的一個問題，未必有找一個之前已經跟你合作過哪怕現在不怎么閑的臭皮匠效果好哦~，所以基於局部的最少連接調度算法，維持的這種映射的作用是，如果來了一個請求，相對應的映射的那台服務器，沒有超載，ok交給老伙伴完事吧，俺放心，如果那台服務器不存在，或者是超載的狀態且有其他服務器工作在一半的負載狀態，則按最少連接調度算法在集群其余的服務器中找一台將請求分配給它。
⑥基於復制的局部最少連接調度算法
這種調度算法同樣應用於cache系統，但它維持的不是到一台服務器的映射而是到一組服務器的映射，當有新的請求到來，根據最小連接原則，從該映射的服務器組中選擇一台服務器，如果它沒有超載則交給它去處理這個請求，如果發現它超載，則從服務器組外的集群中，按最少連接原則拉一台機器加入服務器組，並且在服務器組有一段時間未修改后，將最忙的那台服務器從服務器組中剔除。
5.Sqoop用起來感覺怎樣?
說實話，Sqoop在導入數據的速度上確實十分感人，通過進一步了解，發現Sqoop1和Sqoop2在架構上還是有明顯不同的，無論是從數據類型上還是從安全權限，密碼暴露方面，Sqoop2都有了明顯的改進，同時同一些其他的異構數據同步工具比較,如淘寶的DataX或者Kettle相比，Sqoop無論是從導入數據的效率上還是從支持插件的豐富程度上，Sqoop還是相當不錯滴!!
6.ZooKeeper的角色以及相應的Zookepper工作原理?
果然，人的記憶力是有衰減曲線的，當面試官拋出這個問題后，前者角色，我只答出了兩種(leader和follower)，后者原理壓根就模糊至忘記了。所以惡補了一下，涉及到Zookeeper的角色大概有如下四種：leader、learner(follower)、observer、client。其中leader主要用來決策和調度，follower和observer的區別僅僅在於后者沒有寫的職能，但都有將client請求提交給leader的職能，而observer的出現是為了應對當投票壓力過大這種情形的，client就是用來發起請求的。而Zookeeper所用的分布式一致性算法包括leader的選舉其實和-原始部落的獲得神器為酋長，或者得玉璽者為皇帝類似，誰id最小，誰為leader，會根據你所配置的相應的文件在相應的節點機下生成id，然后相應的節點會通過getchildren()這個函數獲取之前設置的節點下生成的id，誰最小，誰是leader。並且如果萬一這個leader掛掉了或者墮落了，則由次小的頂上。而且在配置相應的zookeeper文件的時候回有類似於如下字樣的信息：Server.x=AAAA:BBBB:CCCC。其中的x即為你的節點號哈，AAAA對應你所部屬zookeeper所在的ip地址，BBBB為接收client請求的端口，CCCC為重新選舉leader端口。
7.HBase的Insert與Update的區別?
這個題目是就着最近的一次項目問的，當時實現的與hbase交互的三個方法分別為insert、delete、update。由於那個項目是對接的一個項目，對接的小伙伴和我協商了下，不將update合並為insert，如果合並的話，按那個項目本身，其實通過insert執行overwrite相當於間接地Update，本質上，或者說在展現上是沒什么區別的包括所調用的put。但那僅僅是就着那個項目的程序而言，如果基於HBaseshell層面。將同一rowkey的數據插入HBase，其實雖然展現一條，但是相應的timestamp是不一樣的，而且最大的版本數可以通過配置文件進行相應地設置。
8.請簡述大數據的結果展現方式。
1)報表形式
基於數據挖掘得出的數據報表，包括數據表格、矩陣、圖形和自定義格式的報表等，使用方便、設計靈活。
2)圖形化展現
提供曲線、餅圖、堆積圖、儀表盤、魚骨分析圖等圖形形式宏觀展現模型數據的分布情況，從而便於進行決策。
3)KPI展現
提供表格式績效一覽表並可自定義績效查看方式，如數據表格或走勢圖，企業管理者可根據可度量的目標快速評估進度。
4)查詢展現
按數據查詢條件和查詢內容，以數據表格來匯總查詢結果，提供明細查詢功能，並可在查詢的數據表格基礎上進行上鑽、下鑽、旋轉等操作。
9.例舉身邊的大數據。
i.QQ，微博等社交軟件產生的數據
ii.天貓，京東等電子商務產生的數據
iii.互聯網上的各種數據
10.簡述大數據的數據管理方式。
答：對於圖像、視頻、URL、地理位置等類型多樣的數據，難以用傳統的結構化方式描述，因此需要使用由多維表組成的面向列存儲的數據管理系統來組織和管理數據。也就是說，將數據按行排序，按列存儲，將相同字段的數據作為一個列族來聚合存儲。不同的列族對應數據的不同屬性，這些屬性可以根據需求動態增加，通過這樣的分布式實時列式數據庫對數據統一進行結構化存儲和管理，避免了傳統數據存儲方式下的關聯查詢。
11.什么是大數據?
答：大數據是指無法在容許的時間內用常規軟件工具對其內容進行抓取、管理和處理的數據。
12.海量日志數據，提取出某日訪問百度次數最多的那個IP。
首先是這一天，並且是訪問百度的日志中的IP取出來，逐個寫入到一個大文件中。注意到IP是32位的，最多有個2^32個IP。同樣可以采用映射的方法，比如模1000，把整個大文件映射為1000個小文件，再找出每個小文中出現頻率最大的IP(可以采用hash_map進行頻率統計，然后再找出頻率最大的幾個)及相應的頻率。然后再在這1000個最大的IP中，找出那個頻率最大的IP，即為所求。
或者如下闡述(雪域之鷹)：
算法思想：分而治之+Hash
1)IP地址最多有2^32=4G種取值情況，所以不能完全加載到內存中處理;
2)可以考慮采用“分而治之”的思想，按照IP地址的Hash(IP)%1024值，把海量IP日志分別存儲到1024個小文件中。這樣，每個小文件最多包含4MB個IP地址;
3)對於每一個小文件，可以構建一個IP為key，出現次數為value的Hashmap，同時記錄當前出現次數最多的那個IP地址;
4)可以得到1024個小文件中的出現次數最多的IP，再依據常規的排序算法得到總體上出現次數最多的IP;
13.搜索引擎會通過日志文件把用戶每次檢索使用的所有檢索串都記錄下來，每個查詢串的長度為1-255字節。
假設目前有一千萬個記錄(這些查詢串的重復度比較高，雖然總數是1千萬，但如果除去重復后，不超過3百萬個。一個查詢串的重復度越高，說明查詢它的用戶越多，也就是越熱門。)，請你統計最熱門的10個查詢串，要求使用的內存不能超過1G。
典型的TopK算法，還是在這篇文章里頭有所闡述，詳情請參見：十一、從頭到尾徹底解析Hash表算法。
文中，給出的最終算法是：
第一步、先對這批海量數據預處理，在O(N)的時間內用Hash表完成統計(之前寫成了排序，特此訂正。July、2011.04.27);
第二步、借助堆這個數據結構，找出TopK，時間復雜度為N‘logK。
即，借助堆結構，我們可以在log量級的時間內查找和調整/移動。因此，維護一個K(該題目中是10)大小的小根堆，然后遍歷300萬的Query，分別和根元素進行對比所以，我們最終的時間復雜度是：O(N)+N’*O(logK)，(N為1000萬，N’為300萬)。ok，更多，詳情，請參考原文。
或者：采用trie樹，關鍵字域存該查詢串出現的次數，沒有出現為0。最后用10個元素的最小推來對出現頻率進行排序。
14.有一個1G大小的一個文件，里面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M。返回頻數最高的100個詞。
方案：順序讀文件中，對於每個詞x，取hash(x)%5000，然后按照該值存到5000個小文件(記為x0,x1,…x4999)中。這樣每個文件大概是200k左右。
如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續往下分，直到分解得到的小文件的大小都不超過1M。
對每個小文件，統計每個文件中出現的詞以及相應的頻率(可以采用trie樹/hash_map等)，並取出出現頻率最大的100個詞(可以用含100個結點的最小堆)，並把100個詞及相應的頻率存入文件，這樣又得到了5000個文件。下一步就是把這5000個文件進行歸並(類似與歸並排序)的過程了。
15.有10個文件，每個文件1G，每個文件的每一行存放的都是用戶的query，每個文件的query都可能重復。要求你按照query的頻度排序。
還是典型的TOPK算法，解決方案如下：
方案1：
順序讀取10個文件，按照hash(query)%10的結果將query寫入到另外10個文件(記為)中。這樣新生成的文件每個的大小大約也1G(假設hash函數是隨機的)。
找一台內存在2G左右的機器，依次對用hash_map(query,query_count)來統計每個query出現的次數。利用快速/堆/歸並排序按照出現次數進行排序。將排序好的query和對應的query_cout輸出到文件中。這樣得到了10個排好序的文件(記為)。
對這10個文件進行歸並排序(內排序與外排序相結合)。
方案2：
一般query的總量是有限的，只是重復的次數比較多而已，可能對於所有的query，一次性就可以加入到內存了。這樣，我們就可以采用trie樹/hash_map等直接來統計每個query出現的次數，然后按出現次數做快速/堆/歸並排序就可以了。
方案3：
與方案1類似，但在做完hash，分成多個文件后，可以交給多個文件來處理，采用分布式的架構來處理(比如MapReduce)，最后再進行合並。
16.給定a、b兩個文件，各存放50億個url，每個url各占64字節，內存限制是4G，讓你找出a、b文件共同的url?
方案1：可以估計每個文件安的大小為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：如果允許有一定的錯誤率，可以使用Bloomfilter，4G內存大概可以表示340億bit。將其中一個文件中的url使用Bloomfilter映射為這340億bit，然后挨個讀取另外一個文件的url，檢查是否與Bloomfilter，如果是，那么該url應該是共同的url(注意會有一定的錯誤率)。
Bloomfilter日后會在本BLOG內詳細闡述。
17.在2.5億個整數中找出不重復的整數，注，內存不足以容納這2.5億個整數。
方案1：采用2-Bitmap(每個數分配2bit，00表示不存在，01表示出現一次，10表示多次，11無意義)進行，共需內存2^32*2bit=1GB內存，還可以接受。然后掃描這2.5億個整數，查看Bitmap中相對應位，如果是00變01，01變10，10保持不變。所描完事后，查看bitmap，把對應位是01的整數輸出即可。
方案2：也可采用與第1題類似的方法，進行划分小文件的方法。然后在小文件中找出不重復的整數，並排序。然后再進行歸並，注意去除重復的元素。
18.騰訊面試題：給40億個不重復的unsignedint的整數，沒排過序的，然后再給一個數，如何快速判斷這個數是否在那40億個數當中?
與上第6題類似，我的第一反應時快速排序+二分查找。以下是其它更好的方法：
方案1：oo，申請512M的內存，一個bit位代表一個unsignedint值。讀入40億個數，設置相應的bit位，讀入要查詢的數，查看相應bit位是否為1，為1表示存在，為0表示不存在。
dizengrong：
方案2：這個問題在《編程珠璣》里有很好的描述，大家可以參考下面的思路，探討一下：
又因為2^32為40億多，所以給定一個數可能在，也可能不在其中;
這里我們把40億個數中的每一個用32位的二進制來表示
假設這40億個數開始放在一個文件中。
然后將這40億個數分成兩類:
1.最高位為0
2.最高位為1
並將這兩類分別寫入到兩個文件中，其中一個文件中數的個數<=20億，而另一個>=20億(這相當於折半了);
與要查找的數的最高位比較並接着進入相應的文件再查找
再然后把這個文件為又分成兩類:
1.次最高位為0
2.次最高位為1
並將這兩類分別寫入到兩個文件中，其中一個文件中數的個數<=10億，而另一個>=10億(這相當於折半了);
與要查找的數的次最高位比較並接着進入相應的文件再查找。
…….
以此類推，就可以找到了,而且時間復雜度為O(logn)，方案2完。
附：這里，再簡單介紹下，位圖方法：
使用位圖法判斷整形數組是否存在重復
判斷集合中存在重復是常見編程任務之一，當集合中數據量比較大時我們通常希望少進行幾次掃描，這時雙重循環法就不可取了。
位圖法比較適合於這種情況，它的做法是按照集合中最大元素max創建一個長度為max+1的新數組，然后再次掃描原數組，遇到幾就給新數組的第幾位置上1，如遇到5就給新數組的第六個元素置1，這樣下次再遇到5想置位時發現新數組的第六個元素已經是1了，這說明這次的數據肯定和以前的數據存在着重復。這種給新數組初始化時置零其后置一的做法類似於位圖的處理方法故稱位圖法。它的運算次數最壞的情況為2N。如果已知數組的最大值即能事先給新數組定長的話效率還能提高一倍。
歡迎，有更好的思路，或方法，共同交流。
19.怎么在海量數據中找出重復次數最多的一個?
方案1：先做hash，然后求模映射為小文件，求出每個小文件中重復次數最多的一個，並記錄重復次數。然后找出上一步求出的數據中重復次數最多的一個就是所求(具體參考前面的題)。
20.上千萬或上億數據(有重復)，統計其中出現次數最多的錢N個數據。
方案1：上千萬或上億的數據，現在的機器的內存應該能存下。所以考慮采用hash_map/搜索二叉樹/紅黑樹等來進行統計次數。然后就是取出前N個出現次數最多的數據了，可以用第2題提到的堆機制完成。
21.一個文本文件，大約有一萬行，每行一個詞，要求統計出其中最頻繁出現的前10個詞，請給出思想，給出時間復雜度分析。
方案1：這題是考慮時間效率。用trie樹統計每個詞出現的次數，時間復雜度是O(n*le)(le表示單詞的平准長度)。然后是找出出現最頻繁的前10個詞，可以用堆來實現，前面的題中已經講到了，時間復雜度是O(n*lg10)。所以總的時間復雜度，是O(n*le)與O(n*lg10)中較大的哪一個。
附、100w個數中找出最大的100個數。
方案1：在前面的題中，我們已經提到了，用一個含100個元素的最小堆完成。復雜度為O(100w*lg100)。
方案2：采用快速排序的思想，每次分割之后只考慮比軸大的一部分，知道比軸大的一部分在比100多的時候，采用傳統排序算法排序，取前100個。復雜度為O(100w*100)。
方案3：采用局部淘汰法。選取前100個元素，並排序，記為序列L。然后一次掃描剩余的元素x，與排好序的100個元素中最小的元素比，如果比這個最小的要大，那么把這個最小的元素刪除，並把x利用插入排序的思想，插入到序列L中。依次循環，知道掃描了所有的元素。復雜度為O(100w*100)。
第二部分、十個海量數據處理方法大總結
ok，看了上面這么多的面試題，是否有點頭暈。是的，需要一個總結。接下來，本文將簡單總結下一些處理海量數據問題的常見方法，而日后，本BLOG內會具體闡述這些方法。
一、Bloomfilter
適用范圍：可以用來實現數據字典，進行數據的判重，或者集合求交集
基本原理及要點：
對於原理來說很簡單，位數組+k個獨立hash函數。將hash函數對應的值的位數組置1，查找時如果發現所有hash函數對應位都是1說明存在，很明顯這個過程並不保證查找的結果是100%正確的。同時也不支持刪除一個已經插入的關鍵字，因為該關鍵字對應的位會牽動到其他的關鍵字。所以一個簡單的改進就是countingBloomfilter，用一個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的。所以使用bloomfilter內存上通常都是節省的。
擴展：
Bloomfilter將集合中的元素映射到位數組中，用k(k為哈希函數個數)個映射位是否全1表示元素在不在這個集合中。Countingbloomfilter(CBF)將位數組中的每一位擴展為一個counter，從而支持了元素的刪除操作。SpectralBloomFilter(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，則大大簡單了。
二、Hashing
適用范圍：快速查找，刪除的基本數據結構，通常需要總數據量可以放入內存
基本原理及要點：
hash函數選擇，針對字符串，整數，排列，具體相應的hash方法。
碰撞處理，一種是openhashing，也稱為拉鏈法;另一種就是closedhashing，也稱開地址法，openedaddressing。
擴展：
d-lefthashing中的d是多個的意思，我們先簡化這個問題，看一看2-lefthashing。2-lefthashing指的是將一個哈希表分成長度相等的兩半，分別叫做T1和T2，給T1和T2分別配備一個哈希函數，h1和h2。在存儲一個新的key時，同時用兩個哈希函數進行計算，得出兩個地址h1[key]和h2[key]。這時需要檢查T1中的h1[key]位置和T2中的h2[key]位置，哪一個位置已經存儲的(有碰撞的)key比較多，然后將新key存儲在負載少的位置。如果兩邊一樣多，比如兩個位置都為空或者都存儲了一個key，就把新key存儲在左邊的T1子表中，2-left也由此而來。在查找一個key時，必須進行兩次hash，同時查找兩個位置。
問題實例：
1).海量日志數據，提取出某日訪問百度次數最多的那個IP。
IP的數目還是有限的，最多2^32個，所以可以考慮使用hash將ip直接存入內存，然后進行統計。
三、bit-map
適用范圍：可進行數據的快速查找，判重，刪除，一般來說數據范圍是int的10倍以下
基本原理及要點：使用bit數組來表示某些元素是否存在，比如8位電話號碼
擴展：bloomfilter可以看做是對bit-map的擴展
問題實例：
1)已知某個文件內包含一些電話號碼，每個號碼為8位數字，統計不同號碼的個數。
8位最多99999999，大概需要99m個bit，大概10幾m字節的內存即可。
2)2.5億個整數中找出不重復的整數的個數，內存空間不足以容納這2.5億個整數。
將bit-map擴展一下，用2bit表示一個數即可，0表示未出現，1表示出現一次，2表示出現2次及以上。或者我們不用2bit來進行表示，我們用兩個bit-map即可模擬實現這個2bit-map。
四、堆
適用范圍：海量數據前n大，並且n比較小，堆可以放入內存
基本原理及要點：最大堆求前n小，最小堆求前n大。方法，比如求前n小，我們比較當前元素與最大堆里的最大元素，如果它小於最大元素，則應該替換那個最大元素。這樣最后得到的n個元素就是最小的n個。適合大數據量，求前n小，n的大小比較小的情況，這樣可以掃描一遍即可得到所有的前n元素，效率很高。
擴展：雙堆，一個最大堆與一個最小堆結合，可以用來維護中位數。
問題實例：
1)100w個數中找最大的前100個數。
用一個100個元素大小的最小堆即可。
五、雙層桶划分—-其實本質上就是【分而治之】的思想，重在“分”的技巧上!
適用范圍：第k大，中位數，不重復或重復的數字
基本原理及要點：因為元素范圍很大，不能利用直接尋址表，所以通過多次划分，逐步確定范圍，然后最后在一個可以接受的范圍內進行。可以通過多次縮小，雙層只是一個例子。
擴展：
問題實例：
1).2.5億個整數中找出不重復的整數的個數，內存空間不足以容納這2.5億個整數。
有點像鴿巢原理，整數個數為2^32,也就是，我們可以將這2^32個數，划分為2^8個區域(比如用單個文件代表一個區域)，然后將數據分離到不同的區域，然后不同的區域在利用bitmap就可以直接解決了。也就是說只要有足夠的磁盤空間，就可以很方便的解決。
2).5億個int找它們的中位數。
這個例子比上面那個更明顯。首先我們將int划分為2^16個區域，然后讀取數據統計落到各個區域里的數的個數，之后我們根據統計結果就可以判斷中位數落到那個區域，同時知道這個區域中的第幾大數剛好是中位數。然后第二次掃描我們只統計落在這個區域中的那些數就可以了。
實際上，如果不是int是int64，我們可以經過3次這樣的划分即可降低到可以接受的程度。即可以先將int64分成2^24個區域，然后確定區域的第幾大數，在將該區域分成2^20個子區域，然后確定是子區域的第幾大數，然后子區域里的數的個數只有2^20，就可以直接利用directaddrtable進行統計了。
六、數據庫索引
適用范圍：大數據量的增刪改查
基本原理及要點：利用數據的設計實現方法，對海量數據的增刪改查進行處理。
七、倒排索引(Invertedindex)
適用范圍：搜索引擎，關鍵字查詢
基本原理及要點：為何叫倒排索引?一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。
以英文為例，下面是要被索引的文本：
T0=“itiswhatitis”
T1=“whatisit”
T2=“itisabanana”
我們就能得到下面的反向文件索引：
“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有些不夠，所以可以用來排序。內存可以當輸入緩沖區使用。
九、trie樹
適用范圍：數據量大，重復多，但是數據種類小可以放入內存
基本原理及要點：實現方式，節點孩子的表示方式
擴展：壓縮實現。
問題實例：
1).有10個文件，每個文件1G，每個文件的每一行都存放的是用戶的query，每個文件的query都可能重復。要你按照query的頻度排序。
2).1000萬字符串，其中有些是相同的(重復),需要把重復的全部去掉，保留沒有重復的字符串。請問怎么設計和實現?
3).尋找熱門查詢：查詢串的重復度比較高，雖然總數是1千萬，但如果除去重復后，不超過3百萬個，每個不超過255字節。
十、分布式處理mapreduce
適用范圍：數據量大，但是數據種類小可以放入內存
基本原理及要點：將數據交給不同的機器去處理，數據划分，結果歸約。
擴展：
問題實例：
1).ThecanonicalexampleapplicationofMapReduceisaprocesstocounttheappearancesof
eachdifferentwordinasetofdocuments:
2).海量數據分布在100台電腦中，想個辦法高效統計出這批數據的TOP10。
3).一共有N個機器，每個機器上有N個數。每個機器最多存O(N)個數並對它們操作。如何找到N^2個數的中數(median)?
經典問題分析
上千萬or億數據(有重復)，統計其中出現次數最多的前N個數據,分兩種情況：可一次讀入內存，不可一次讀入。
可用思路：trie樹+堆，數據庫索引，划分子集分別統計，hash，分布式計算，近似統計，外排序
所謂的是否能一次讀入內存，實際上應該指去除重復后的數據量。如果去重后數據可以放入內存，我們可以為數據建立字典，比如通過map，hashmap，trie，然后直接進行統計即可。當然在更新每條數據的出現次數的時候，我們可以利用一個堆來維護出現次數最多的前N個數據，當然這樣導致維護次數增加，不如完全統計后在求前N大效率高。
如果數據無法放入內存。一方面我們可以考慮上面的字典方法能否被改進以適應這種情形，可以做的改變就是將字典存放到硬盤上，而不是內存，這可以參考數據庫的存儲方法。
當然還有更好的方法，就是可以采用分布式計算，基本上就是map-reduce過程，首先可以根據數據值或者把數據hash(md5)后的值，將數據按照范圍划分到不同的機子，最好可以讓數據划分后可以一次讀入內存，這樣不同的機子負責處理各種的數值范圍，實際上就是map。得到結果后，各個機子只需拿出各自的出現次數最多的前N個數據，然后匯總，選出所有的數據中出現次數最多的前N個數據，這實際上就是reduce過程。
實際上可能想直接將數據均分到不同的機子上進行處理，這樣是無法得到正確的解的。因為一個數據可能被均分到不同的機子上，而另一個則可能完全聚集到一個機子上，同時還可能存在具有相同數目的數據。比如我們要找出現次數最多的前100個，我們將1000萬的數據分布到10台機器上，找到每台出現次數最多的前100個，歸並之后這樣不能保證找到真正的第100個，因為比如出現次數最多的第100個可能有1萬個，但是它被分到了10台機子，這樣在每台上只有1千個，假設這些機子排名在1000個之前的那些都是單獨分布在一台機子上的，比如有1001個，這樣本來具有1萬個的這個就會被淘汰，即使我們讓每台機子選出出現次數最多的1000個再歸並，仍然會出錯，因為可能存在大量個數為1001個的發生聚集。因此不能將數據隨便均分到不同機子上，而是要根據hash后的值將它們映射到不同的機子上處理，讓不同的機器處理一個數值范圍。
而外排序的方法會消耗大量的IO，效率不會很高。而上面的分布式方法，也可以用於單機版本，也就是將總的數據根據值的范圍，划分成多個不同的子文件，然后逐個處理。處理完畢之后再對這些單詞的及其出現頻率進行一個歸並。實際上就可以利用一個外排序的歸並過程。
另外還可以考慮近似計算，也就是我們可以通過結合自然語言屬性，只將那些真正實際中出現最多的那些詞作為一個字典，使得這個規模可以放入內存。
【某公司筆試面試題】
1使用mr，spark,sparksql編寫wordcount程序
【Spark版本】
valconf=newSparkConf().setAppName("wd").setMaster("local[1]")
valsc=newSparkContext(conf,2)
//加載
vallines=sc.textFile("tructField("name",DataTypes.StringType,true)")
valparis=lines.flatMap(line=>line.split("^A"))
valwords=paris.map((_,1))
valresult=words.reduceByKey(_+_).sortBy(x=>x._1,false)
//打印
result.foreach(
wds=>{
println("單詞："+wds._1+"個數："+wds._2)
}
)
sc.stop()
【sparksql版本】
valconf=newSparkConf().setAppName("sqlWd").setMaster("local[1]")
valsc=newSparkContext(conf)
valsqlContext=newSQLContext(sc)
//加載
vallines=sqlContext.textFile("E:idea15createRecommederdatawords.txt")
valwords=lines.flatMap(x=>x.split("")).map(y=>Row(y))
valstructType=StructType(Array(StructField("name",DataTypes.StringType,true)))
valdf=sqlContext.createDataFrame(rows,structType)
df.registerTempTable("t_word_count")
sqlContext.udf.register("num_word",(name:String)=>1)
sqlContext.sql("selectname,num_word(name)fromt_word_count").groupBy(df.col("name")).count().show()
sc.stop()
2hive的使用，內外部表的區別，分區作用，UDF和Hive優化
(1)hive使用：倉庫、工具
(2)hive內外部表：內部表數據永久刪除，外部表數據刪除后、其他人依然可以訪問
(3)分區作用：防止數據傾斜
(4)UDF函數：用戶自定義的函數(主要解決格式，計算問題)，需要繼承UDF類
java代碼實現
classTestUDFHiveextendsUDF{
publicStringevalute(Stringstr){
try{
return"hello"+str
}catch(Exceptione){
returnstr+"error"
}
}
}
(5)Hive優化：看做mapreduce處理
a排序優化：sortby效率高於orderby
b分區：使用靜態分區(statu_date="20160516",location="beijin")，每個分區對應hdfs上的一個目錄
c減少job和task數量：使用表鏈接操作
d解決groupby數據傾斜問題：設置hive.groupby.skewindata=true，那么hive會自動負載均衡
e小文件合並成大文件：表連接操作
f使用UDF或UDAF函數：hive中UDTF編寫和使用(轉) - ggjucheng - 博客園
3Hbase的rk設計，Hbase優化
aowkey:hbase三維存儲中的關鍵(rowkey：行鍵，columnKey(family+quilaty)：列鍵，timestamp：時間戳)
owkey字典排序、越短越好
使用id+時間：9527+20160517使用hash散列：dsakjkdfuwdsf+9527+20160518
應用中，rowkey一般10~100bytes,8字節的整數倍，有利於提高操作系統性能
bHbase優化
分區：RegionSplit()方法NUMREGIONS=9
column不超過3個
硬盤配置，便於regionServer管理和數據備份及恢復
分配合適的內存給regionserver
其他：
hbase查詢
(1)get
(2)scan
使用startRow和endRow限制
4Linux常用操作
aawk：
awk-F:`BEGIN{print"nameip"}{print$1$7}END{print"結束"}`/etc/passwd
last|head-5|awk`BEGIN{print"nameip"}{print$1$3}END{print"結束了"}`
bsed
5java線程2種方式實現、設計模式、鏈表操作、排序
(1)2種線程實現
aThread類繼承
TestCLth=newTestCL()//類繼承Thread
th.start()
b實現Runnable接口
Threadth=newThread(newRunnable(){
publicvoidrun(){
//實現
}
})
th.start()
(2)設計模式，分為4類
a創建模式：如工廠模式、單例模式
b結構模式：代理模式
c行為模式：觀察者模式
d線程池模式
6【最熟悉的一個項目簡介、架構圖、使用的技術、你負責哪塊】
7cdh集群監控
(1)數據庫監控(2)主機監控(3)服務監控(4)活動監控
8計算機網絡工作原理
將分散的機器通過數據通信原理連接起來，實現共享!
9hadoop生態系統
hdfsmapreducehivehbasezookeeperlume
hdfs原理及各個模塊的功能mapreduce原理mapreduce優化數據傾斜
11系統維護：hadoop升級datanode節點
12【講解項目要點：數據量、多少人、分工、運行時間、項目使用機器、算法、技術】
13【學會向對方提問】
14jvm運行機制及內存原理
運行：
I加載.class文件
II管理並且分配內存
III垃圾回收
內存原理：
IJVM裝載環境和配置
II裝載JVM.dll並初始化JVM.dll
IV處理class類
15hdfs、yarn參數調優
mapreduce.job.jvm.num.tasks
默認為1，設置為-1，重用jvm
16Hbase、Hive、impala、zookeeper、Storm、spark原理和使用方法、使用其架構圖講解
【某公司筆試題】
1、如何為一個hadoop任務設置mappers的數量
答案：
使用job.setNumMapTask(intn)手動分割，這是不靠譜的
官方文檔：“Note:Thisisonlyahinttotheframework”說明這個方法只是提示作用，不起決定性作用
實際上要用公式計算：
Max(min.split，min(max.split，block))就設置分片的最大最下值computeSplitSize()設置
參考：深度分析如何在Hadoop中控制Map的數量 - 張貴賓的技術專欄 - 博客頻道 - CSDN.NET
2、有可能使hadoop任務輸出到多個目錄中么?如果可以，怎么做?
答案：在1.X版本后使用MultipleOutputs.java類實現
源碼：
MultipleOutputs.addNamedOutput(conf,"text2",TextOutputFormat.class,Long.class,String.class);
MultipleOutputs.addNamedOutput(conf,"text3",TextOutputFormat.class,Long.class,String.class);
參考：MapReduce中的自定義多目錄/文件名輸出HDFS - leejun2005的個人頁面 - 開源中國社區
發音：Multiple['m?lt?pl]--》許多的
3、如何為一個hadoop任務設置要創建的reducer的數量
答案：job.setNumReduceTask(intn)
或者調整hdfs-site.xml中的mapred.tasktracker.reduce.tasks.maximum默認參數值
4、在hadoop中定義的主要公用InputFormats中，哪一個是默認值：
(A)TextInputFormat
(B)KeyValueInputFormat
(C)SequenceFileInputFormat
答案：A
5、兩個類TextInputFormat和KeyValueTextInputFormat的區別?
答案：
?FileInputFormat的子類：
TextInputFormat(默認類型，鍵是LongWritable類型，值為Text類型，key為當前行在文件中的偏移量，value為當前行本身);
?KeyValueTextInputFormat(適合文件自帶key，value的情況，只要指定分隔符即可，比較實用，默認是分割);
源碼：
StringsepStr=job.get("mapreduce.input.keyvaluelinerecordreader.key.value.separator","");
注意：在自定義輸入格式時，繼承FileInputFormat父類
6、在一個運行的hadoop任務中，什么是InputSpilt?
答案：InputSplit是MapReduce對文件進行處理和運算的輸入單位，只是一個邏輯概念，每個InputSplit並沒有對文件實際的切割，只是記錄了要處理的數據的位置(包括文件的path和hosts)和長度(由start和length決定)，默認情況下與block一樣大。
拓展：需要在定義InputSplit后，展開講解mapreduce的原理
7、Hadoop框架中，文件拆分是怎么被調用的?
答案：JobTracker，創建一個InputFormat的實例，調用它的getSplits()方法，把輸入目錄的文件拆分成FileSplist作為Mappertask的輸入，生成Mappertask加入Queue。
源碼中體現了拆分的數量
longgoalSize=totalSize/(numSplits==0?1:numSplits);
longminSize=Math.max(job.getLong(org.apache.hadoop.mapreduce.lib.input.
FileInputFormat.SPLIT_MINSIZE,1),minSplitSize);//minSplitSize默認是1
8、分別舉例什么情況下使用combiner,什么情況下不會使用?
答案：Combiner適用於對記錄匯總的場景(如求和)，但是，求平均數的場景就不能使用Combiner了
9、Hadoop中job和Tasks之間的區別是什么?
答案：
job是工作的入口，負責控制、追蹤、管理任務，也是一個進程
包含maptask和reducetask
Tasks是map和reduce里面的步驟，主要用於完成任務，也是線程
10、Hadoop中通過拆分任務到多個節點運行來實現並行計算，但是某些節點運行較慢會拖慢整個任務的運行，hadoop采用何種機制應對這種情況?
答案：結果查看監控日志，得知產生這種現象的原因是數據傾斜問題
解決：
(1)調整拆分mapper的數量(partition數量)
(2)增加jvm
(3)適當地將reduce的數量變大
11、流API中的什么特性帶來可以使mapreduce任務可以以不同語言(如perlubyawk等)實現的靈活性?
答案：用可執行文件作為Mapper和Reducer，接受的都是標准輸入，輸出的都是標准輸出
12、參考下面的M/R系統的場景：
--HDFS塊大小為64MB
--輸入類型為FileInputFormat
--有3個文件的大小分別是：64k65MB127MB
Hadoop框架會把這些文件拆分為多少塊?
答案：
64k------->一個block
65MB---->兩個文件：64MB是一個block，1MB是一個block
127MB--->兩個文件：64MB是一個block,63MB是一個block
13、Hadoop中的RecordReader的作用是什么?
答案：屬於split和mapper之間的一個過程
將inputsplit輸出的行為一個轉換記錄，成為key-value的記錄形式提供給mapper
14、Map階段結束后，Hadoop框架會處理：Partitioning,shuffle和sort,在這個階段都會發生了什么?
答案：
MR一共有四個階段，splitmapshuffreduce在執行完map之后，可以對map的輸出結果進行分區，
分區：這塊分片確定到哪個reduce去計算(匯總)
排序：在每個分區中進行排序，默認是按照字典順序。
Group：在排序之后進行分組
15、如果沒有定義partitioner,那么數據在被送達reducer前是如何被分區的?
答案：
Partitioner是在map函數執行context.write()時被調用。
用戶可以通過實現自定義的?Partitioner來控制哪個key被分配給哪個?Reducer。
查看源碼知道：
如果沒有定義partitioner，那么會走默認的分區Hashpartitioner
publicclassHashPartitionerextendsPartitioner{
/**Use{@linkObject#hashCode()}topartition.*/
publicintgetPartition(Kkey,Vvalue,intnumReduceTasks){
return(key.hashCode()&Integer.MAX_VALUE)%numReduceTasks;
}
}
16、什么是Combiner?
答案：這是一個hadoop優化性能的步驟，它發生在map與reduce之間
目的：解決了數據傾斜的問題，減輕網絡壓力，實際上時減少了maper的輸出
源碼信息如下：
publicvoidreduce(Textkey,Iteratorvalues,
OutputCollectoroutput,Reporterreporter)
throwsIOException{
LongWritablemaxValue=null;
while(values.hasNext()){
LongWritablevalue=values.next();
if(maxValue==null){
maxValue=value;
}elseif(value.compareTo(maxValue)>0){
maxValue=value;
}
}
output.collect(key,maxValue);
}
在collect實現類中，有這樣一段方法
publicsynchronizedvoidcollect(Kkey,Vvalue)
throwsIOException{
outCounter.increment(1);
writer.append(key,value);
if((outCounter.getValue()%progressBar)==0){
progressable.progress();
}
}