hdfs: 一個分佈式文件系統(一)

一. hdfs設計的動機

爲大規模分佈式計算準備的分佈式文件系統，並不是實時性要求很高的文件系統。

二. 設計的取捨

1. 由於要求有高吞吐量，因此犧牲讀取文件的實時性，實時性要求高的分佈式文件系統能夠選擇hbase

2. 使用廉價的機器，因此任意一個存儲節點可能會掛掉，將之視爲hadoop的常態

3. 流式存儲，一次寫入，屢次讀取進行數據迭代，寫入也儘可能採起在文件的末尾進行追加的方式，在任意一處寫入數據的操做代價很高，儘可能不要作

4. 不鼓勵使用大量的小文件處理，每一個小文件都須要都有一個元數據來存儲這些小文件的信息，而且這些信息都存儲在namenode上，一條元數據大概是150K左右的大小，而namenode的容量是有限的

三. hdfs中的塊

       hdfs中的塊與普通文件系統中的塊（這裏是邏輯塊，不一樣於磁盤中的塊）的概念相似，都是文件系統可操做的最小單位，可是大小差異很大，常見的文件系統的塊一般爲磁盤塊大小（512字節）的整數倍，而hdfs中的塊默認大小爲64M

       hdfs的塊之因此那麼大，是爲了儘快尋址，而且hadoop中的不鼓勵處理小文件，而大小小於64M的文件會被單獨佔一個塊，只是這個塊的大小等於文件的大小，並非64M

hdfs中的塊很適合作備份，一般每一個塊都會有三個備份，而後存儲在不一樣的節點上，即便其中一個節點掛掉，仍然能夠找到備份的數據塊（如何將塊儘可能的比較均勻分佈在不一樣的節點上？）

四.namenode和datanode

namenode是管理者，datanode是執行者

namenode存儲着文件塊的位置、索引信息、namespace，這些信息在系統重啓時重建，還存儲操做日誌

datanode上存儲着具體的文件塊，而且在一個固定的時間段內（心跳），會向namenode報告本身的狀態和塊列表信息

若是namenode上的信息丟失，將是整個文件系統的災難，因此要有必定的機制來保證文件存儲的可靠性

hdfs通常經過兩個機制來保證可靠性：

a. 寫時copy:在namenode進行寫操做（原子操做）的同時，在向本地磁盤寫的同時，也會向網絡上的某個機器上寫一樣的內容，一般經過NFS完成

b. 鏡像備份：按期將namenode上的數據在另外一個機器上建立鏡像，進行備份，若是namenode出現問題，則經過鏡像進行恢復，缺點是仍然會損失一些數據

 

 

       從上述這張圖中，能夠看出，用戶寫文件並非通過namenode進行轉發，而是直接往datanode上寫,而後由datanode將本身節點上塊信息傳給namenode，這樣就避免了namenode成爲系統IO的瓶頸。

五. 常見hdfs命令

1. 見$hadoop fs -help  http://hadoop.apache.org/docs/r1.2.1/file_system_shell.html    閱讀幫助和文檔是最好的學習命令的方式

2. 修改~/.bashrc 映射經常使用命令