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.3metadata組成
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上所有數據塊的列表。
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的統一調度下進行數據塊的創建、刪除和複製。
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.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.5 快照
HDFS快照是文件系統的只讀時間點副本。利用快照，可以讓HDFS在數據損壞時恢復到過去一個已知正確的時間點。可以對文件系統的子樹或整個文件系統進行快照。快照的一些常見用例是數據備份，防止用戶錯誤和災難恢復。
HDFS快照的實現是高效的：
-
快照創建是即時的：成本是O（1）*，*不包括inode查找時間；
-
僅當相對於快照進行修改時才使用附加內存：內存使用爲O（M），其中M是修改的文件/目錄的數量；
-
不復制datanode中的塊：快照文件記錄塊列表和文件大小。沒有數據複製；
-
快照不會對常規HDFS操作產生不利影響：按照時間倒序順序記錄修改，以便可以直接訪問當前數據。通過從當前數據中減去修改來計算快照數據。
4.2.1.5.1 Snapshottable目錄
一旦目錄設置爲可快照，就可以對任何目錄進行快照。snaphottable目錄能夠容納65,536個同步快照。可快照目錄的數量沒有限制。管理員可以將任何目錄設置爲可快照。如果快照目錄中有快照，則在刪除所有快照之前，不能刪除或重命名目錄。
當前不允許嵌套snaphottable目錄。換句話說，如果一個目錄的祖先或後代是一個snaphottable目錄，則不能將其設置爲snaphottable。
5. 命令指南
所有的hadoop命令均由bin/hdfs腳本引發。不指定參數運行hdfs腳本會打印所有命令的描述。
用法：hdfs [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]
Hadoop有一個選項解析框架用於解析一般的選項和運行類。
5.1 用戶命令
hadoop集羣用戶的常用命令。
5.1.1 classpath
打印獲取Hadoop jar和所需庫所需的類路徑。如果無參數調用，則打印由命令腳本設置的類路徑，可以在類路徑條目中包含通配符。其他選項在通配符擴展後打印類路徑或將類路徑寫入jar文件的清單。後者在不能使用通配符且擴展的類路徑超過支持的最大命令行長度的環境中非常有用。
5.1.2 dfs
HDFS允許以文件和目錄的形式組織用戶數據。它提供了一個稱爲FS shell的命令行界面，允許用戶與HDFS中的數據交互。此命令
集的語法類似於我們已經熟悉的shell。5.1.3 envvars
顯示計算的Hadoop環境變量。
5.1.4 fetchdt
HDFS支持fetchdt命令來獲取授權標識，並將其存儲在本地文件系統的一個文件中。一個“非安全”的客戶端可以用這個標識來訪問受限的服務器（例如NameNode）。獲取這個標識，採用RPC或HTTPS(over Kerberos)方式，然後，在獲取之前需要提交Kerberos憑證（運行kinit來獲得憑證）。HDFS fechedt命令不是一個Hadoop shell命令。它以bin/hadoop fetchdt DTfile方式運行。當你獲得授權標識後，通過指定環境變量HADOOP_TOKEN_FILE_LOCATION爲授權標識文件名，你就可以運行HDFS命令，而不需要Kerberros憑證了。
5.1.5 fsck
HDFS支持fsck命令來檢查系統中的各種不一致狀況。這個命令被設計來報告各種文件存在的問題，比如文件缺少數據塊或者副本數目不夠。不同於在本地文件系統上傳統的fsck工具，這個命令並不會修正它檢測到的錯誤。一般來說，NameNode會自動修正大多數可恢復的錯誤。HDFS的fsck不是一個Hadoop shell命令。它通過'bin/hadoop fsck'執行。
5.1.6 getconf
從配置目錄獲取配置信息。
5.1.7 groups
返回給定一個或多個用戶名的組信息。
5.1.8 lsSnapshottableDir
獲取快照目錄的列表。當它作爲超級用戶運行時，它返回所有可快照目錄。否則，它返回那些由當前用戶擁有的目錄。
5.1.9 jmxget
從服務轉儲JMX信息。
5.1.10 oev
Hadoop離線edits查看器。
5.1.11 oiv
Hadoop離線image查看器用於Hadoop 2.4或更高版本中的映像文件。
5.1.12 oiv_legacy
Hadoop的舊版本的Hadoop離線image查看器。
5.1.13 snapshotDiff
確定HDFS快照之間的差異。
5.2 管理命令
hadoop集羣管理員常用的命令。
5.2.1 balancer
運行集羣平衡工具。管理員可以簡單的按Ctrl-C來停止平衡過程。
5.2.2 cacheadmin
HDFS緩存管理。
5.2.3 crypto
HDFS透明加密。
5.2.4 datanode
運行HDFS datanode。
5.2.5 dfsadmin
DFSAdmin命令集用於管理HDFS集羣。這些是僅由HDFS管理員使用的命令。以下是一些示例/命令對：
5.2.6 diskbalancer
運行磁盤調度程序CLI。
5.2.7 erasurecode
運行ErasureCoding CLI。
5.2.8 haadmin
在帶有NFS的HDFS HA或帶有QJM的HDFS HA中使用。
5.2.9 journalnode
這個命令啓動一個journalnode用於帶有QJM的HDFS HA。
5.2.10 mover
運行數據遷移實用程序。
5.2.11 namenode
運行namenode。以及升級和回滾。
5.2.12 nfs3
這個comamnd啓動NFS3網關用於HDFS NFS3服務。
5.2.13 portmap
這個comamnd啓動RPC portmap用於HDFS NFS3服務。
5.2.14 secondarynamenode
運行HDFS輔助節點。
5.2.15 storagepolicies
列出所有/獲取/設置/取消設置存儲策略。
5.2.16 zkfc
這個命令啓動一個Zookeeper故障轉移控制器過程與帶有QJM的HDFS HA一起使用。