HDFS架構
?NameNode
?DataNode
?Sencondary NameNode
數據存儲細節
NameNode 目錄結構
Namenode的目錄結構：
${dfs.name.dir}/current /VERSION
/edits
/fsimage
/fstime
dfs.name.dir是hdfs-site.xml里配置的若干個目錄組成的列表。
NameNode
Namenode上保存著HDFS的名字空間。對于任何對文件系統元數據產生修改的操作，Namenode都會使用一種稱為EditLog的事務日志記錄下來。例如，在HDFS中創建一個文件，Namenode就會在Editlog中插入一條記錄來表示；同樣地，修改文件的副本系數也將往Editlog插入一條記錄。Namenode在本地操作系統的文件系統中存儲這個Editlog。整個文件系統的名字空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱為FsImage的文件中，這個文件也是放在Namenode所在的本地文件系統上。
Namenode在內存中保存著整個文件系統的名字空間和文件數據塊映射(Blockmap)的映像。這個關鍵的元數據結構設計得很緊湊，因而一個有4G內存的Namenode足夠支撐大量的文件和目錄。當Namenode啟動時，它從硬盤中讀取Editlog和FsImage，將所有Editlog中的事務作用在內存中的FsImage上，并將這個新版本的FsImage從內存中保存到本地磁盤上，然后刪除舊的Editlog，因為這個舊的Editlog的事務都已經作用在FsImage上了。這個過程稱為一個檢查點(checkpoint)。在當前實現中，檢查點只發生在Namenode啟動時，在不久的將來將實現支持周期性的檢查點。
HDFS NameSpace
HDFS支持傳統的層次型文件組織結構。用戶或者應用程序可以創建目錄，然后將文件保存在這些目錄里。文件系統名字空間的層次結構和大多數現有的文件系統類似：用戶可以創建、刪除、移動或重命名文件。當前，HDFS不支持用戶磁盤配額和訪問權限控制，也不支持硬鏈接和軟鏈接。但是HDFS架構并不妨礙實現這些特性。
Namenode負責維護文件系統命名空間，任何對文件系統名字空間或屬性的修改都將被Namenode記錄下來。應用程序可以設置HDFS保存的文件的副本數目。文件副本的數目稱為文件的副本系數，這個信息也是由Namenode保存的。
DataNode
Datanode將HDFS數據以文件的形式存儲在本地的文件系統中，它并不知道有關HDFS文件的信息。它把每個HDFS數據塊存儲在本地文件系統的一個單獨的文件中。Datanode并不在同一個目錄創建所有的文件，實際上，它用試探的方法來確定每個目錄的最佳文件數目，并且在適當的時候創建子目錄。在同一個目錄中創建所有的本地文件并不是最優的選擇，這是因為本地文件系統可能無法高效地在單個目錄中支持大量的文件。
當一個Datanode啟動時，它會掃描本地文件系統，產生一個這些本地文件對應的所有HDFS數據塊的列表，然后作為報告發送到Namenode，這個報告就是塊狀態報告。
Secondary NameNode
Secondary NameNode定期合并fsimage和edits日志，將edits日志文件大小控制在一個限度下。
配置Secondary NameNode
??conf/masters文件指定的為Secondary NameNode節點
?修改在masters文件中配置了的機器上的conf/hdfs-site.xml文件，加上如下選項：
dfs.http.address namenode.hadoop-host.com:50070
?core-site.xml：這里有2個參數可配置，但一般來說我們不做修改。fs.checkpoint.period表示多長時間記錄一次hdfs的鏡像。默認是1小時。fs.checkpoint.size表示一次記錄多大的size，默認64M。
fs.checkpoint.period 3600 The number of seconds between two periodic checkpoints.
fs.checkpoint.size 67108864 The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn't expired.
Secondary NameNode
Secondary NameNode處理流程
(1)、namenode響應Secondary namenode請求，將edit log推送給Secondary namenode，開始重新寫一個新的edit log。
(2)、Secondary namenode收到來自namenode的fsimage文件和edit log。
(3)、Secondary namenode將fsimage加載到內存，應用edit log，并生成一個新的fsimage文件。
(4)、Secondary namenode將新的fsimage推送給Namenode。
(5)、Namenode用新的fsimage取代舊的fsimage，在fstime文件中記下檢查點發生的時
HDFS通信協議
所有的HDFS通訊協議都是構建在TCP/IP協議上?？蛻舳送ㄟ^一個可配置的端口連接到Namenode，通過ClientProtocol與Namenode交互。而Datanode是使用DatanodeProtocol與Namenode交互。再設計上，DataNode通過周期性的向NameNode發送心跳和數據塊來保持和NameNode的通信，數據塊報告的信息包括數據塊的屬性，即數據塊屬于哪個文件，數據塊ID，修改時間等，NameNode的DataNode和數據塊的映射關系就是通過系統啟動時DataNode的數據塊報告建立的。從ClientProtocol和Datanodeprotocol抽象出一個遠程調用(RPC），在設計上，Namenode不會主動發起RPC，而是是響應來自客戶端和Datanode的RPC請求。
HDFS的安全模式
Namenode啟動后會進入一個稱為安全模式的特殊狀態。處于安全模式的Namenode是不會進行數據塊的復制的。Namenode從所有的Datanode接收心跳信號和塊狀態報告。塊狀態報告包括了某個Datanode所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當Namenode檢測確認某個數據塊的副本數目達到這個最小值，那么該數據塊就會被認為是副本安全(safely replicated)的；在一定百分比（這個參數可配置）的數據塊被Namenode檢測確認是安全之后（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒有達到指定數目，并將這些數據塊復制到其他Datanode上。
第二部分：HDFS文件讀取的解析
文件讀取流程
流程分析
?使用HDFS提供的客戶端開發庫Client，向遠程的Namenode發起RPC請求；
??Namenode會視情況返回文件的部分或者全部block列表，對于每個block，Namenode都會返回有該block拷貝的DataNode地址；
?客戶端開發庫Client會選取離客戶端最接近的DataNode來讀取block；如果客戶端本身就是DataNode,那么將從本地直接獲取數據.
?讀取完當前block的數據后，關閉與當前的DataNode連接，并為讀取下一個block尋找最佳的DataNode；
?當讀完列表的block后，且文件讀取還沒有結束，客戶端開發庫會繼續向Namenode獲取下一批的block列表。
?讀取完一個block都會進行checksum驗證，如果讀取datanode時出現錯誤，客戶端會通知Namenode，然后再從下一個擁有該block拷貝的datanode繼續讀。
第三部分：HDFS文件寫入的解析
文件寫入流程
流程分析
?使用HDFS提供的客戶端開發庫Client，向遠程的Namenode發起RPC請求；
?Namenode會檢查要創建的文件是否已經存在，創建者是否有權限進行操作，成功則會為文件創建一個記錄，否則會讓客戶端拋出異常；
?當客戶端開始寫入文件的時候，會將文件切分成多個packets，并在內部以數據隊列"data queue"的形式管理這些packets，并向Namenode申請新的blocks，獲取用來存儲replicas的合適的datanodes列表，列表的大小根據在Namenode中對replication的設置而定。
?開始以pipeline（管道）的形式將packet寫入所有的replicas中。把packet以流的方式寫入第一個datanode，該datanode把該packet存儲之后，再將其傳遞給在此pipeline中的下一個datanode，直到最后一個datanode，這種寫數據的方式呈流水線的形式。
?最后一個datanode成功存儲之后會返回一個ack packet，在pipeline里傳遞至客戶端，在客戶端的開發庫內部維護著"ack queue"，成功收到datanode返回的ack packet后會從"ack queue"移除相應的packet。
?如果傳輸過程中，有某個datanode出現了故障，那么當前的pipeline會被關閉，出現故障的datanode會從當前的pipeline中移除，剩余的block會繼續剩下的datanode中繼續以pipeline的形式傳輸，同時Namenode會分配一個新的datanode，保持replicas設定的數量。
流水線復制
當客戶端向HDFS文件寫入數據的時候，一開始是寫到本地臨時文件中。假設該文件的副本系數設置為3，當本地臨時文件累積到一個數據塊的大小時，客戶端會從Namenode獲取一個Datanode列表用于存放副本。然后客戶端開始向第一個Datanode傳輸數據，第一個Datanode一小部分一小部分(4 KB)地接收數據，將每一部分寫入本地倉庫，并同時傳輸該部分到列表中第二個Datanode節點。第二個Datanode也是這樣，一小部分一小部分地接收數據，寫入本地倉庫，并同時傳給第三個Datanode。最后，第三個Datanode接收數據并存儲在本地。因此，Datanode能流水線式地從前一個節點接收數據，并在同時轉發給下一個節點，數據以流水線的方式從前一個Datanode復制到下一個
更細節的原理
客戶端創建文件的請求其實并沒有立即發送給Namenode，事實上，在剛開始階段HDFS客戶端會先將文件數據緩存到本地的一個臨時文件。應用程序的寫操作被透明地重定向到這個臨時文件。當這個臨時文件累積的數據量超過一個數據塊的大小，客戶端才會聯系Namenode。Namenode將文件名插入文件系統的層次結構中，并且分配一個數據塊給它。然后返回Datanode的標識符和目標數據塊給客戶端。接著客戶端將這塊數據從本地臨時文件上傳到指定的Datanode上。當文件關閉時，在臨時文件中剩余的沒有上傳的數據也會傳輸到指定的Datanode上。然后客戶端告訴Namenode文件已經關閉。此時Namenode才將文件創建操作提交到日志里進行存儲。如果Namenode在文件關閉前宕機了，則該文件將丟失。
第四部分：副本機制
特點
1.數據類型單一
2.副本數比較多
3.寫文件時副本的放置方法
4.動態的副本創建策略
5.弱化的副本一致性要求
副本擺放策略
修改副本數
1.集群只有三個Datanode，hadoop系統replication=4時，會出現什么情況？
對于上傳文件到hdfs上時，當時hadoop的副本系數是幾，這個文件的塊數副本數就會有幾份，無論以后你怎么更改系統副本系統，這個文件的副本數都不會改變，也就說上傳到分布式系統上的文件副本數由當時的系統副本數決定，不會受replication的更改而變化，除非用命令來更改文件的副本數。因為dfs.replication實質上是client參數，在create文件時可以指定具體replication，屬性dfs.replication是不指定具體replication時的采用默認備份數。文件上傳后，備份數已定，修改dfs.replication是不會影響以前的文件的，也不會影響后面指定備份數的文件。只影響后面采用默認備份數的文件。但可以利用hadoop提供的命令后期改某文件的備份數：hadoop fs -setrep -R 1。如果你是在hdfs-site.xml設置了dfs.replication，這并一定就得了，因為你可能沒把conf文件夾加入到你的 project的classpath里，你的程序運行時取的dfs.replication可能是hdfs-default.xml里的 dfs.replication，默認是3。可能這個就是造成你為什么dfs.replication老是3的原因。你可以試試在創建文件時，顯式設定replication。replication一般到3就可以了，大了意義也不大。
