hdfs: 數據流（二）

大部分的HDFS程序對文件操做須要的是一次寫屢次讀取的操做模式。

一個文件一旦建立、寫入、關閉以後就不須要修改了。這個假定簡單化了數據一致的問題和並使高吞吐量的數據訪問變得可能。

1. 讀文件

從上圖能夠看出，客戶端讀取數據時，

首先從namenode獲取以下信息（這些元數據信息是在內存中，因此查詢速度很快，這個過程對客戶端是透明的）：

a. 該文件有哪些數據塊

b.這些數據塊都放在哪裏或者說是取哪一個節點上的什麼數據塊

而後，客戶端直接從datanode中以文件流的方式讀取數據

最後，關閉這個文件流

一個問題：由於每一個數據塊都有三個備份，那麼取哪一個比較好？

選取讀取代價最小的節點，首先會在同一個節點中選取（若是客戶端也是datanode時），其次在同一個機架上的datanode中選取，最後再同一個機房中選取

hadoop會根據網絡拓撲給每個冗餘數據塊打分，原則就是考慮是否在同一個節點上，是否在相同的機架上，是否在同一個機房（目前hadoop不能跨機房部署）

2. 寫文件

首先，客戶端通知namenode：我要寫文件了，確認客戶端權限和沒有相同的文件後，namenode建立一個新的文件記錄

而後，將文件分紅一個一個的數據塊（默認大小是64M），經過文件流的方式往datanode中寫數據，寫數據時注意是會寫冗餘數據，冗餘數據塊的個數默認是3個

最後，只有冗餘數據塊所有寫完，datanode再向客戶端發出確認，而後客戶端向namenode發出結束消息，並將文件的塊信息存儲在namenode中

一個問題：如何選datanode用來存儲冗餘數據塊

這是一個權衡的問題：備份的可靠性，網絡IO的代價，其實若是都存在不一樣的機房，這樣的可靠性最高，可是網絡IO的代價就會很高，由於跨機房的網絡IO代價很大，若是都存儲在一個節點上，則不須要網絡IO，可是數據可靠性就會打折扣

因此hadoop默認的佈局策略是：第一個隨機在機房中選擇一個負載較小的節點，而後在不一樣的機架上（例如選擇了機架A）選擇一個節點，再在相同的機架上隨機選擇一個節點（仍是在機架A上）