Hadoop采用64M的分塊有什么優勢

小編給大家分享一下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操作的。想想歸并排序算法的思想，對小文件進行排序，然后將小文件歸并成大文件的思想，然后就會懂這點了....

以上是“Hadoop采用64M的分塊有什么優勢”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！