HDFS常見問題

在HDFS裏面，data node上的塊大小默認是64MB(或者是128MB或256MB)

問題: 爲何64MB(或128MB或256MB)是最優選擇？

爲何不能遠少於64MB(或128MB或256MB) （普通文件系統的數據塊大小通常爲4KB）

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

HDFS設計前提是支持大容量的流式數據操做，因此即便是通常的數據讀寫操做，涉及到的數據量都是比較大的。假如數據塊設置過少，那須要讀取的數據塊就比較多，因爲數據塊在硬盤上非連續存儲，普通硬盤由於須要移動磁頭，因此隨機尋址較慢，讀越多的數據塊就增大了總的硬盤尋道時間。當硬盤尋道時間比io時間還要長的多時，那麼硬盤尋道時間就成了系統的一個瓶頸。合適的塊大小有助於減小硬盤尋道時間，提升系統吞吐量。

2)減小Namenode內存消耗

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

爲何不能遠大於64MB(或128MB或256MB)

這裏主要從上層的MapReduce框架來討論

1)Map崩潰問題：

系統須要從新啓動，啓動過程須要從新加載數據，數據塊越大，數據加載時間越長，系統恢復過程越長。

2)監管時間問題：

主節點監管其餘節點的狀況，每一個節點會週期性的把完成的工做和狀態的更新報告回來。若是一個節點保持沉默超過一個預設的時間間隔，主節點記錄下這個節點狀態爲死亡，並把分配給這個節點的數據發到別的節點。對於這個「預設的時間間隔」，這是從數據塊的角度大概估算的。假如是對於64MB的數據塊，我能夠假設你10分鐘以內不管如何也能解決了吧，超過10分鐘也沒反應，那就是死了。可對於640MB或是1G以上的數據，我應該要估算個多長的時間內？估算的時間短了，那就誤判死亡了，分分鐘更壞的狀況是全部節點都會被判死亡。估算的時間長了，那等待的時間就過長了。因此對於過大的數據塊，這個「預設的時間間隔」很差估算。

3)問題分解問題：

數據量大小是問題解決的複雜度是成線性關係的。對於同個算法，處理的數據量越大，它的時間複雜度也就越大。

4)約束Map輸出：

在Map Reduce框架裏，Map以後的數據是要通過排序才執行Reduce操做的。想一想歸併排序算法的思想，對小文件進行排序，而後將小文件歸併成大文件的思想，而後就會懂這點了....

HDFS默認三個備份

因爲hadoop的HDFS對數據文件的分佈式存放是按照分塊block存儲，每一個block會有多個副本(默認爲3)，而且爲了數據的安全和高效，因此hadoop默認對3個副本的存放策略爲：

第一個block副本放在和client所在的node裏（若是client不在集羣範圍內，則這第一個node是隨機選取的）。

第二個副本放置在與第一個節點不一樣的機架中的node中（隨機選擇）。

第三個副本彷佛放置在與第一個副本所在節點同一機架的另外一個節點上

若是還有更多的副本就隨機放在集羣的node裏。

這樣的策略能夠保證對該block所屬文件的訪問可以優先在本rack下找到，若是整個rack發生了異常，也能夠在另外的rack上找到該block的副本。這樣足夠的高效，而且同時作到了數據的容錯。

可是，hadoop對機架的感知並不是是自適應的，亦即，hadoop集羣分辨某臺slave機器是屬於哪一個rack並不是是隻能的感知的，而是須要hadoop的管理者人爲的告知hadoop哪臺機器屬於哪一個rack，這樣在hadoop的namenode啓動初始化時，會將這些機器與rack的對應信息保存在內存中，用來做爲對接下來全部的HDFS的寫塊操做分配datanode列表時（好比3個block對應三臺datanode）的選擇datanode策略，作到hadoop allocate block的策略：儘可能將三個副本分佈到不一樣的rack。