1. Hadoop會有哪些重大故障，如何應對？
1）namenode單點故障：通過zookeeper搭建HA高可用，可自動切換namenode。
2）ResourceManager單點故障：可通過配置YARN的HA，並在配置的namenode上手動啓動ResourceManager作爲Slave，在Master 故障後，Slave 會自動切換爲Master。
3）reduce階段內存溢出：是由於單個reduce任務處理的數據量過多，通過增大reducetasks數目、優化partition 規則使數據分佈均勻進行解決。
4）datanode內存溢出：是由於創建的線程過多，通過調整linux的maxuserprocesses參數，增大可用線程數進行解決。
5）集羣間時間不同步導致運行異常：通過配置內網時間同步服務器進行解決。
數據如何導入HDFS中，又如何導入數據庫中？
數據處理之前的導入：通過HDFS shell命令或者Java API程序導入到HDFS中，如果需要導入Hive中，則在創建Hive數據表的時候load HDFS上的目標文件路徑。
數據處理完成之後的導出：假設是hive處理完成之後的數據，可通過sqoop導出到本地的MySQL數據庫中。
列舉你瞭解的海量數據的處理方法以及使用範圍
- mapreduce： 大數據常用的分佈式離線計算框架，核心思想爲分而治之。
- 倒排索引：一種索引方法，用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射，在倒排索引中單詞指向了包含單詞的文檔。
- 消息隊列：大量的數據寫入首先存入消息隊列進行緩衝，再把消息隊列作爲數據來源進行數據讀取。這種方法在實時計算中經常用到，例如SparkStreamming Storm。比較常用的消息隊列如kafka。
- 數據庫讀寫分離：在一臺數據庫中寫入數據，另外的多臺數據庫從這臺數據庫中進行讀取。
開放性問題(根絕你學過的知識 擴展你的思維)
大廠，例如騰訊 阿里會出這樣的問題？ 自己設計算法或者實現方案來解決。
1. 有一個1G大小的一個文件，裏面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M。返回頻數最高的100 個詞？
解決方案：順序讀文件中，對於每個詞 x，取 hash(x)%5000，然後按照該值存到 5000 個小文件（記爲 x0,x1,…x4999）中。這樣每個文件大概是 200k 左右。
如果其中的有的文件超過了1M 大小，還可以按照類似的方法繼續往下分，直到分解得到的小文件的大小都不超過 1M。 (這一過程就是mapreduce程序中 map方法中對數據的分割！！)
對每個小文件，統計每個文件中出現的詞以及相應的頻率（可以採用 trie 樹/hash_map 等），並取出出現頻率最大的100個詞（可以用含100個結點的最小堆），並把100個詞及相應的頻率存入文件，這樣又得到了5000個文件（這裏實質就是reduce階段的核心思想）。
下一步就是把這5000個文件進行歸併（類似與歸併排序）的過程了。
2. 有 10 個文件，每個文件1G，每個文件的每一行存放的都是用戶的query，每個文件的query都可能重複。要求你按照query的頻度排序 ？
解決方案如下：
方案 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），最後再進行合併。
3. 給定 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：如果允許有一定的錯誤率，可以使用Bloom filter，4G內存大概可以表示340億bit。將其中一個文件中的url使用Bloom filter映射爲這340億 bit，然後挨個讀取另外一個文件的url，檢查是否與 Bloom filter，如果是，那麼該 url 應該是共同的 url（注意會有一定的錯誤率）。
未完待續， 之後南國 有總結更好的問題 定會持續更新~