爲何Hadoop採用64M的分塊？

• 減小硬盤尋道時間(disk seek time)

          HDFS設計前提是支持大容量的流式數據操做，因此即便是通常的數據讀寫操做，涉及到的數據量都是比較大的。假如數據塊設置過少，那須要讀取的數據塊就比較多，因爲數據塊在硬盤上非連續存儲，普通硬盤由於須要移動磁頭，因此隨機尋址較慢，讀越多的數據塊就增大了總的硬盤尋道時間。當硬盤尋道時間比io時間還要長的多時，那麼硬盤尋道時間就成了系統的一個瓶頸。 合適的塊大小有助於減小硬盤尋道時間，提升系統吞吐量。

• 減小Namenode內存消耗

          對於HDFS，他只有一個Namenode節點，他的內存相對於Datanode來講，是極其有限的。然而，namenode須要在其內存FSImage文件中中記錄在Datanode中的數據塊信息，假如數據塊大小設置過少，而須要維護的數據塊信息就會過多，那Namenode的內存可能就會傷不起了。

爲何不能遠大於64MB(或128MB或256MB)

這裏主要從上層的MapReduce框架來討論

Map崩潰問題：

系統須要從新啓動，啓動過程須要從新加載數據，數據塊越大，數據加載時間越長，系統恢復過程越長。

監管時間問題：

      主節點監管其餘節點的狀況，每一個節點會週期性的把完成的工做和狀態的更新報告回來。若是一個節點保持沉默超過一個預設的時間間隔，主節點記錄下這個節點狀態爲死亡，並把分配給這個節點的數據發到別的節點。對於這個「預設的時間間隔」，這是從數據塊的角度大概估算的。假如是對於64MB的數據塊，我能夠假設你10分鐘以內不管如何也能解決了吧，超過10分鐘也沒反應，那就是死了。可對於640MB或是1G以上的數據，我應該要估算個多長的時間內？估算的時間短了，那就誤判死亡了，分分鐘更壞的狀況是全部節點都會被判死亡。估算的時間長了，那等待的時間就過長了。因此對於過大的數據塊，這個「預設的時間間隔」很差估算。

 

問題分解問題：

數據量大小是問題解決的複雜度是成線性關係的。對於同個算法，處理的數據量越大，它的時間複雜度也就越大。

約束Map輸出：

         在Map Reduce框架裏，Map以後的數據是要通過排序才執行Reduce操做的。想一想歸併排序算法的思想，對小文件進行排序，而後將小文件歸併成大文件的思想，而後就會懂這點了....