1 . 談談資料傾斜，它如何發生的，並給出優化方案!
首先談一下什麼是資料傾斜? 答：map /reduce程式執行時，reduce節點大部分執行完畢，但是有一個或者幾個reduce節點執行很慢，導致整個程式的處理時間很長。現象是 : 進度長時間維持在99%（或100%），檢視任務監控頁面，發現只有少量（1個或幾個）reduce子任務未完成；檢視未完成的子任務，可以看到本地讀寫資料量積累非常大，通常超過10GB可以認定為發生資料傾斜。
如何發生的?資料的傾斜主要是兩個的資料相差的數量不在一個級別上 ,這是因為某一個key的條數比其他key多很多（有時是百倍或者千倍之多）,這條key所在的reduce節點所處理的資料量比其他節點就大很多，從而導致某幾個節點遲遲執行不完。
優化方案 :
方式一 : reduce 本身的計算需要以合適的記憶體作為支援，在硬體環境容許的情況下，增加reduce 的JVM記憶體大小顯然有改善資料傾斜的可能，這種方式尤其適合資料分佈第一種情況，單個值有大量記錄, 這種值的所有紀錄已經超過了分配給reduce 的記憶體，無論你怎麼樣分割槽這種情況都不會改變. 當然這種情況的限制也非常明顯, 1.記憶體的限制存在，2.可能會對叢集其他任務的執行產生不穩定的影響。
方式二 : 這個對於資料分佈第二種情況有效，情況(一值較多，單個唯一值的記錄數不會超過分配給reduce 的記憶體). 如果發生了偶爾的資料傾斜情況，增加reduce 個數可以緩解偶然情況下的某些reduce 不小心分配了多個較多記錄數的情況. 但是對於第一種資料分佈無效。
方式三 : 一種情況是某個領域知識告訴你資料分佈的顯著型別，比如<

2 . datanode 首次加入 cluster 的時候，如果 log 報告不相容檔案版本，那需要namenode 執行格式化操作，這樣處理的原因是？(可以當成工作中遇到的問題!)
這樣處理是不合理的，因為那麼 namenode 格式化操作，是對檔案系統進行格式化，namenode 格式化時清空 dfs/name 下空兩個目錄下的所有檔案，之後，會在目錄 dfs.name.dir 下建立檔案。文字不相容，有可能時 namenode 與 datanode 的 資料裡的 namespaceID、clusterID 不一致，找到兩個 ID 位置，修改為一樣即可解決。