1 HDFS的設計特點？

可以進行超大文件存儲

對商用硬件要求不高

式數據訪問：適合一次寫入，多次讀出的場景，適合用來做數據分析，并不適合用來做網盤應用等文件系統。

HDFS只支持單個寫入者，而且文件的寫入只能以“添加”方式在文件末尾寫數據。

因為namenode的原因，不適合大量小文件的存儲。

數據訪問的延遲相對較高，不適合進行低延遲處理

對商業硬件要求低，可以再廉價的機器上運行。

2 HDFS 文件塊大小問題？

塊的大小設置原則：最小化尋址開銷。

HDFS的塊比磁盤的塊大(磁盤的塊一般為512字節)，其目的是為了最小化尋址開銷

然而真正實際開發中要把block設置的遠大于128MB，比如存儲文件是1TB時，一般把Block大小設置成512MB.但是也不能任意設置的太大，比如200GB一個，因為在MapReduce的map任務中通常一次只處理一個塊中數據(切片大小默認等于block大小)，如果設置太大，因為任務數太少(少于集群中的節點數量)，那么作業的運行速度就會慢很多，此外比如故障等原因也會拖慢速度。

如何設置塊的大小？

主要由以下考慮：

減少硬盤尋道時間(disk seek time)：

減少Namenode內存消耗：

Map崩潰問題：

監管時間問題：

問題分解問題：

約束Map輸出：

詳細說明

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

HDFS設計前提是支持大容量的流式數據操作，所以即使是一般的數據讀寫操作，涉及到的數據量都是比較大的。假如數據塊設置過少，那需要讀取的數據塊就比較多，由于數據塊在硬盤上非連續存儲，普通硬盤因為需要移動磁頭，所以隨機尋址較慢，讀越多的數據塊就增大了總的硬盤尋道時間。當硬盤尋道時間比io時間還要長的多時，那么硬盤尋道時間就成了系統的一個瓶頸。合適的塊大小有助于減少硬盤尋道時間，提高系統吞吐量。傳輸一個由多個塊的組成的文件取決于磁盤傳輸速率。如尋址時間約為10ms，傳輸速率為100MB/S，為了使尋址時間僅占傳輸時間的1%，塊的大小設置約為100MB，默認大小是64MB，現在在實際身纏中都是128MB了，隨著新一代磁盤去東區傳輸速率的提升，塊的大小將會被設置的更大。

減少Namenode內存消耗

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

Map崩潰問題：

系統需要重新啟動，啟動過程需要重新加載數據，數據塊越大，數據加載時間越長，系統恢復過程越長。

監管時間問題：

主節點監管其他節點的情況，每個節點會周期性的把完成的工作和狀態的更新報告回來。如果一個節點保持沉默超過一個預設的時間間隔，主節點記錄下這個節點狀態為死亡，并把分配給這個節點的數據發到別的節點。對于這個“預設的時間間隔”，這是從數據塊的角度大概估算的。假如是對于64MB的數據塊，我可以假設你10分鐘之內無論如何也能解決了吧，超過10分鐘也沒反應，那就是死了。可對于640MB或是1G以上的數據，我應該要估算個多長的時間內？估算的時間短了，那就誤判死亡了，分分鐘更壞的情況是所有節點都會被判死亡。估算的時間長了，那等待的時間就過長了。所以對于過大的數據塊，這個“預設的時間間隔”不好估算。

問題分解問題：

數據量大小是問題解決的復雜度是成線性關系的。對于同個算法，處理的數據量越大，它的時間復雜度也就越大。塊的大小太大的話，一個map任務處理一個塊，那任務數就變少了，作業運行速度也就變慢了。

約束Map輸出：

在Map Reduce框架里，Map之后的數據是要經過排序才執行Reduce操作的。想想歸并排序算法的思想，對小文件進行排序，然后將小文件歸并成大文件的思想

總結

以上是生活随笔為你收集整理的linux数据块的大小不一样,HDFS块大小默认为什么是64MB(或者是128MB）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。