.前期準備工作
1：安裝protobuf（其版本只能是2.5，高了不行）
windows下
下載protobuf：https://github.com/google/protobuf/releases，選擇protoc-xxx-win32.zip下載
將解壓出來的protoc.exe放在一全英文路徑下，并把其路徑名放在windows環境變量下的path下
打開命令窗口，輸入protoc --version，若顯示出了protoc的版本號，則安裝成功。
Linux環境
下載protobuf：https://github.com/google/protobuf/releases，選擇Linux版本下載。
解壓安裝包，并將其路徑加入到環境變量，即/etc/profile文件中。
進入protobuf目錄（我是將其解壓在/home/dev/目錄下的），依次執行以下命令
./configure --prefix=/home/dev/protobuf-2.5.0
make
make check
make install
ldconfig
添加環境變量：vi /etc/profile，添加如下，
# (動態庫搜索路徑) 程序加載運行期間查找動態鏈接庫時指定除了系統默認路徑之外的其他路徑export
export PATH=$PATH:$PROTOCOL_HOME:/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/dev/protobuf-2.5.0/lib
export LIBRARY_PATH=$LIBRARY_PATH:/home/dev/protobuf-2.5.0/lib
source /etc/profile，使其生效，最后在終端輸入 protoc --version，此處與windows類似。
安裝成功會顯示版本號，如下圖（以windows為例）：
2.安裝maven
maven安裝方式可參照下面連接，方法也就是將其安裝路徑加入環境變量。
windows：https://jingyan.baidu.com/article/3065b3b6a00792becef8a46c.html
Linux：https://www.cnblogs.com/jimmy-muyuan/p/7895933.html
二：編譯
1.首先在Hadoop官網下載Hadoop源碼，然后將其解壓在一個全英文目錄。
2.修改項目根目錄（hadoop-3.0.0-src目錄）下的pom.xml文件，將snapshot依賴注釋或者刪除（在190行）。不然會導致在編譯過程中出現無法找到依賴而導致編譯失敗。
3.進入到hadoop-maven-plugins目錄下，輸入mvn install，然后進入hadoop-3.0.0-src目錄下，輸入mvn eclipse:eclipse –DskipTests，此過程會下載很多依賴，會很慢，若編譯成功出現如下。
四.將項目導入到Eclipse
打開Eclipse，按照下列步驟：import-->general-->Existing Projects into Workspace-->next-->select root directory-->選擇Hadoop-3.0.0-src文件-->finish即可。
不過導入進來會有一些錯誤，需要解決。。。
隨著全球經濟的不斷發展，大數據時代早已悄悄到來，而Hadoop又是大數據環境的基礎，想入門大數據行業首先需要了解Hadoop的知識。2017年年初apache發行了Hadoop3.0，也意味著一直有一群人在對Hadoop不斷的做優化，不僅如此，各個Hadoop的商業版本也有好多公司正在使用，這也印證了它的商業價值。
讀者可以通過閱讀“一文讀懂Hadoop”系列文章，對Hadoop技術有個全面的了解，它涵蓋了Hadoop官網的所有知識點，并且通俗易懂，英文不好的讀者完全可以通過閱讀此篇文章了解Hadoop。
本期獨家內容“一文讀懂Hadoop”系列文章將根據先介紹Hadoop，繼而分別詳細介紹HDFS、MAPREDUCE、YARN的所有知識點的框架，分為四期內容在近幾天推送。敬請關注后續內容。
本期內容為大家詳解HDFS，由于字數限制，本文分為上下兩篇分別在頭條和二條推送。
1. HDFS優缺點
1.1 優點
1.1.1 高容錯性
可以由數百或數千個服務器機器組成，每個服務器機器存儲文件系統數據的一部分；
數據自動保存多個副本；
副本丟失后檢測故障快速，自動恢復。
1.1.2 適合批處理
移動計算而非數據；
數據位置暴露給計算框架；
數據訪問的高吞吐量；
運行的應用程序對其數據集進行流式訪問。
1.1.3 適合大數據處理
典型文件大小為千兆字節到太字節；
支持單個實例中的數千萬個文件；
10K+節點。
1.1.4 可構建在廉價的機器上
通過多副本提高可靠性；
提供了容錯與恢復機制。
1.1.5 跨異構硬件和軟件平臺的可移植性強
輕松地從一個平臺移植到另一個平臺。
1.1.6 簡單一致性模型
應用程序需要一次寫入多次讀取文件的訪問模型；
除了追加和截斷之外，不需要更改已創建，寫入和關閉的文件；
簡化了數據一致性問題，并實現了高吞吐量數據訪問；
高度可配置，具有非常適合于許多安裝的默認配置。大多數時候，只需要為非常大的集群調整配置。
1.2 缺點
1.2.1 不適合低延遲的數據訪問
HDFS設計更多的是批處理，而不是用戶交互使用。重點在于數據訪問的高吞吐量，而不是數據訪問的低延遲。
1.2.2 不適合小文件存取
占用NameNode大量內存；
尋道時間超過讀取時間。
1.2.3 無法并發寫入、文件隨即修改
一個文件只能有一個寫者；
僅支持追加和截斷。
2. 基本組成
2.1 Namenode
2.1.1 接受客戶端的讀寫服務
執行文件系統命名空間操作，如打開，關閉和重命名文件和目錄。
2.1.2 管理文件系統命名空間
記錄對文件系統命名空間或其屬性的任何更改。
2.1.3 metadata組成
Metadata是存儲在Namenode上的元數據信息，它存儲到磁盤的文件名為：fsimage。并且有個叫edits的文件記錄對metadata的操作日志。總體來說，fsimage與edits文件記錄了Metadata中的權限信息和文件系統目錄樹、文件包含哪些塊、確定塊到DataNode的映射、Block存放在哪些DataNode上(由DataNode啟動時上報)。
NameNode將這些信息加載到內存并進行拼裝，就成為了一個完整的元數據信息。
2.1.4 文件系統命名空間
HDFS支持傳統的分層文件組織。用戶或應用程序可以在這些目錄中創建目錄和存儲文件。文件系統命名空間層次結構與大多數其他現有文件系統類似：可以創建和刪除文件，將文件從一個目錄移動到另一個目錄，或重命名文件。HDFS支持用戶配額和訪問權限。但不支持硬鏈接或軟鏈接。
NameNode維護文件系統命名空間。對文件系統命名空間或其屬性的任何更改由NameNode記錄。應用程序可以指定應由HDFS維護的文件的副本數。文件的副本數稱為該文件的復制因子。此信息由NameNode存儲。
2.1.5 文件系統元數據的持久性
NameNode的metadata信息在啟動后會加載到內存，由于加載到內存的數據很不安全，斷電后就沒有了，因此必須對內存中存放的信息做持久化處理。
Namenode上保存著HDFS的命名空間。對于任何對文件系統元數據產生修改的操作，Namenode都會使用一種稱為Edits的事務日志記錄下來。例如，在HDFS中創建一個文件，Namenode就會在Edits中插入一條記錄來表示；同樣地，修改文件的副本系數也將往Edits插入一條記錄。Namenode在本地操作系統的文件系統中存儲這個Edits。整個文件系統的命名空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱為FsImage的文件中，這個文件也是放在Namenode所在的本地文件系統上。
Namenode在內存中保存著整個文件系統的命名空間和文件數據塊映射(Blockmap)的映像。這個關鍵的元數據結構設計得很緊湊，因而一個有4G內存的Namenode足夠支撐大量的文件和目錄。當Namenode啟動時，它從硬盤中讀取Edits和FsImage，將所有Edits中的事務作用在內存中的FsImage上，并將這個新版本的FsImage從內存中保存到本地磁盤上，然后刪除舊的Edits，因為這個舊的Edits的事務都已經作用在FsImage上了。這個過程稱為一個檢查點(checkpoint)。
Datanode將HDFS數據以文件的形式存儲在本地的文件系統中，它并不知道有關HDFS文件的信息。它把每個HDFS數據塊存儲在本地文件系統的一個單獨的文件中。Datanode并不在同一個目錄創建所有的文件，實際上，它用試探的方法來確定每個目錄的最佳文件數目，并且在適當的時候創建子目錄。在同一個目錄中創建所有的本地文件并不是最優的選擇，這是因為本地文件系統可能無法高效地在單個目錄中支持大量的文件。當一個Datanode啟動時，它會掃描本地文件系統，產生一個這些本地文件對應的所有HDFS數據塊的列表，然后作為報告發送到Namenode，這個報告就是塊狀態報告。
2.2 SecondaryNameNode
它不是NameNode的備份，但可以作為NameNode的備份，當因為斷電或服務器損壞的情況，可以用SecondNameNode中已合并的fsimage文件作為備份文件恢復到NameNode上，但是很有可能丟失掉在合并過程中新生成的edits信息。因此不是完全的備份。
由于NameNode僅在啟動期間合并fsimage和edits文件，因此在繁忙的群集上，edits日志文件可能會隨時間變得非常大。較大編輯文件的另一個副作用是下一次重新啟動NameNode需要更長時間。SecondNameNode的主要功能是幫助NameNode合并edits和fsimage文件，從而減少NameNode啟動時間。
2.2.1 SNN執行合并時機
根據配置文件配置的時間間隔fs.checkpoint.period默認1小時；
dfs.namenode.checkpoint.txns，默認設置為1百萬，也就是Edits中的事務條數達到1百萬就會觸發一次合并，即使未達到檢查點期間。
2.2.2 SNN合并流程
首先生成一個名叫edits.new的文件用于記錄合并過程中產生的日志信息；
當觸發到某一時機時（時間間隔達到1小時或Edits中的事務條數達到1百萬）時SecondaryNamenode將edits文件、與fsimage文件從NameNode上讀取到SecondNamenode上；
將edits文件與fsimage進行合并操作，合并成一個fsimage.ckpt文件；
將生成的合并后的文件fsimage.ckpt文件轉換到NameNode上；
將fsimage.ckpt在NameNode上變成fsimage文件替換NameNode上原有的fsimage文件，并將edits.new文件上變成edits文件替換NameNode上原有的edits文件。
SNN在hadoop2.x及以上版本在非高可用狀態時還存在，但是在hadoop2.x及以上版本高可用狀態下SNN就不存在了，在hadoop2.x及以上版本在高可用狀態下，處于standby狀態的NameNode來做合并操作。
2.3 DataNode
管理附加到它們運行的節點的存儲，并允許用戶數據存儲在文件中；
在內部，文件被分割成一個或多個塊（Block），并且這些塊被存儲在一組DataNode中；
負責提供來自文件系統客戶端的讀取和寫入請求；
執行塊創建，刪除；
啟動DN進程的時候會向NN匯報Block信息；
通過向NN發送心跳保持與其聯系（3秒一次），如果NN10分鐘沒有收到DN的心跳，則認為DN已經丟失，并且復制其上的Block到其他的DN上。
2.3.1 HDFS存儲單元（block）
2.3.1.1文件被切分成固定大小的數據塊
默認數據塊大小為64MB（hadoop1.x）、128MB（hadoop2.x）、256MB(hadoop3.x)，可配置；
若文件大小不到一個塊大小，則單獨存成一個block，block塊是一個邏輯意義上的概念。文件大小是多少，就占多少空間。
2.3.1.2 一個文件存儲方式
按大小被切分成不同的block，存儲到不同的節點上；
默認情況下，每個block都有3個副本；
block大小與副本數通過client端上傳文件時設置，文件上傳成功后副本數可以變更，block size不可變更。
2.3.1.3 設計思想
將大文件拆分成256MB的block塊，每個block塊分別隨機存放在不同的節點上，從而避免了數據傾斜的問題，但是在開發過程中，如果算法、程序寫的不好，同樣也會出現數據傾斜的問題。
2.3.2 數據復制
2.3.2.1 數據復制概述
HDFS被設計成能夠在一個大集群中跨機器可靠地存儲超大文件。它將每個文件存儲成一系列的數據塊，除了最后一個，所有的數據塊都是同樣大小的。為了容錯，文件的所有數據塊都會有副本。每個文件的數據塊大小和副本系數都是可配置的。應用程序可以指定某個文件的副本數目。副本系數可以在文件創建的時候指定，也可以在之后改變。HDFS中的文件都是一次性寫入的，并且嚴格要求在任何時候只能有一個寫入者。
Namenode全權管理數據塊的復制，它周期性地從集群中的每個Datanode接收心跳信號和塊狀態報告(Blockreport)。接收到心跳信號意味著該Datanode節點工作正常。塊狀態報告包含了一個該Datanode上所有數據塊的列表。
HDFS數據節點
2.3.2.2 Block的副本放置策略
副本的存放是HDFS可靠性和性能的關鍵。優化的副本存放策略是HDFS區分于其他大部分分布式文件系統的重要特性。這種特性需要做大量的調優，并需要經驗的積累。HDFS采用一種稱為機架感知(rack-aware)的策略來改進數據的可靠性、可用性和網絡帶寬的利用率。目前實現的副本存放策略只是在這個方向上的第一步。實現這個策略的短期目標是驗證它在生產環境下的有效性，觀察它的行為，為實現更先進的策略打下測試和研究的基礎。
大型HDFS實例一般運行在跨越多個機架的計算機組成的集群上，不同機架上的兩臺機器之間的通訊需要經過交換機。在大多數情況下，同一個機架內的兩臺機器間的帶寬會比不同機架的兩臺機器間的帶寬大。
通過一個機架感知的過程，Namenode可以確定每個Datanode所屬的機架id。一個簡單但沒有優化的策略就是將副本存放在不同的機架上。這樣可以有效防止當整個機架失效時數據的丟失，并且允許讀數據的時候充分利用多個機架的帶寬。這種策略設置可以將副本均勻分布在集群中，有利于當組件失效情況下的負載均衡。但是，因為這種策略的一個寫操作需要傳輸數據塊到多個機架，這增加了寫的代價。
在大多數情況下，副本系數是3，HDFS的存放策略是將一個副本存放在本地機架的節點上，一個副本放在同一機架的另一個節點上，最后一個副本放在不同機架的節點上。這種策略減少了機架間的數據傳輸，這就提高了寫操作的效率。機架的錯誤遠遠比節點的錯誤少，所以這個策略不會影響到數據的可靠性和可用性。于此同時，因為數據塊只放在兩個（不是三個）不同的機架上，所以此策略減少了讀取數據時需要的網絡傳輸總帶寬。在這種策略下，副本并不是均勻分布在不同的機架上。三分之一的副本在一個節點上，三分之二的副本在一個機架上，其他副本均勻分布在剩下的機架中，這一策略在不損害數據可靠性和讀取性能的情況下改進了寫的性能。
2.3.2.3 副本選擇
為了降低整體的帶寬消耗和讀取延時，HDFS會盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個機架上有一個副本，那么就讀取該副本。如果一個HDFS集群跨越多個數據中心，那么客戶端也將首先讀本地數據中心的副本。
2.3.2.4 安全模式
NameNode在啟動的時候會進入一個稱為安全模式的特殊狀態，它首先將映像文件（fsimage）載入內存，并執行編輯日志（edits）中的各項操作；
一旦在內存中成功建立文件系統元數據映射，則創建一個新的fsimage文件（這個操作不需要SecondNameNode來做）與一個空的編輯日志；
此刻namenode運行在安全模式，即namenode的文件系統對于客戶端來說是只讀的，顯示目錄、顯示文件內容等，寫、刪除、重命名都會失敗；
在此階段namenode搜集各個datanode的報告，當數據塊達到最小副本數以上時，會被認為是“安全”的，在一定比例的數據塊被認為是安全的以后（可設置），再過若干時間，安全模式結束；
當檢測到副本數不足數據塊時，該塊會被復制，直到達到最小副本數，系統中數據塊的位置并不是由namenode維護的，而是以塊列表形式存儲在datanode中。
2.4 數據組織
2.4.1 數據塊
HDFS被設計成支持大文件，適用HDFS的是那些需要處理大規模的數據集的應用。這些應用都是只寫入數據一次，但卻讀取一次或多次，并且讀取速度應能滿足流式讀取的需要。HDFS支持文件的“一次寫入多次讀取”語義。一個典型的數據塊大小是256MB。因而，HDFS中的文件總是按照256M被切分成不同的塊，每個塊盡可能地存儲于不同的Datanode中。
2.4.2 分段
客戶端創建文件的請求其實并沒有立即發送給Namenode，事實上，在剛開始階段HDFS客戶端會先將文件數據緩存到本地的一個臨時文件。應用程序的寫操作被透明地重定向到這個臨時文件。當這個臨時文件累積的數據量超過一個數據塊的大小，客戶端才會聯系Namenode。Namenode將文件名插入文件系統的層次結構中，并且分配一個數據塊給它。然后返回Datanode的標識符和目標數據塊給客戶端。接著客戶端將這塊數據從本地臨時文件上傳到指定的Datanode上。當文件關閉時，在臨時文件中剩余的沒有上傳的數據也會傳輸到指定的Datanode上。然后客戶端告訴Namenode文件已經關閉。此時Namenode才將文件創建操作提交到日志里進行存儲。如果Namenode在文件關閉前宕機了，則該文件將丟失。
上述方法是對在HDFS上運行的目標應用進行認真考慮后得到的結果。這些應用需要進行文件的流式寫入。如果不采用客戶端緩存，由于網絡速度和網絡堵塞會對吞估量造成比較大的影響。這種方法并不是沒有先例的，早期的文件系統，比如AFS，就用客戶端緩存來提高性能。為了達到更高的數據上傳效率，已經放松了POSIX標準的要求。
2.4.3 管道復制
當客戶端向HDFS文件寫入數據的時候，一開始是寫到本地臨時文件中。假設該文件的副本系數設置為3，當本地臨時文件累積到一個數據塊的大小時，客戶端會從Namenode獲取一個Datanode列表用于存放副本。然后客戶端開始向第一個Datanode傳輸數據，第一個Datanode一小部分一小部分(4 KB)地接收數據，將每一部分寫入本地倉庫，并同時傳輸該部分到列表中第二個Datanode節點。第二個Datanode也是這樣，一小部分一小部分地接收數據，寫入本地倉庫，并同時傳給第三個Datanode。最后，第三個Datanode接收數據并存儲在本地。因此，Datanode能流水線式地從前一個節點接收數據，并在同時轉發給下一個節點，數據以流水線的方式從前一個Datanode復制到下一個。
3. 讀寫流程
3.1 HDFS讀流程
首先HDFS的客戶端通過DistributedFileSystem；
通過DistributedFileSystem來對NameNode進行請求，同時將用戶信息及文件名的信息等發送給NameNode，并返回給DistributedFileSystem該文件包含的block所在的DataNode位置；
HDFS客戶端通過FSDataInputStream按順序去讀取DataNode中的block信息（它會選擇負載最低的或離客戶端最近的一臺DataNode去讀block）；
FSDataInputStream按順序一個一個的讀，直到所有的block都讀取完畢；
當讀取完畢后會將FSDataInputStream關閉。
3.2 HDFS寫流程
首先HDFS的客戶端通過Distributed FileSystem（HDFS中API里的一個對象）；
通過Distributed FileSystem發送客戶端的請求給NameNode（NameNode主要是接受客戶端請求）并且會帶著文件要保存的位置、文件名、操作的用戶名等信息一起發送給NameNode；
NameNode會給客戶端返回了一個FSDataOutputStream，同時也會返回文件要寫入哪些DataNode上（負載較低的）；
通過FSDataOutputStream進行寫操作，在寫之前就做文件的拆分，將文件拆分成多個Block，第一個寫操作寫在負載比較低的DataNode上，并將這個block復制到其他的DataNode上；
當所有的block副本復制完成后會反饋給FSDataOutputStream；
當所有的block副本全都復制完成，就可以將FSDataOutputStream流關閉；
通過Distributed FileSystem更新NameNode中的源數據信息。
4. 架構
4.1 NameNode和DataNode
HDFS采用master/worker架構。一個HDFS集群是由一個Namenode和一定數目的Datanodes組成。Namenode是一個中心服務器，負責管理文件系統的命名空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節點一個，負責管理它所在節點上的存儲。HDFS暴露了文件系統的命名空間，用戶能夠以文件的形式在上面存儲數據。從內部看，一個文件其實被分成一個或多個數據塊，這些塊存儲在一組Datanode上。Namenode執行文件系統的命名空間操作，比如打開、關閉、重命名文件或目錄。它也負責確定數據塊到具體Datanode節點的映射。Datanode負責處理文件系統客戶端的讀寫請求。在Namenode的統一調度下進行數據塊的創建、刪除和復制。
HDFS架構
Namenode和Datanode被設計成可以在普通的商用機器上運行。這些機器一般運行著GNU/Linux操作系統(OS)。HDFS采用Java語言開發，因此任何支持Java的機器都可以部署Namenode或Datanode。由于采用了可移植性極強的Java語言，使得HDFS可以部署到多種類型的機器上。一個典型的部署場景是一臺機器上只運行一個Namenode實例，而集群中的其它機器分別運行一個Datanode實例。這種架構也可以在一臺機器上運行多個Datanode，但這樣的情況比較少見。
集群中單一Namenode的結構大大簡化了系統的架構。Namenode是所有HDFS元數據的管理者，用戶數據永遠不會流過Namenode。
4.1.1 通信協議
所有的HDFS通訊協議都是建立在TCP/IP協議之上。客戶端通過一個可配置的TCP端口連接到Namenode，通過ClientProtocol協議與Namenode交互。而Datanode使用DatanodeProtocol協議與Namenode交互。一個遠程過程調用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協議。在設計上，Namenode不會主動發起RPC，而是響應來自客戶端或 Datanode 的RPC請求。
4.2 基礎架構
Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬件上的分布式文件系統。它和現有的分布式文件系統有很多共同點。但同時，它和其他的分布式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取文件系統數據的目的。HDFS在最開始是作為Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。
客戶端的請求全部落到了NameNode上；
元數據信息存在NameNode；
在Hadoop集群中有且只有一個處于Active狀態的NameNode；
SecondaryNameNode不是NameNode的備份節點或從節點（確切的說它只能備份NameNode的部分內容，而不是全部）；
NameNode與DataNode之間有心跳機制，從而NameNode可以知道DataNode的運行情況與負載情況。
4.2.1 健壯性
HDFS的主要目標就是即使在出錯的情況下也要保證數據存儲的可靠性。常見的三種出錯情況是：Namenode出錯, Datanode出錯和網絡分區。
4.2.1.1 磁盤數據錯誤，心跳檢測和重新復制
每個Datanode節點周期性地向Namenode發送心跳信號。網絡原因有可能導致一部分Datanode跟Namenode失去聯系。Namenode通過心跳信號的缺失來檢測這一情況，并將這些近期不再發送心跳信號的Datanode標記為宕機，不會再將新的IO請求發給它們。任何存儲在宕機Datanode上的數據將不再有效。Datanode的宕機可能會引起一些數據塊的副本系數低于指定值，Namenode不斷地檢測這些需要復制的數據塊，一旦發現就啟動復制操作。在下列情況下，可能需要重新復制：某個Datanode節點失效、某個副本遭到損壞、Datanode上的硬盤錯誤或者文件的副本系數增大。
4.2.1.1.1 DataNode熱插拔驅動器
Datanode支持熱插拔驅動器。可以添加或替換HDFS數據卷，而不必不關閉DataNode。下面簡要介紹典型的熱插拔驅動程序：
如果存在新的存儲目錄，則應格式化它們并適當地裝載它們；
將數據卷目錄更新到DataNode的配置dfs.datanode.data.dir中；
通過運行dfsadmin -reconfig datanode HOST：PORT start來使我們配置的目錄生效，并且可以使用dfsadmin -reconfig datanode HOST：PORT status查詢重新配置任務的運行狀態；
一旦重新配置任務完成，我們就可以安全地卸載、刪除數據卷目錄并物理刪除磁盤。
4.2.1.2 負載均衡
HDFS的架構支持數據均衡策略。如果某個Datanode節點上的空閑空間低于特定的臨界點，按照均衡策略系統就會自動地將數據從這個Datanode移動到其他空閑的Datanode。在對特定文件的突然高需求的情況下，此方案可以動態地創建附加的副本并重新平衡群集中的其他數據。
4.2.1.2.1 平衡器
HDFS的數據也許并不是非常均勻的分布在各個DataNode中。一個常見的原因是在現有的集群上經常會增添新的DataNode節點。當新增一個數據塊（一個文件的數據被保存在一系列的塊中）時，NameNode在選擇DataNode接收這個數據塊之前，會考慮到很多因素。其中的一些考慮的是：
將數據塊的一個副本放在正在寫這個數據塊的節點上；
盡量將數據塊的不同副本分布在不同的機架上，這樣集群可在完全失去某一機架的情況下還能存活；
一個副本通常被放置在和寫文件的節點同一機架的某個節點上，這樣可以減少跨越機架的網絡I/O；
盡量均勻地將HDFS數據分布在集群的DataNode中。
4.2.1.2.2 磁盤平衡器
Diskbalancer是一個命令行工具，可以將數據均勻分布在數據節點的所有磁盤上。此工具不同于平衡器，它負責群集范圍的數據平衡。由于幾個原因，數據可能在節點上的磁盤之間具有不均勻分布。這可能是由于大量的寫入和刪除或由于更換磁盤而發生的。該工具針對給定的數據編碼進行操作，并將塊從一個磁盤移動到另一個磁盤。
4.2.1.2.2.1 架構
磁盤平衡器通過創建計劃進行操作，然后在數據節點上執行該計劃。一個計劃是一組描述兩個磁盤之間移動數據的語句。一個計劃由多個步驟組成。移動步驟具有源磁盤，目標磁盤和要移動的字節數。可以針對操作數據節點執行計劃。
一共包含3個階段,Discover(發現)到Plan(計劃),再從Plan(計劃)到Execute(執行):
4.2.1.2.2.1.1 Discover
發現階段做的事情實際上就是通過計算各個節點內的磁盤使用情況,然后得出需要數據平衡的磁盤列表.這里會通過Volume Data Density磁盤使用密度的概念作為一個評判的標準,這個標準值將會以節點總使用率作為比較值.舉個例子,如果一個節點,總使用率為75%,就是0.75,其中A盤使用率0.5(50%),那么A盤的volumeDataDensity密度值就等于0.75-0.5=0.25.同理,如果超出的話,則密度值將會為負數.于是我們可以用節點內各個盤的volumeDataDensity的絕對值來判斷此節點內磁盤間數據的平衡情況,如果總的絕對值的和越大,說明數據越不平衡,這有點類似于方差的概念.Discover階段將會用到如下的連接器對象:
DBNameNodeConnector
JsonConnector
NullConnector
其中第一個對象會調用到Balancer包下NameNodeConnector對象,以此來讀取集群節點,磁盤數據情況。
4.2.1.2.2.1.2 Plan
拿到上一階段的匯報結果數據之后,將會進行執行計劃的生成.Plan并不是一個最小的執行單元,它的內部由各個Step組成.Step中會指定好源、目標磁盤.這里的磁盤對象是一層經過包裝的對象:DiskBalancerVolume,并不是原來的FsVolume.這里順便提一下DiskBalancer中對磁盤節點等概念的轉化:
DiskBalancerCluster.通過此對象可以讀取到集群中的節點信息,這里的節點信息以DiskBalancerDataNode的方式所呈現；
DiskBalancerDataNode.此對象代表的是一個包裝好后的DataNode；
DiskBalancerVolume和DiskBalancerVolumeSet.DataNode磁盤對象以及磁盤對象集合.DiskBalancerVolumeSet內的磁盤存儲目錄類型需要是同種StorageType。
4.2.1.2.2.1.3 Execute
最后一部分是執行階段,所有的plan計劃生成好了之后,就到了執行階段.這些計劃會被提交到各自的DataNode上,然后在DiskBalancer類中進行執行.DiskBalancer類中有專門的類對象來做磁盤間數據平衡的工作,這個類名稱叫做DiskBalancerMover.在磁盤間數據平衡的過程中,高使用率的磁盤會移動數據塊到相對低使用率的磁盤,等到滿足一定閾值關系的情況下時,DiskBalancer會漸漸地退出.在DiskBalancer的執行階段,有以下幾點需要注意：
帶寬的限制.DiskBalancer中同樣可以支持帶寬的限制,默認是10M,通過配置dfs.disk.balancer.max.disk.throughputInMBperSec進行控制；
失敗次數的限制.DiskBalancer中會存在失敗次數的控制.在拷貝block數據塊的時候,出現IOException異常,會進行失敗次數的累加計數,如果超出最大容忍值,DiskBalancer也會退出；
數據平衡閾值控制.DiskBalancer中可以提供一個磁盤間數據的平衡閾值,以此作為是否需要繼續平衡數據的標準,配置項為dfs.disk.balancer.block.tolerance.percent。
4.2.1.3 數據完整性
從某個Datanode獲取的數據塊有可能是損壞的，損壞可能是由Datanode的存儲設備錯誤、網絡錯誤或者軟件bug造成的。HDFS客戶端軟件實現了對HDFS文件內容的校驗和(checksum)檢查。當客戶端創建一個新的HDFS文件，會計算這個文件每個數據塊的校驗和，并將校驗和作為一個單獨的隱藏文件保存在同一個HDFS名字空間下。當客戶端獲取文件內容后，它會檢驗從Datanode獲取的數據跟相應的校驗和文件中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該數據塊的副本。
4.2.1.3.1 回收站機制
4.2.1.3.1.1 文件的刪除和恢復
如果啟用了回收站功能，FS Shell刪除的文件不會立即從HDFS中刪除。而是將其移動到回收目錄（每個用戶在/user /<username>/.Trash下都有自己的回收目錄）。只要文件保留在回收站中，文件就可以快速恢復。
最近刪除的文件移動到當前回收目錄（/user/<username>/.Trash/Current），并在可配置的時間間隔內，HDFS創建對/user/<username>/.Trash/<date>目錄下的一個檢查點，并在過期后刪除舊檢查點。
當文件在回收站期滿之后，NameNode將從HDFS命名空間中刪除該文件。刪除文件會導致與該文件關聯的塊被釋放。需要說明的是，文件被用戶刪除的時間和對應的釋放空間的時間之間有一個明顯的時間延遲。
4.2.1.3.1.2 減少副本
當文件的副本因子減小時，NameNode選擇可以刪除的多余副本。下一個心跳將此信息傳輸到DataNode。DataNode然后刪除相應的塊并且釋放對應的空間。同樣，在設置副本因子完成和集群中出現新的空間之間有個時間延遲。
4.2.1.4 元數據磁盤錯誤
FsImage和Edits是HDFS的核心數據結構。如果這些文件損壞了，整個HDFS實例都將失效。因而，Namenode可以配置成支持維護多個FsImage和Edits的副本。任何對FsImage或者Edits的修改，都將同步到它們的副本上。這種多副本的同步操作可能會降低Namenode每秒處理的命名空間事務數量。然而這個代價是可以接受的，因為即使HDFS的應用是數據密集型的，它們的元數據信息的量也不會很大。當Namenode重啟的時候，它會選取最近的完整的FsImage和Edits來使用。
4.2.1.4.1 檢查點節點
NameNode采用兩個文件來保存命名空間的信息：fsimage，它是最新的已執行檢查點的命名空間的信息：edits，它是執行檢查點后命名空間變化的日志文件。當NameNode啟動時，fsimage和edits合并，提供一個最新的文件系統的metadata，然后NameNode將新的HDFS狀態寫入fsimage，并開始一個新的edits日志。
Checkpoint節點周期性地創建命名空間的檢查點。它從NameNode下載fsimage和edits，在本地合并它們，并將其發回給活動的NameNode。Checkpoint節點通常與NameNode不在同一臺機器上，因為它們有同樣的內存要求。Checkpoint節點由配置文件中的bin/hdfs namenode –checkpoint來啟動。
Checkpoint(或Backup)節點的位置以及附帶的web接口由dfs.namenode.backup.address anddfs.namenode.backup.http-address參數指定。
Checkpoint進程的運行受兩個配置參數控制：
dfs.namenode.checkpoint.period，兩次連續的檢查點之間的最大的時間間隔，缺省值是1小時；
dfs.namenode.checkpoint.txns，最大的沒有執行檢查點的事務數目，默認設置為1百萬，也就是Edits中的事務條數達到1百萬就會觸發一次合并，即使未達到檢查點期間；
Checkpoint節點上保存的最新的檢查點，其目錄結構與NameNode上一樣，這樣，如果需要，NameNode總是可以讀取這上面的已執行檢查點的文件映像。多個Checkpoint節點可以在集群的配置文件中指定。
4.2.1.4.2 備份節點
Backup節點與Checkpoint節點提供同樣的執行檢查點功能，只不過它還在內存中保存一份最新的命名空間的的拷貝，該拷貝與NameNode中的保持同步。除了接收NameNode中發送的edits并把它保存到磁盤之外，Backup還將edits用到自己的內存中，因而創建出一份命名空間的備份。
因為Backup節點在內存中保持有最新的命名空間的狀態，因此它不需要從NameNode下載fsimage和edits文件來創建一個檢查點，而這是Checkpoint節點或備用NameNode所必需的步驟。Backup節點的檢查點進程更高效，因為它只需要將命名空間信息保存到本地的fsimage文件并重置edits就可以了。
由于Backup節點內存中維護了一份命名空間的拷貝，它的內存要求與NameNode一致。NameNode同一時刻只支持一個Backup節點。如果Backup在用，則不能注冊Checkpont節點。
Backup節點的配置與Checkpoint節點一樣，它采用bin/hdfs namenode –backup啟動。Backup(或Checkup)節點的位置及其web接口由配置參數dfs.namenode.backup.address和 dfs.namenode.backup.http-address指定。
使用Backup節點，NameNode就可以選擇不進行存儲，而將保持命名空間狀態的責任交給Backup節點。為此，在NameNode的配置中，采用選項-importCheckpoint來啟動NameNode，并且不設置edits的存儲位置選項dfs.namenode.edits.dir。
4.2.1.4.3 導入檢查點
如果其它所有的映像文件和edits都丟失了，可以將最后的檢查點導入到NameNode，為此，需要以下步驟：
創建一個空目錄，在dfs.namenode.name.dir項中配置為該目錄；
設置dfs.namenode.checkpoint.dir為檢查點目錄；
采用-importCheckpoint選項來啟動NameNode。
NameNode將從dfs.namenode.checkpoint.dir設置的目錄中上載檢查點，并將其保存在dfs.namenode.name.dir指定的目錄中。如果dfs.namenode.name.dir中存在一個映像文件，NameNode就會啟動失敗，NameNode要驗證dfs.namenode.checkpoint.dir中的映像文件是否有問題，但在任何情況下，都不會修改該文件。
4.2.1.4.4 恢復模式
通常，你要配置多個metadata存儲位置，當一個存儲位置崩潰后，你可以從其它位置讀取到metadata。但是，如果僅有的一個存儲位置崩潰后怎么辦呢？在這種情況下，有一個特別的NameNode啟動模式，叫恢復模式，允許你恢復大部分數據。你可以像這樣啟動恢復模式：namenode –recover，在恢復模式時，NameNode以命令行的方式與你交互，顯示你可能采取的恢復數據的措施。如果你不想采用交互模式，你可以加上選項-force，這個選項將強制選取第一個選擇恢復，通常，這是最合理的選擇。由于恢復模式可能使數據丟失，你應該在使用它之前備份edits日志文件和fsimage。
4.2.1.4.5 離線Edits文件視圖
離線Edits文件視圖是解析Edits日志文件的工具。當前處理器主要用于不同格式之間的轉換，包括可讀且比本地二進制格式更容易編輯的XML。該工具可以解析Edits日志文件格式（大致Hadoop 0.19）和更高版本。該工具僅對文件操作，它不需要運行Hadoop集群。
支持的輸入格式：
binary：Hadoop在內部使用的本地二進制格式；
xml：XML格式，由xml處理器生成，如果filename具有.xml（不區分大小寫）擴展名，則使用。
離線Edits文件視圖提供了多個輸出處理器（除非另有說明，否則處理器的輸出可以轉換回原始Edits日志文件）：
binary：Hadoop在內部使用的本地二進制格式；
xml：XML格式；
stats：打印出統計信息，不能轉換回Edits日志文件。
4.2.1.4.6 離線Image文件視圖
離線Image文件視圖是一個工具，用于將hdfs fsimage文件的內容轉儲為可讀的格式，并提供只讀WebHDFS API，以允許離線分析和檢查Hadoop集群的命名空間。該工具能夠相對快速地處理非常大的image文件。該工具處理Hadoop版本2.4及更高版本中包含的布局格式。如果要處理較早的布局格式，可以使用oiv_legacy Command的離線Image文件視圖。如果該工具無法處理fsimage文件，它會完全退出。另外，離線Image文件視圖不需要運行Hadoop集群。它完全離線運行。
離線Image文件視圖提供了幾個輸出處理器：
Web是默認的輸出處理器。它啟動一個HTTP服務器，公開只讀WebHDFS API。用戶可以通過使用HTTP REST API交互地查看命名空間；
XML創建fsimage的XML文檔，并包含fsimage中的所有信息。此處理器的輸出可通過XML工具進行自動處理和分析；
FileDistribution是用于分析命名空間Image中文件大小的工具。為了運行工具，應該通過指定maxSize和一個步驟來定義整數[0，maxSize]的范圍。整數范圍被分成指定步長的段：[0，s [1]，...，s [n-1]，maxSize]，并且處理器計算系統中有多少文件落入每個段（s [i -1]，s [i]）。請注意，大于maxSize的文件總是落入最后一個段。默認情況下，輸出文件格式化為一個制表符分隔的兩個列表：Size和NumFiles。其中Size代表段的開始，numFiles是形成Image的文件數，該大小落在該段中。通過指定選項-format，輸出文件將以可讀的方式格式化；
分隔：生成一個文本文件，其中包含inode和inode下的inode所共有的所有元素，用分隔符分隔。默認分隔符為\t，但可以通過-delimiter參數更改；
ReverseXML：與XML處理器功能相反，它從XML文件重建fsimage。此處理器可以輕松地創建fsimages進行測試。
4.2.1.5 快照
HDFS快照是文件系統的只讀時間點副本。利用快照，可以讓HDFS在數據損壞時恢復到過去一個已知正確的時間點。可以對文件系統的子樹或整個文件系統進行快照。快照的一些常見用例是數據備份，防止用戶錯誤和災難恢復。
HDFS快照的實現是高效的：
快照創建是即時的：成本是O（1）*，*不包括inode查找時間；
僅當相對于快照進行修改時才使用附加內存：內存使用為O（M），其中M是修改的文件/目錄的數量；
不復制datanode中的塊：快照文件記錄塊列表和文件大小。沒有數據復制；
快照不會對常規HDFS操作產生不利影響：按照時間倒序順序記錄修改，以便可以直接訪問當前數據。通過從當前數據中減去修改來計算快照數據。
4.2.1.5.1 Snapshottable目錄
一旦目錄設置為可快照，就可以對任何目錄進行快照。snaphottable目錄能夠容納65,536個同步快照。可快照目錄的數量沒有限制。管理員可以將任何目錄設置為可快照。如果快照目錄中有快照，則在刪除所有快照之前，不能刪除或重命名目錄。
當前不允許嵌套snaphottable目錄。換句話說，如果一個目錄的祖先或后代是一個snaphottable目錄，則不能將其設置為snaphottable。
4.2.2 輔助功能
4.2.2.1 瀏覽器界面
典型的HDFS安裝配置Web服務器以通過可配置的TCP端口公開HDFS命名空間。這允許用戶使用web瀏覽器導航HDFS命名空間并查看其文件的內容。
NameNode和DataNode每個都運行內部Web服務器，以顯示有關集群當前狀態的基本信息。如果使用默認配置，NameNode 首頁位于http://namenode-name:9870/(http://namenode-name:9870/(hadoop3.x)（hadoop3.X）。它列出集群中的DataNode和集群的基本統計信息。Web界面也可以用于瀏覽文件系統（使用NameNode首頁上的“瀏覽文件系統”鏈接）。
4.2.2.2 插件
有一種用插件訪問其內部數據的方式，將hadoop-eclipse-plugin-version.jar包拷貝到eclipse中的plugins目錄下，并進行相應的配置，即可直接用eclipse訪問HDFS的數據，已及對其進行操作，操作方式與在windows環境操作文件相似。
4.2.2.3 JAVA編程
HDFS提供了一個FileSystem Java API,支持用寫java代碼的方式來訪問HDFS的數據。
4.2.3 可擴展性
現在，Hadoop已經運行在上千個節點的集群上。HDFS集群只有一個NameNode節點。目前，NameNode上可用內存大小是一個主要的擴展限制。在超大型的集群中，增大HDFS存儲文件的平均大小能夠增大集群的規模，而不需要增加NameNode的內存。默認配置也許并不適合超大規模的集群。
4.2.4 文件權限和安全性
這里的文件權限和其他常見平臺如Linux的文件權限類似。R:read w:write x:execute權限x對于文件忽略，對于文件夾表示是否允許訪問其內容。如果zhangsan在linux系統中使用hadoop命令創建一個文件，那么這個文件在HDFS中的owner就是zhangsan。
目前，安全性不僅僅限于簡單的文件權限。HDFS還支持網絡驗證協議（比如Kerberos）來對用戶身份進行驗證和對數據進行加密傳輸。
4.2.4.1 HDFS權限指南
Hadoop分布式文件系統（HDFS）為共享大多數POSIX模型的文件和目錄實現了一個權限模型。每個文件和目錄都與所有者和組相關聯。文件或目錄對作為所有者的用戶，對于該組成員的其他用戶以及對所有其他用戶具有單獨的權限。對于文件，讀取文件需要r權限，并且需要w權限寫入或附加到文件。對于目錄，需要r權限列出目錄的內容，需要w權限才能創建或刪除文件或目錄，并且需要x權限才能訪問目錄的子目錄。
與POSIX模型相反，沒有針對文件的setuid或setgid位，因為沒有可執行文件的概念。對于目錄，沒有setuid或setgid bits目錄作為簡化。防止除超級用戶、目錄所有者或文件所有者之外的任何人刪除或移動目錄中的文件。總的來說，文件或目錄的權限是它的模式。通常，將使用用于表示和顯示模式的Unix習慣，包括使用八進制數。創建文件或目錄時，其所有者是客戶端進程的用戶標識，其組是父目錄（BSD規則）的組。
HDFS還為POSIX ACL（訪問控制列表）提供了可選的支持，以通過針對特定命名用戶或命名組的細粒度規則擴充文件權限。訪問HDFS的每個客戶端進程都具有由用戶名和組列表組成的兩部分身份。每當HDFS必須對客戶端進程訪問的文件或目錄foo執行權限檢查時：
如果用戶名與foo的所有者匹配，則測試所有者權限;
否則，如果foo的組匹配組列表的任何成員，則測試組權限；
否則，將測試foo的其他權限。
如果權限檢查失敗，則客戶端操作失敗。
4.3 HDFS高可用性（QJM）
在Hadoop 2.0.0之前，NameNode是HDFS集群中的單點故障（SPOF）。每個集群都有一個NameNode，如果該機器或進程不可用，則作為整體的集群將不可用，直到NameNode被重新啟動或在單獨的機器上啟動。
這會以兩種主要方式影響HDFS集群的總可用性：
在計劃外事件（如計算機崩潰）的情況下，群集將不可用，直到操作員重新啟動NameNode；
計劃的維護事件（如NameNode計算機上的軟件或硬件升級）將導致集群停機時間的窗口。
HDFS高可用性功能通過在具有熱備份的主/從配置中提供在同一集群中運行兩個（以及3.0.0或更多個）冗余NameNode的選項來解決上述問題。這允許在機器崩潰的情況下快速故障切換到新的NameNode，或者出于計劃維護的目的，由管理員主動發起故障切換。
4.3.1 原理
hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager，這是一個基于Paxos算法實現的HDFS HA方案，它給出了一種較好的解決思路和方案, 在典型的HA群集中，兩個或多個單獨的計算機配置為NameNode。在任何時間點，只有一個NameNode處于活動狀態，而其他的處于待機狀態。活動NameNode負責集群中的所有客戶端操作，而Standby只維護足夠的狀態以在必要時提供快速故障轉移。示意圖如下：
為了使備用節點保持其與活動節點同步的狀態，兩個節點都與一組稱為“日志節點”（JN）的獨立守護進程通信。當活動節點執行任何命名空間修改時，它持久地將修改的記錄記錄到這些JN中的大多數。備用節點能夠從JN讀取編輯。
基本原理就是用2N+1臺 JN 存儲Edits，每次寫數據操作有大多數（>=N+1）返回成功時即認為該次寫成功。當然這個算法所能容忍的是最多有N臺機器掛掉，如果多于N臺掛掉，這個算法就失效了。這個原理是基于Paxos算法。
在HA架構里面SecondaryNameNode這個角色已經不存在了，為了保持standby NN時時的與主Active NN的元數據保持一致，他們之間交互通過一系列守護的輕量級進程JournalNode
任何修改操作在 Active NN上執行時，JN進程同時也會記錄修改log到至少半數以上的JN中，這時 Standby NN 監測到JN 里面的同步log發生變化了會讀取 JN 里面的修改log，然后同步到自己的的目錄鏡像樹里面，如下圖：
當發生故障時，Active的 NN 掛掉后，Standby NN 會在它成為Active NN 前，讀取所有的JN里面的修改日志，這樣就能高可靠的保證與掛掉的NN的目錄鏡像樹一致，然后無縫的接替它的職責，維護來自客戶端請求，從而達到一個高可用的目的。
為了提供快速故障轉移，還必需備用節點具有關于集群中塊的位置的最新信息。為了實現這一點，DataNode被配置有所有NameNode的位置，并且向所有NameNode發送塊位置信息和心跳。
4.3.2 QJM的主要優勢
不需要配置額外的高共享存儲，降低了復雜度和維護成本；
消除spof；
系統健壯的程度是可配置的；
JN不會因為其中一臺的延遲而影響整體的延遲，而且也不會因為JN的數量增多而影響性能（因為NN向JN發送日志是并行的）。
4.3.3 只有一個NN能命令DN
每個NN改變狀態的時候，向DN發送自己的狀態和一個序列號；
DN在運行過程中維護此序列號，當failover時，新的NN在返回DN心跳時會返回自己的active狀態和一個更大的序列號。DN接收到這個返回則認為該NN為新的active；
如果這時原來的active NN恢復，返回給DN的心跳信息包含active狀態和原來的序列號，這時DN就會拒絕這個NN的命令。
4.3.4 只有一個NN響應客戶端
訪問standby nn的客戶端直接失敗。在RPC層封裝了一層，通過FailoverProxyProvider以重試的方式連接NN。通過若干次連接一個NN失敗后嘗試連接新的NN，對客戶端的影響是重試的時候增加一定的延遲。客戶端可以設置重試次數和時間。
Hadoop提供了ZKFailoverController角色，部署在每個NameNode的節點上，作為一個deamon進程, 簡稱zkfc，示例圖如下：
4.3.5 FailoverController組成
HealthMonitor：監控NameNode是否處于unavailable或unhealthy狀態。當前通過RPC調用NN相應的方法完成；
ActiveStandbyElector：管理和監控自己在ZK中的狀態；
ZKFailoverController：它訂閱HealthMonitor 和ActiveStandbyElector 的事件，并管理NameNode的狀態。
4.3.6 ZKFailoverController職責
健康監測：周期性的向它監控的NN發送健康探測命令，從而來確定某個NameNode是否處于健康狀態，如果機器宕機，心跳失敗，那么zkfc就會標記它處于一個不健康的狀態；
會話管理：如果NN是健康的，zkfc就會在zookeeper中保持一個打開的會話，如果NameNode同時還是Active狀態的，那么zkfc還會在Zookeeper中占有一個類型為短暫類型的znode，當這個NN掛掉時，這個znode將會被刪除，然后備用的NN，將會得到這把鎖，升級為主NN，同時標記狀態為Active；
當宕機的NN新啟動時，它會再次注冊zookeper，發現已經有znode鎖了，便會自動變為Standby狀態，如此往復循環，保證高可靠，目前可以支持兩個以上NN；
master選舉：如上所述，通過在zookeeper中維持一個短暫類型的znode，來實現搶占式的鎖機制，從而判斷哪個NameNode為Active狀態。
注意，在HA群集中，Standby NameNode還執行命名空間狀態的檢查點，因此不需要在HA群集中運行Secondary NameNode，CheckpointNode或BackupNode。
4.4 HDFS高可用性（NFS）
NFS的方式的HA的配置與啟動，和QJM方式基本上是一樣，唯一不同的地方就是active namenode和standby namenode共享edits文件的方式。QJM方式是采用journalnode來共享edits文件，而NFS方式則是采用NFS遠程共享目錄來共享edits文件。
NFS允許用戶像訪問本地文件系統一樣訪問遠程文件系統，而將NFS引入HDFS后，用戶可像讀寫本地文件一樣讀寫HDFS上的文件，大大簡化了HDFS使用，這是通過引入一個NFS gateway服務實現的，該服務能將NFS協議轉換為HDFS訪問協議，具體如下圖所示。
4.5 HDFS Federation
4.5.1 HDFS的兩個主要層
命名空間
由目錄，文件和塊組成；
它支持所有與命名空間相關的文件系統操作，如創建，刪除，修改和列出文件和目錄。
塊存儲服務
包括兩部分：
塊管理（在Namenode中執行）
①通過處理注冊和定期心跳提供Datanode集群成員身份；
②處理并維護塊的位置；
③支持塊相關操作，如創建，刪除，修改和獲取塊位置；
④管理副本放置，低復制塊的塊復制，以及刪除超過復制的塊。
存儲
由Datanodes通過在本地文件系統上存儲塊并允許讀/寫訪問來提供。
先前的HDFS架構僅允許整個集群使用單個命名空間。在該配置中，單個Namenode管理命名空間。HDFS Federration通過向HDFS添加對多個Namenodes /命名空間的支持來解決此限制。
4.5.2 原理
單Active NN的架構使得HDFS在集群擴展性和性能上都有潛在的問題，當集群大到一定程度后，NN進程使用的內存可能會達到上百G，NN成為了性能的瓶頸。
常用的估算公式為1G對應1百萬個塊，按缺省塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個文件只有一個塊，所有元數據信息也不會有1KB/block)。
為了水平擴展名稱服務，Federration使用多個獨立的Namenodes/命名空間。Namenodes之間管理的數據是共享的，但同時也是獨立的，不需要彼此協調。Datanodes被所有Namenode用作塊的公共存儲。每個Datanode注冊集群中的所有Namenode。Datanodes發送定期心跳和塊報告。它們還處理來自Namenode的命令。
為了解決這個問題,Hadoop 2.x、Hadoop 3.x提供了HDFS Federation, 示意圖如下：
多個NN共用一個集群里的存儲資源，每個NN都可以單獨對外提供服務。
每個NN都會定義一個存儲池，有單獨的id，每個DN都為所有存儲池提供存儲。
DN會按照存儲池id向其對應的NN匯報塊信息，同時，DN會向所有NN匯報本地存儲可用資源情況。
如果需要在客戶端方便的訪問若干個NN上的資源，可以使用客戶端掛載表，把不同的目錄映射到不同的NN，但NN上必須存在相應的目錄。
4.5.3 設計優勢
改動最小，向前兼容；現有的NN無需任何配置改動；如果現有的客戶端只連某臺NN的話，代碼和配置也無需改動；
分離命名空間管理和塊存儲管理；
客戶端掛載表：通過路徑自動對應NN、使Federation的配置改動對應用透明。
4.5.4 ViewF
View文件系統（ViewFs）提供了一種管理多個Hadoop文件系統命名空間（或命名空間卷）的方法。它對于在HDFS Federation中具有多個命名空間的集群特別有用。ViewF類似于一些Unix/Linux系統中的客戶端安裝表。ViewF可用于創建個性化命名空間視圖以及每個集群的常見視圖。
View文件系統具有多個集群的Hadoop系統的上下文中顯示，每個集群可以聯合到多個命名空間中，以提供每個群集的全局命名空間，以便應用程序可以以類似于聯合前的方式運行。
4.5.4.1 單個Namenode集群
在HDFS聯合之前，集群具有單個命名空間，為該集群提供單個文件系統命名空間。如果有多個集群。則每個集群的文件系統命名空間是完全獨立和不相交的。此外，物理存儲不是在集群之間共享（即Datanodes不是跨集群共享的）。
4.5.4.2 Federation和ViewF
如果有多個集群。每個集群都有一個或多個命名空間。每個namenode都有自己的命名空間。namenode屬于一個且僅一個集群。但是與單個namenode集群不同的是：同一集群中的namenode共享該集群的物理存儲。集群中的命名空間與前面一樣是獨立的。
操作根據存儲需求決定群集中每個namenode上存儲的內容。例如，他們可以將所有用戶數據（/user/<username>）放在一個命名空間中，將所有feed數據（/data）放置在另一個命名空間中，將所有項目（/projects）放在另一個命名空間等等。
4.5.4.3 使用ViewF的每個集群的全局命名空間
為了提供透明度，ViewF文件系統（即客戶端裝載表）用于創建每個集群獨立的集群命名空間視圖，這與單個Namenode集群中的命名空間類似。客戶端安裝表（如Unix安裝表），并使用舊的命名約定安裝新的命名空間卷。下圖顯示了裝載四個命名空間卷/user，/data，/projects和/tmp的裝載表：
ViewF實現了Hadoop文件系統接口，就像HDFS和本地文件系統一樣。這是一個普通的文件系統，它只允許鏈接到其他文件系統。所有shell命令與ViewFS一起使用，與HDFS和本地文件系統一樣。
5. 命令指南
所有的hadoop命令均由bin/hdfs腳本引發。不指定參數運行hdfs腳本會打印所有命令的描述。
用法：hdfs [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]
Hadoop有一個選項解析框架用于解析一般的選項和運行類。
由于字數限制，本文分為上下兩篇分別在頭條和二條推送，后半部分內容請見今日二條推送。
更多精彩干貨內容，敬請搜索關注清華-青島數據科學研究院官方公眾平臺“數據派THU”