一、HDFS介紹
1.1 背景
隨著資料量越來越大，在一個作業系統管轄的範圍存不下了，那麼就分配到更多的作業系統管理的磁碟中，但是不方便管理和維護，迫切需要一種系統來管理多臺機器上的檔案，這就是分散式檔案管理系統。
學術一點的定義就是：分散式檔案系統是一種允許檔案通過網路在多臺主機上分享的檔案的系統，可讓多機器上的多使用者分享檔案和儲存空間。分散式檔案管理系統很多，HDFS 只是其中一種。適用於一次寫入、多次查詢的情況，不支援併發寫情況，小檔案不合適。因為小檔案也佔用一個塊，小檔案越多（1000個1k檔案）塊越多，NameNode壓力越大。
1.2 HDFS是什麼
我們通過hadoop shell上傳的檔案是存放在DataNode的block中，通過linux shell是看不到檔案的，只能看到block。可以一句話描述HDFS：把客戶端的大檔案存放在很多節點的資料塊中。在這裡，出現了三個關鍵詞：檔案、節點、資料塊。HDFS就是圍繞著這三個關鍵詞設計的，我們在學習的時候也要緊抓住這三個關鍵詞來學習。
二、 HDFS的基本結構
2.1 NameNode
(1) 概述
NameNode的作用是管理檔案目錄結構，接受使用者的操作請求，是管理資料節點。名位元組點維護兩套資料：
① 檔案目錄與資料塊之間的關係。是靜態的，存放在磁碟上的，通過fsimage和edits檔案來維護。
② 資料塊與節點之間的關係。不持久放到到磁碟，每當叢集啟動的時候，會自動建立這些資訊，所以一般都放在記憶體中。
所以他是整個檔案系統的管理節點。它維護著整個檔案系統的檔案目錄樹，檔案/目錄的元資訊和每個檔案對應的資料塊列表，接收使用者的操作請求。
檔案包括：
① fsimage（檔案系統映象）:後設資料映象檔案。儲存某一時段NameNode記憶體後設資料資訊。
② edits:操作日誌檔案。
③ fstime:儲存最近一次checkpoint的時間
以上這些檔案是儲存在linux的檔案系統中
(2) 特點
是一種允許檔案網路在多臺主機上分享的檔案系統，可讓多機器上的多使用者分享檔案和儲存空間。
① 通透性。讓實際上是通過網路來訪問檔案的動作，由程式與使用者看來，就像是訪問本地的磁碟一般。
② 容錯。即使系統中有某些節點離線，整體來說系統仍然可以持續運作而不會有資料損失。
③ 適用於一次寫入、多次查詢的情況，不支援併發寫情況，小檔案不合適
(3) 目錄結構
a) 既然NameNode維護這麼多的資訊,那麼這些資訊都存放在哪裡呢?
在hadoop原始碼中有個檔案叫做hdfs-default.xml，如圖3.1所示。
圖 3.1
b) 開啟這個檔案
在第149行和第158行，有兩個配置資訊，一個是dfs.name.dir，另一個是dfs.name.edits.dir。這兩個檔案表示的是NameNode的核心檔案fsimage和edits的存放位置，如圖3.2所示。
圖 3.2
在對應配置的value值有${}，這是變數的表示方式，ER表示式，在程式讀取檔案時，會把變數的值讀取出來。那麼，第150行的變數hadoop.tmp.dir的值(即hadoop臨時儲存路徑)，如圖3.3所示。
圖 3.3
但是在我們在上一章的配置檔案core-site.xml中，配置的值是/usr/local/hadoop/tmp。
c) 我們可以進入linux檔案系統
執行命令 cd /usr/local/hadoop/conf,more core-site.xml檢視到如圖3.3所示的內容。
圖 3.4
可以看出，這兩個檔案的儲存位置是在linux檔案系統的/usr/local/hadoop/tmp/dfs/name目錄下。
d) 我們進入這個目錄
檢視這個目錄的內容，如圖3.5所示。
圖 3.5
從圖中可知，NameNode的核心檔案fsimage和edits的存放在current目錄下，與此同時name目錄下有一個檔案in_use.lock而檢視其內容的時候發現，內容為空，也就是說只能有一個Namenode程式能夠訪問該目錄，讀者可以自己試一下，當沒有開啟hadoop時，該目錄下是沒有檔案in_use.lock 的，當hadoop啟動以後才會生成該檔案。
e) 檔案fsimage件
這個檔案非常重要，丟失的話，Namenode無法使用，那麼如何防止該檔案丟失而造成不良後果呢。我可以下再次看一下hdfs-default.xml中的一段程式碼如圖3.6所示。
圖 3.6
由其中的描述可知，該變數，決定DFS NameNode 的NameTable(fsimage)應該在本地檔案系統上的儲存位置。如果這是一個用逗號分隔的列表的目錄，那麼nametable，會被複複製到所有的目錄中,來冗餘（備份來保證資料的安全性）。如${hadoop.tmp.dir}/dfs/name，~/name2，~/name3，~/name4。那麼fsimage會分別複製到~/name1，~/name2，~/name3，~/name4目錄中。所以這些目錄一般是在不同的機器,不同的磁碟，不同的資料夾上，總之越分散越好，這樣能保證資料的安全性。有人會問在多臺機上怎麼實現呢？其實在Linux中有nfs檔案共享系統，這裡不做詳述。
f) 看一下edits的描述
檢視一下hdfs-default.xml中的一段程式碼如圖3.7所示
圖 3.7
由其中的描述可知，該變數，決定DFSNameNode的儲存事務檔案（edits）在本地檔案系統上的位置。如果這是一個以逗號分隔的目錄列表，那麼，事務檔案會被複制所有的目錄中,來冗餘。預設值是dfs.name.dir一樣。（edit儲存事務過程）
2.2 DataNode
(1) 概述
DataNode的作用是HDFS中真正儲存資料的。
(2) block
① 如果一個檔案非常大，比如100GB，那麼怎麼儲存在DataNode中呢？DataNode在儲存資料的時候是按照block為單位讀寫資料的。block是hdfs讀寫資料的基本單位。
② 假設檔案大小是100GB，從位元組位置0開始，每64MB位元組劃分為一個block，依此類推，可以劃分出很多的block。每個block就是64MB大小。
a) 我們看一下org.apache.hadoop.hdfs.protocol.Block類，這裡面的屬性有以下幾個，如圖4.1所示。
圖4.1
由上圖可知，類中的屬性沒有一個是可以儲存資料的。 所以block本質上是一個邏輯概念，意味著block裡面不會真正的儲存資料，只是劃分檔案的。
b) 為什麼一定要劃分為64MB大小呢？
因為這是在預設配置檔案中設定的，我們檢視core-default.xml檔案，如圖4.2所示。
圖4.2
上圖中的引數ds.block.name指的就是block的大小，值是67 108 864位元組，可以換算為64MB。如果我們不希望使用64MB大小，可以在core-site.xml中覆蓋該值。注意單位是位元組。
(3) 副本
a) 副本就是備份，目的當時是為了安全。正是因為叢集環境的不可靠，所以才使用副本機制來保證資料的安全性。
b) 副本的缺點就是會佔用大量的儲存空間。副本越多，佔用的空間越多。相比資料丟失的風險，儲存空間的花費還是值得的。
c) 那麼，一個檔案有幾個副本合適呢？我們檢視hdfs-default.xml檔案，如圖4.3所示。
圖4.3
從圖4.3中可以看到，預設的副本數量是3。意味著HDFS中的每個資料塊都有3份。當然，每一份肯定會盡力分配在不同的DataNode伺服器中。試想：如果備份的3份資料都在同一臺伺服器上，那麼這臺伺服器停機了，是不是所有的資料都丟了啊？
(4) 目錄結構
a) DataNode是按block來劃分檔案的
那麼劃分後的檔案到底存放在哪裡哪？我們檢視檔案core-default.xml，如圖4.4所示。
圖4.4
引數dfs.data.dir的值就是block存放在linux檔案系統中的位置。變數hadoop.tmp.dir的值前面已經介紹了，是/usr/local/hadoop/tmp，那麼dfs.data.dir的完整路徑是/usr/local/hadoop/tmp/dfs/data。通過linux命令檢視，結果如圖4.5所示。
b) 上傳一個檔案
我們首先點選PieTTY開啟另一個Linux終端，上傳一個檔案 jdk-6u24-linux-i586.bin，檔案大小為 84927175k，如圖4.5所示。
圖4-5
然後我們可以在原來終端，檢視上傳檔案，就是在該Linux檔案系統的/usr/local/hadoop/tmp/dfs/data目錄下，如圖4.6所示
圖 4.6
上圖中以“blk_”開頭的檔案就是儲存資料的block。這裡的命名是有規律的，除了block檔案外，還有字尾是“meta”的檔案，這是block的源資料檔案，存放一些後設資料資訊。因此，上圖中只有2個block檔案。
注意：我們從linux磁碟上傳一個完整的檔案到hdfs中，這個檔案在linux是可以看到的，但是上傳到hdfs後，就不會有一個對應的檔案存在，而是被劃分成很多的block存在的。而且由於我們的hadoop安裝方式是偽分佈安裝，只有一個節點，DataNode和NameNode都在這一個節點上，所以上傳的block塊最終還是在該Linux系統中。
2.3 SecondaryNameNode
HA的一個解決方案。但不支援熱備。配置即可。由於資料操作越多edits檔案膨脹越大，但不能讓他無限的膨脹下去，所以要把日誌過程轉換出來放到fsimage中。由於NameNode要接受使用者的操作請求，必須能夠快速響應使用者請求，為了保證NameNode的快速響應給使用者，所以將此項工作交給了SecondaryNode，所以他也備份一部分fsimage的一部分內容。
執行過程：從NameNode上下載後設資料資訊（fsimage,edits），然後把二者合併，生成新的fsimage，在本地儲存，並將其推送到NameNode，同時重置NameNode的edits.預設在安裝在NameNode節點上，但這樣...不安全！
合併原理如圖5.1所示。
圖 5.1