HDFS數據塊：
與一般文件系統一樣，HDFS也有塊（block）的概念，HDFS上的文件也被划分為塊大小的多個分塊作為獨立的存儲單元。
與通常的磁盤文件系統不同的是：
HDFS中小於一個塊大小的文件不會占據整個塊的空間（當一個1MB的文件存儲在一個128MB的塊中時，文件只使用1MB的磁盤空間，而不是128MB）
設置數據塊的好處：
（1）一個文件的大小可以大於集群任意節點磁盤的容量
（2）容易對數據進行備份，提高容錯能力
（3）使用抽象塊概念而非整個文件作為存儲單元，大大簡化存儲子系統的設計
---------------------
來源：CSDN
原文：https://blog.csdn.net/liu123641191/article/details/80727462
————————————————————————————————————————————————————
1、塊大小設置
在hdfs-site.xml中，增加全局參數dfs.block.size
<property>
<name>dfs.block.size</name>
<value>512000</value>
</property>
注意：blockSize必須是io.bytes.per.checksum的整數倍，否則會報錯
“put: io.bytes.per.checksum(512) and blockSize(100000) do not match. blockSize should be a multiple of io.bytes.per.checksum”
————————————————————————————————————————————————————————————
為什么不能遠少於64MB？
（1）減少硬盤尋道時間。HDFS設計前提是應對大數據量操作，若數據塊大小設置過小，那需要讀取的數據塊數量就會增多，從而間接增加底層硬盤的尋道時間
（2）減少NameNode內存消耗。由於NameNode記錄着DataNode中的數據塊信息，若數據塊大小設置過小，則數據塊數量增多，需要維護的數據塊信息就會增多，從而消耗NameNode的內存。
為什么不能遠大於64MB？
原因主要從上層的MapReduce框架來尋找。
（1）Map崩潰問題。系統需要重新啟動，啟動過程中需要重新加載數據，數據塊越大，數據加載時間越長，系統恢復過程越長
（2）監管時間問題。主節點監管其他節點的情況，每個節點會周期性的與主節點進行匯報通信。倘若某一個節點保持沉默的時間超過一個預設的時間間隔，主節點會記錄這個節點狀態為死亡，並將該節點的數據轉發給別的節點。而這個“預設時間間隔”是從數據塊的角度大致估算的。（加入對64MB的數據塊，我可以假設你10分鍾之內無論如何也能解決完了吧，超過10分鍾還沒反應，那我就認為你出故障或已經死了。）64MB大小的數據塊，其時間尚可較為精准地估計，如果我將數據塊大小設為640MB甚至上G，那這個“預設的時間間隔”便不好估算，估長估短對系統都會造成不必要的損失和資源浪費。
（3）問題分解問題。數據量的大小與問題解決的復雜度呈線性關系。對於同一個算法，處理的數據量越大，時間復雜度越高。
（4）約束Map輸出。在Map Reduce框架里，Map之后的數據是要經過排序才執行Reduce操作的。這通常涉及到歸並排序，而歸並排序的算法思想便是“對小文件進行排序，然后將小文件歸並成大文件”，因此“小文件”不宜過大。
HDFS的塊設置的如此之大主要還是為了減小尋址開銷的，《Hadoop權威指南》中有一段話：
“HDFS的塊比磁盤塊大，其目的是為了最小化尋址開銷。如果塊設置得足夠大，從磁盤傳輸數據的時間可以明顯大於定位這個塊開始位置所需的時間。這樣，傳輸一個由多個塊組成的文件的時間就取決於磁盤傳輸速率。”
“我們做一個估計計算，如果尋址時間為10ms左右，而傳輸速率為100MB/s，為了使尋址時間僅占傳輸時間的1%，我們需要設置塊大小為100MB左右。而默認的塊大小實際為64MB，但是很多情況下HDFS使用128MB的塊設置。以后隨着新一代磁盤驅動器傳輸速率的提升，塊的大小將被設置得更大。”
“但是，該參數也不會設置得過大。MapReduce中的map任務通常一次處理一個塊中的數據，因此，如果任務數太少（少於集群中的節點數量），作業的運行速度就會變慢。”
---------------------
來源：CSDN
原文：https://blog.csdn.net/liu123641191/article/details/80727462