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;
<property>
<name>dfs.block.size</name>
<value>134217728</value>
</property>
定址時間:HDFS中找到目標檔案塊(block)所需要的時間。
原理:
檔案塊越大,定址時間越短,但磁碟傳輸時間越長;
檔案塊越小,定址時間越長,但磁碟傳輸時間越短。
1. 如果塊設定過大,
第一點: 從磁碟傳輸資料的時間會明顯大於定址時間,導致程式在處理這塊資料時,變得非常慢;
第二點: mapreduce中的map任務通常一次只處理一個塊中的資料,如果塊過大執行速度也會很慢。
第三點: 在資料讀寫計算的時候,需要進行網路傳輸.如果block過大會導致網路傳輸時間增長,程式卡頓/超時/無響應. 任務執行的過程中拉取其他節點的block或者失敗重試的成本會過高.
第四點: namenode監管容易判斷資料節點死亡.導致叢集頻繁產生/移除副本, 佔用cpu,網路,記憶體資源.
2. 如果塊設定過小,
第一點: 存放大量小檔案會佔用NameNode中大量記憶體來儲存後設資料,而NameNode的實體記憶體是有限的;
第二點: 檔案塊過小,定址時間增大,導致程式一直在找block的開始位置。
第三點: 作業系統對目錄中的小檔案處理存在效能問題.比如同一個目錄下檔案數量操作100萬,執行"fs -l "之類的命令會卡死.
第四點: ,則會頻繁的進行檔案傳輸,對嚴重佔用網路/CPU資源.
主要取決於磁碟/網路的傳輸速率。[其實就是CPU,磁碟,網路卡之間的協同效率 即 跨物理機/機架之間檔案傳輸速率]
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另行考慮.).
如果大家知道其他的原因或者問題 ,麻煩留言告知,不勝感激....
參考: