Table of Contents
一.前言
二. block 大小設置原則：最小化尋址開銷,減少網絡傳輸.
三、為什麼HDFS中塊（block）不能設置太大，也不能設置太小？
四、 HDFS中塊（block）的大小為什麼設置為128M？
一.前言
HDFS中存儲數據是以塊（block，這只是一個邏輯概念）的形式存儲在DataNode，block大小可通過設置HADOOP_HOME/etc/hadoop/hdfs-site.xml中dfs.blocksize實現（設置時先stop集群，修改完restart集群）。在Hadoop2.x之後的版本中，文件塊的默認大小是128M，老版本中默認是64M；
二. block 大小設置原則：最小化尋址開銷,減少網絡傳輸.
減少硬碟尋道時間(disk seek time)：HDFS的設計是為了支持大數據操作，合適的block大小有助於減少硬碟尋道時間（平衡了硬碟尋道時間、IO時間），提高系統吞吐量。
減少NameNode內存消耗：NameNode需要在內存FSImage文件中記錄DataNode中數據塊信息，若block size太小，那麼需要維護的數據塊信息會更多。而HDFS只有一個NameNode節點，內存是極其有限的。
map崩潰問題：若Map任務崩潰，重新啟動執行需要重新加載數據，數據塊越大，數據加載時間將越長，恢復時間越長。
監管時間問題：主節點監管其他節點的情況，每個節點會周期性的把完成的工作和狀態的更新報告回來。若某個節點保存沉默超過預設的時間間隔，主節點「宣告」該節點狀態為死亡，並把分配給這個節點的數據發到別的節點。預設的時間間隔是根據數據塊 size角度估算的，若size設置不合理，容易誤判節點死亡。
約束Map任務輸出：MapReduce框架中Map任務輸出的結果是要經過排序才給reduce函數操作的。在Map任務的merge on disk和Reduce任務中合併溢寫生的文件，用到歸併排序算法，對小文件進行排序，然後將小文件歸併成大文件。
網絡傳輸問題: 在數據讀寫計算的時候,需要進行網絡傳輸.如果block過大會導致網絡傳輸時間增長,程序卡頓/超時/無響應. 任務執行的過程中拉取其他節點的block或者失敗重試的成本會過高.如果block過小,則會頻繁的進行文件傳輸,對嚴重佔用網絡/CPU資源.
三、為什麼HDFS中塊（block）不能設置太大，也不能設置太小？
1. 如果塊設置過大，
第一點: 從磁碟傳輸數據的時間會明顯大於尋址時間，導致程序在處理這塊數據時，變得非常慢；
第二點: mapreduce中的map任務通常一次只處理一個塊中的數據，如果塊過大運行速度也會很慢。
第三點: 在數據讀寫計算的時候,需要進行網絡傳輸.如果block過大會導致網絡傳輸時間增長,程序卡頓/超時/無響應. 任務執行的過程中拉取其他節點的block或者失敗重試的成本會過高.
第四點: namenode監管容易判斷數據節點死亡.導致集群頻繁產生/移除副本, 佔用cpu,網絡,內存資源.
2. 如果塊設置過小，
第一點: 存放大量小文件會佔用NameNode中大量內存來存儲元數據，而NameNode的物理內存是有限的；
第二點: 文件塊過小，尋址時間增大，導致程序一直在找block的開始位置。
第三點: 作業系統對目錄中的小文件處理存在性能問題.比如同一個目錄下文件數量操作100萬,執行"fs -l "之類的命令會卡死.
第四點: ,則會頻繁的進行文件傳輸,對嚴重佔用網絡/CPU資源.
主要取決於磁碟/網絡的傳輸速率。[其實就是CPU,磁碟,網卡之間的協同效率 即 跨物理機/機架之間文件傳輸速率]
四、 HDFS中塊（block）的大小為什麼設置為128M？
1. HDFS中平均尋址時間大概為10ms；
2. 經過測試發現，尋址時間為傳輸時間的1%時，為最佳狀態；
所以最佳傳輸時間為10ms/0.01=1000ms=1s
3. 目前磁碟的傳輸速率普遍為100MB/s , 網卡普遍為千兆網卡傳輸速率普遍也是100MB/s；
計算出最佳block大小：100MB/s x 1s = 100MB
所以我們設定block大小為128MB。
4. 實際在工業生產中，需要經過集群之間的具體情況進行設置.
比如: 跨物理機/機架之間文件傳輸速率為200MB/s時，一般設定block大小為256MB , 文件傳輸速率為400MB/s時，一般設定block大小為512MB . 不過最大一般不會超過512MB , 因為目前固態硬碟的讀寫速率應該不會超過512MB(如果做RAID另行考慮.).
如果大家知道其他的原因或者問題 ,麻煩留言告知,不勝感激....
參考:
------------END-----------