HDFS有什么特點(diǎn)，被設(shè)計(jì)做什么? ? ??

????????Hadoop分布式文件系統(tǒng)(HDFS)被設(shè)計(jì)成適合運(yùn)行在通用硬件(commodity hardware)上的分布式文件系統(tǒng)。有一下幾個(gè)特點(diǎn)：

????????HDFS是一個(gè)高度容錯(cuò)性的系統(tǒng)，具有高容錯(cuò)、高可靠性、高擴(kuò)展性的特點(diǎn)，適合部署在廉價(jià)的機(jī)器上。

????????HDFS能提供對應(yīng)用程序數(shù)據(jù)的高吞吐量訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。HDFS上的一個(gè)典型文件大小一般都在G字節(jié)至T字節(jié)。因此，HDFS被調(diào)節(jié)以支持大文件存儲。它應(yīng)該能提供整體上高的數(shù)據(jù)傳輸帶寬，能在一個(gè)集群里擴(kuò)展到數(shù)百個(gè)節(jié)點(diǎn)。一個(gè)單一的HDFS實(shí)例應(yīng)該能支撐數(shù)以千萬計(jì)的文件。

DataNode與NameNode

二者之間的聯(lián)系

????????HDFS采用master/slave架構(gòu)(主從結(jié)構(gòu))。一個(gè)HDFS集群是由一個(gè)Namenode和一定數(shù)目的Datanodes組成（當(dāng)然，我們可以做HA）。

????????Namenode是一個(gè)中心服務(wù)器，負(fù)責(zé)管理文件系統(tǒng)的名字空間(namespace)以及客戶端對文件的訪問。

????????集群中的Datanode一般是一個(gè)節(jié)點(diǎn)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲。HDFS暴露了文件系統(tǒng)的名字空間，用戶能夠以文件的形式在上面存儲數(shù)據(jù)。從內(nèi)部看，一個(gè)文件其實(shí)被分成一個(gè)或多個(gè)數(shù)據(jù)塊（一個(gè)block塊大小為128M），這些塊存儲在一組Datanode上。Namenode執(zhí)行文件系統(tǒng)的名字空間操作，比如打開、關(guān)閉、重命名文件或目錄。它也負(fù)責(zé)確定數(shù)據(jù)塊到具體Datanode節(jié)點(diǎn)的映射。Datanode負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請求。在Namenode的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制。

? ? ? ?

?集群中單一Namenode的結(jié)構(gòu)大大簡化了系統(tǒng)的架構(gòu)。Namenode是所有HDFS元數(shù)據(jù)的仲裁者和管理者，這樣，用戶數(shù)據(jù)永遠(yuǎn)不會(huì)流過Namenode。

NN與DN都干什么活

NameNode執(zhí)行的是文件系統(tǒng)的namspace操作，比如打開、不安比、重命名文件和目錄，也決定這DataNode中塊的映射。
主要負(fù)責(zé)：
????????處理客戶端請求的響應(yīng)；
????????元數(shù)據(jù)的管理，包括文件的名稱、副本系數(shù)、Block存放的DataNode的管理。

DataNode負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請求。
DataNode還根據(jù)來自NameNode的指令執(zhí)行block的創(chuàng)建，刪除和副本的一些操作。
主要負(fù)責(zé)：
????????存儲用戶的文件對應(yīng)的數(shù)據(jù)塊；
????????定期向NameNode發(fā)送心跳信息，匯報(bào)本身及其所有的block信息，健康狀況。

文件系統(tǒng)的名字空間 (namespace)

????????HDFS支持傳統(tǒng)的層次型文件組織結(jié)構(gòu)。用戶或者應(yīng)用程序可以創(chuàng)建目錄，然后將文件保存在這些目錄里。文件系統(tǒng)名字空間的層次結(jié)構(gòu)和大多數(shù)現(xiàn)有的文件系統(tǒng)類似：用戶可以創(chuàng)建、刪除、移動(dòng)或重命名文件。當(dāng)前，HDFS不支持用戶磁盤配額和訪問權(quán)限控制，也不支持硬鏈接和軟鏈接。但是HDFS架構(gòu)并不妨礙實(shí)現(xiàn)這些特性。

????????Namenode負(fù)責(zé)維護(hù)文件系統(tǒng)的名字空間，任何對文件系統(tǒng)名字空間或?qū)傩缘男薷亩紝⒈籒amenode記錄下來。應(yīng)用程序可以設(shè)置HDFS保存的文件的副本數(shù)目。文件副本的數(shù)目稱為文件的副本系數(shù)，這個(gè)信息也是由Namenode保存的。

數(shù)據(jù)復(fù)制

????????HDFS被設(shè)計(jì)成能夠在一個(gè)大集群中跨機(jī)器可靠地存儲超大文件。它將每個(gè)文件存儲成一系列的數(shù)據(jù)塊，除了最后一個(gè)，所有的數(shù)據(jù)塊都是同樣大小的（整除效果，還有余數(shù)）。為了容錯(cuò)，文件的所有數(shù)據(jù)塊都會(huì)有副本（一般副本數(shù)為3個(gè)，看需求）。每個(gè)文件的數(shù)據(jù)塊大小和副本系數(shù)都是可配置的。應(yīng)用程序可以指定某個(gè)文件的副本數(shù)目。副本系數(shù)可以在文件創(chuàng)建的時(shí)候指定，也可以在之后改變。HDFS中的文件都是一次性寫入的，并且嚴(yán)格要求在任何時(shí)候只能有一個(gè)寫入者。

????????Namenode全權(quán)管理數(shù)據(jù)塊的復(fù)制，它周期性地從集群中的每個(gè)Datanode接收心跳信號和塊狀態(tài)報(bào)告(Blockreport)。接收到心跳信號意味著該Datanode節(jié)點(diǎn)工作正常。塊狀態(tài)報(bào)告包含了一個(gè)該Datanode上所有數(shù)據(jù)塊的列表。

副本存放: 最最開始的一步（機(jī)架感知策略）

????????副本的存放是HDFS可靠性和性能的關(guān)鍵。優(yōu)化的副本存放策略是HDFS區(qū)分于其他大部分分布式文件系統(tǒng)的重要特性。這種特性需要做大量的調(diào)優(yōu)，并需要經(jīng)驗(yàn)的積累。

機(jī)架感知策略（非常非常重要的且NB的詞匯?。?/h5>

????????HDFS采用一種稱為機(jī)架感知(rack-aware)的策略來改進(jìn)數(shù)據(jù)的可靠性、可用性和網(wǎng)絡(luò)帶寬的利用率。

????????大型HDFS實(shí)例一般運(yùn)行在跨越多個(gè)機(jī)架的計(jì)算機(jī)組成的集群上，不同機(jī)架上的兩臺機(jī)器之間的通訊需要經(jīng)過交換機(jī)。在大多數(shù)情況下，同一個(gè)機(jī)架內(nèi)的兩臺機(jī)器間的帶寬會(huì)比不同機(jī)架的兩臺機(jī)器間的帶寬大。

????????通過一個(gè)機(jī)架感知的過程，Namenode可以確定每個(gè)Datanode所屬的機(jī)架id -->? -->? -->

一個(gè)簡單但沒有優(yōu)化的策略就是將副本存放在不同的機(jī)架上。這樣可以有效防止當(dāng)整個(gè)機(jī)架失效時(shí)數(shù)據(jù)的丟失，并且允許讀數(shù)據(jù)的時(shí)候充分利用多個(gè)機(jī)架的帶寬。這種策略設(shè)置可以將副本均勻分布在集群中，有利于當(dāng)組件失效情況下的負(fù)載均衡。但是，因?yàn)檫@種策略的一個(gè)寫操作需要傳輸數(shù)據(jù)塊到多個(gè)機(jī)架，這增加了寫的代價(jià)。

????????在大多數(shù)情況下，副本系數(shù)是3，HDFS的存放策略是將一個(gè)副本存放在本地機(jī)架的節(jié)點(diǎn)上，一個(gè)副本放在同一機(jī)架的另一個(gè)節(jié)點(diǎn)上，最后一個(gè)副本放在不同機(jī)架的節(jié)點(diǎn)上。這種策略減少了機(jī)架間的數(shù)據(jù)傳輸，這就提高了寫操作的效率。機(jī)架的錯(cuò)誤遠(yuǎn)遠(yuǎn)比節(jié)點(diǎn)的錯(cuò)誤少，所以這個(gè)策略不會(huì)影響到數(shù)據(jù)的可靠性和可用性。于此同時(shí)，因?yàn)閿?shù)據(jù)塊只放在兩個(gè)（不是三個(gè)）不同的機(jī)架上，所以此策略減少了讀取數(shù)據(jù)時(shí)需要的網(wǎng)絡(luò)傳輸總帶寬。在這種策略下，副本并不是均勻分布在不同的機(jī)架上。三分之一的副本在一個(gè)節(jié)點(diǎn)上，三分之二的副本在一個(gè)機(jī)架上，其他副本均勻分布在剩下的機(jī)架中，這一策略在不損害數(shù)據(jù)可靠性和讀取性能的情況下改進(jìn)了寫的性能。（這個(gè)思路非常NB?。?/p>

（注：機(jī)架就是機(jī)房里頭的安置服務(wù)器的架子）

副本選擇

為了降低整體的帶寬消耗和讀取延時(shí)，HDFS會(huì)盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個(gè)機(jī)架上有一個(gè)副本，那么就讀取該副本。如果一個(gè)HDFS集群跨越多個(gè)數(shù)據(jù)中心，那么客戶端也將首先讀本地?cái)?shù)據(jù)中心的副本。

注：大數(shù)據(jù)中最常說的一句話就是：移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更有利

安全模式（很重要的點(diǎn)）

Namenode啟動(dòng)后會(huì)進(jìn)入一個(gè)稱為安全模式的特殊狀態(tài)。處于安全模式的Namenode是不會(huì)進(jìn)行數(shù)據(jù)塊的復(fù)制的。

安全模式怎么退出（Important!）

????????Namenode從所有的 Datanode接收心跳信號和塊狀態(tài)報(bào)告。塊狀態(tài)報(bào)告包括了某個(gè)Datanode所有的數(shù)據(jù)塊列表。每個(gè)數(shù)據(jù)塊都有一個(gè)指定的最小副本數(shù)。

????????當(dāng)Namenode檢測確認(rèn)某個(gè)數(shù)據(jù)塊的副本數(shù)目達(dá)到這個(gè)最小值，那么該數(shù)據(jù)塊就會(huì)被認(rèn)為是副本安全(safely replicated)的；在一定百分比（這個(gè)參數(shù)可配置）的數(shù)據(jù)塊被Namenode檢測確認(rèn)是安全之后（加上一個(gè)額外的30秒等待時(shí)間），Namenode將退出安全模式狀態(tài)。

接下來它會(huì)確定還有哪些數(shù)據(jù)塊的副本沒有達(dá)到指定數(shù)目，并將這些數(shù)據(jù)塊復(fù)制到其他Datanode上。

文件系統(tǒng)元數(shù)據(jù)的持久化

EditLog的事務(wù)日志（IM）

????????Namenode上保存著HDFS的名字空間。對于任何對文件系統(tǒng)元數(shù)據(jù)產(chǎn)生修改的操作，Namenode都會(huì)使用一種稱為EditLog的事務(wù)日志記錄下來。例如，在HDFS中創(chuàng)建一個(gè)文件，Namenode就會(huì)在Editlog中插入一條記錄來表示；同樣地，修改文件的副本系數(shù)也將往Editlog插入一條記錄。Namenode在本地操作系統(tǒng)的文件系統(tǒng)中存儲這個(gè)Editlog。

FsImage文件（IM）

????????整個(gè)文件系統(tǒng)的名字空間，包括數(shù)據(jù)塊到文件的映射、文件的屬性等，都存儲在一個(gè)稱為FsImage的文件中，這個(gè)文件也是放在Namenode所在的本地文件系統(tǒng)上。

注：journalnode 同步兩個(gè)namenode之前的元數(shù)據(jù)信息的，同步edit_log

檢查點(diǎn)(checkpoint)及其過程

????????Namenode在內(nèi)存中保存著整個(gè)文件系統(tǒng)的名字空間和文件數(shù)據(jù)塊映射(Blockmap)的映像。這個(gè)關(guān)鍵的元數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)得很緊湊，因而一個(gè)有4G內(nèi)存的Namenode足夠支撐大量的文件和目錄。

????????當(dāng)Namenode啟動(dòng)時(shí)，它從硬盤中讀取Editlog和FsImage，將所有Editlog中的事務(wù)作用在內(nèi)存中的FsImage上，并將這個(gè)新版本的FsImage從內(nèi)存中保存到本地磁盤上，然后刪除舊的Editlog，因?yàn)檫@個(gè)舊的Editlog的事務(wù)都已經(jīng)作用在FsImage上了。這個(gè)過程稱為一個(gè)檢查點(diǎn)(checkpoint)。

????????在當(dāng)前實(shí)現(xiàn)中，檢查點(diǎn)只發(fā)生在Namenode啟動(dòng)時(shí)，在不久的將來將實(shí)現(xiàn)支持周期性的檢查點(diǎn)。

塊狀態(tài)報(bào)告

????????Datanode將HDFS數(shù)據(jù)以文件的形式存儲在本地的文件系統(tǒng)中，它并不知道有關(guān)HDFS文件的信息。它把每個(gè)HDFS數(shù)據(jù)塊存儲在本地文件系統(tǒng)的一個(gè)單獨(dú)的文件中。Datanode并不在同一個(gè)目錄創(chuàng)建所有的文件，實(shí)際上，它用試探的方法來確定每個(gè)目錄的最佳文件數(shù)目，并且在適當(dāng)?shù)臅r(shí)候創(chuàng)建子目錄。在同一個(gè)目錄中創(chuàng)建所有的本地文件并不是最優(yōu)的選擇，這是因?yàn)楸镜匚募到y(tǒng)可能無法高效地在單個(gè)目錄中支持大量的文件。

????????當(dāng)一個(gè)Datanode啟動(dòng)時(shí)，它會(huì)掃描本地文件系統(tǒng)，產(chǎn)生一個(gè)這些本地文件對應(yīng)的所有HDFS數(shù)據(jù)塊的列表，然后作為報(bào)告發(fā)送到Namenode，這個(gè)報(bào)告就是塊狀態(tài)報(bào)告。

通訊協(xié)議

????????所有的HDFS通訊協(xié)議都是建立在TCP/IP協(xié)議之上。

? ? ? ? 首先客戶端通過一個(gè)可配置的TCP端口連接到Namenode，再通過ClientProtocol協(xié)議與Namenode交互。

????????而Datanode使用DatanodeProtocol協(xié)議與Namenode交互。

一個(gè)遠(yuǎn)程過程調(diào)用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協(xié)議。在設(shè)計(jì)上，Namenode不會(huì)主動(dòng)發(fā)起RPC，而是響應(yīng)來自客戶端或 Datanode 的RPC請求。

健壯性

HDFS的主要目標(biāo)就是即使在出錯(cuò)的情況下也要保證數(shù)據(jù)存儲的可靠性。常見的三種出錯(cuò)情況是：Namenode出錯(cuò), Datanode出錯(cuò)和網(wǎng)絡(luò)割裂(network partitions，網(wǎng)斷了)。

磁盤數(shù)據(jù)錯(cuò)誤，心跳檢測和重新復(fù)制

心跳有什么作用

????????每個(gè)Datanode節(jié)點(diǎn)周期性地向Namenode發(fā)送心跳信號。網(wǎng)絡(luò)波動(dòng)可能導(dǎo)致一部分Datanode跟Namenode失去聯(lián)系。

????????Namenode通過心跳信號的缺失來檢測這一情況，并將這些近期不再發(fā)送心跳信號Datanode標(biāo)記為宕機(jī)，不會(huì)再將新的IO請求發(fā)給它們。任何存儲在宕機(jī)Datanode上的數(shù)據(jù)將不再有效。Datanode的宕機(jī)可能會(huì)引起一些數(shù)據(jù)塊的副本系數(shù)低于指定值，Namenode不斷地檢測這些需要復(fù)制的數(shù)據(jù)塊，一旦發(fā)現(xiàn)就啟動(dòng)復(fù)制操作。

在下列情況下，可能需要重新復(fù)制：

????????某個(gè)Datanode節(jié)點(diǎn)失效，

????????某個(gè)副本遭到損壞，

????????Datanode上的硬盤錯(cuò)誤，

? ? ? ? 或者文件的副本系數(shù)增大。

集群均衡

????????HDFS的架構(gòu)支持?jǐn)?shù)據(jù)均衡策略。如果某個(gè)Datanode節(jié)點(diǎn)上的空閑空間低于特定的臨界點(diǎn)，按照均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從這個(gè)Datanode移動(dòng)到其他空閑的Datanode。當(dāng)對某個(gè)文件的請求突然增加，那么也可能啟動(dòng)一個(gè)計(jì)劃創(chuàng)建該文件新的副本，并且同時(shí)重新平衡集群中的其他數(shù)據(jù)。這些均衡策略目前還沒有實(shí)現(xiàn)。

注：現(xiàn)階段的版本已經(jīng)實(shí)現(xiàn)了，我們通過控制balancer參數(shù)進(jìn)行控制，基本上出現(xiàn)的情況是擴(kuò)展了幾臺幾點(diǎn)，如何做均衡這種情況

如何保證數(shù)據(jù)完整性（校驗(yàn)和的出現(xiàn)IMIMIM）

? ? ? ? 我們從某個(gè)Datanode獲取的數(shù)據(jù)塊有可能是損壞的，損壞可能是由Datanode的存儲設(shè)備錯(cuò)誤、網(wǎng)絡(luò)錯(cuò)誤或者軟件bug造成的。

解決辦法（校驗(yàn)和）

HDFS客戶端軟件實(shí)現(xiàn)了對HDFS文件內(nèi)容的校驗(yàn)和(checksum)檢查。具體步驟如下：

? ? ? ? 一、當(dāng)客戶端創(chuàng)建一個(gè)新的HDFS文件，會(huì)計(jì)算這個(gè)文件每個(gè)數(shù)據(jù)塊的校驗(yàn)和，并將校驗(yàn)和作為一個(gè)單獨(dú)的隱藏文件保存在同一個(gè)HDFS名字空間下。

? ? ? ? 二、當(dāng)客戶端獲取文件內(nèi)容后，它會(huì)檢驗(yàn)從Datanode獲取的數(shù)據(jù)跟相應(yīng)的校驗(yàn)和文件中的校驗(yàn)和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該數(shù)據(jù)塊的副本。

元數(shù)據(jù)磁盤錯(cuò)誤

????????FsImage和Editlog是HDFS的核心數(shù)據(jù)結(jié)構(gòu)。如果這些文件損壞了，整個(gè)HDFS實(shí)例都將失效。因而，Namenode可以配置成支持維護(hù)多個(gè)FsImage和Editlog的副本。任何對FsImage或者Editlog的修改，都將同步到它們的副本上。這種多副本的同步操作可能會(huì)降低Namenode每秒處理的名字空間事務(wù)數(shù)量。然而這個(gè)代價(jià)是可以接受的，因?yàn)榧词笻DFS的應(yīng)用是數(shù)據(jù)密集的，它們也非元數(shù)據(jù)密集的。當(dāng)Namenode重啟的時(shí)候，它會(huì)選取最近的完整的FsImage和Editlog來使用。

????????Namenode是HDFS集群中的單點(diǎn)故障(single point of failure)所在。如果Namenode機(jī)器故障，是需要手工干預(yù)的。目前，自動(dòng)重啟或在另一臺機(jī)器上做Namenode故障轉(zhuǎn)移的功能已經(jīng)實(shí)現(xiàn)了。

數(shù)據(jù)組織

數(shù)據(jù)塊

????????HDFS被設(shè)計(jì)成支持大文件，適用HDFS的是那些需要處理大規(guī)模的數(shù)據(jù)集的應(yīng)用。

????????這些應(yīng)用都是只寫入數(shù)據(jù)一次，但卻讀取一次或多次，并且讀取速度應(yīng)能滿足流式讀取的需要。HDFS支持文件的“一次寫入多次讀取”語義。

????????一個(gè)典型的數(shù)據(jù)塊大小是128M。因而，HDFS中的文件總是按照128M被切分成不同的塊，每個(gè)塊盡可能地存儲于不同的Datanode中。

Staging（階段）

????????客戶端創(chuàng)建文件的請求其實(shí)并沒有立即發(fā)送給Namenode，事實(shí)上，

????????在剛開始階段HDFS客戶端會(huì)先將文件數(shù)據(jù)緩存到本地的一個(gè)臨時(shí)文件。

????????應(yīng)用程序的寫操作被透明地重定向到這個(gè)臨時(shí)文件。

????????當(dāng)這個(gè)臨時(shí)文件累積的數(shù)據(jù)量超過一個(gè)數(shù)據(jù)塊的大小，客戶端才會(huì)聯(lián)系Namenode。

????????Namenode將文件名插入文件系統(tǒng)的層次結(jié)構(gòu)中，并且分配一個(gè)數(shù)據(jù)塊給它。

????????然后返回Datanode的標(biāo)識符和目標(biāo)數(shù)據(jù)塊給客戶端。

????????接著客戶端將這塊數(shù)據(jù)從本地臨時(shí)文件上傳到指定的Datanode上。

????????當(dāng)文件關(guān)閉時(shí)，在臨時(shí)文件中剩余的沒有上傳的數(shù)據(jù)也會(huì)傳輸?shù)街付ǖ腄atanode上。

????????然后客戶端告訴Namenode文件已經(jīng)關(guān)閉。

????????此時(shí)Namenode才將文件創(chuàng)建操作提交到日志里進(jìn)行存儲。

????????如果Namenode在文件關(guān)閉前宕機(jī)了，則該文件將丟失。

上述方法是對在HDFS上運(yùn)行的目標(biāo)應(yīng)用進(jìn)行認(rèn)真考慮后得到的結(jié)果。這些應(yīng)用需要進(jìn)行文件的流式寫入。如果不采用客戶端緩存，由于網(wǎng)絡(luò)速度和網(wǎng)絡(luò)堵塞會(huì)對吞估量造成比較大的影響。這種方法并不是沒有先例的，早期的文件系統(tǒng)，比如AFS，就用客戶端緩存來提高性能。為了達(dá)到更高的數(shù)據(jù)上傳效率，已經(jīng)放松了POSIX標(biāo)準(zhǔn)的要求。

流水線復(fù)制流程（副本）

當(dāng)客戶端向HDFS文件寫入數(shù)據(jù)的時(shí)候，一開始是寫到本地臨時(shí)文件中。

假設(shè)該文件的副本系數(shù)設(shè)置為3，

????????當(dāng)本地臨時(shí)文件累積到一個(gè)數(shù)據(jù)塊的大小時(shí)，客戶端會(huì)從Namenode獲取一個(gè)Datanode列表用于存放副本。

????????然后客戶端開始向第一個(gè)Datanode傳輸數(shù)據(jù)，第一個(gè)Datanode一小部分一小部分(4 KB)地接收數(shù)據(jù)，將每一部分寫入本地倉庫，并同時(shí)傳輸該部分到列表中第二個(gè)Datanode節(jié)點(diǎn)。

????????第二個(gè)Datanode也是這樣，一小部分一小部分地接收數(shù)據(jù)，寫入本地倉庫，并同時(shí)傳給第三個(gè)Datanode。

????????最后，第三個(gè)Datanode接收數(shù)據(jù)并存儲在本地。

????????因此，Datanode能流水線式地從前一個(gè)節(jié)點(diǎn)接收數(shù)據(jù)，并在同時(shí)轉(zhuǎn)發(fā)給下一個(gè)節(jié)點(diǎn)，數(shù)據(jù)以流水線的方式從前一個(gè)Datanode復(fù)制到下一個(gè)。

DFSShell

HDFS以文件和目錄的形式組織用戶數(shù)據(jù)。它提供了一個(gè)命令行的接口(DFSShell)讓用戶與HDFS中的數(shù)據(jù)進(jìn)行交互。命令的語法和用戶熟悉的其他shell(例如 bash, csh)工具類似。下面是一些動(dòng)作/命令的示例：

DFSShell 可以用在那些通過腳本語言和文件系統(tǒng)進(jìn)行交互的應(yīng)用程序上。

注：如果配置了環(huán)境變量，就不必按照上面的命令了

DFSAdmin

DFSAdmin 命令用來管理HDFS集群。這些命令只有HDSF的管理員才能使用。下面是一些動(dòng)作/命令的示例：

存儲空間回收

HDFS文件的刪除和恢復(fù)

????????當(dāng)用戶或應(yīng)用程序刪除某個(gè)文件時(shí)，這個(gè)文件并沒有立刻從HDFS中刪除。實(shí)際上，HDFS會(huì)將這個(gè)文件重命名轉(zhuǎn)移到/trash目錄。只要文件還在/trash目錄中，該文件就可以被迅速地恢復(fù)。文件在/trash中保存的時(shí)間是可配置的，當(dāng)超過這個(gè)時(shí)間時(shí)，Namenode就會(huì)將該文件從名字空間中刪除。刪除文件會(huì)使得該文件相關(guān)的數(shù)據(jù)塊被釋放。注意，從用戶刪除文件到HDFS空閑空間的增加之間會(huì)有一定時(shí)間的延遲。

只要被刪除的文件還在/trash目錄中，用戶就可以恢復(fù)這個(gè)文件。如果用戶想恢復(fù)被刪除的文件，他/她可以瀏覽/trash目錄找回該文件。/trash目錄僅僅保存被刪除文件的最后副本。/trash目錄與其他的目錄沒有什么區(qū)別，除了一點(diǎn)：在該目錄上HDFS會(huì)應(yīng)用一個(gè)特殊策略來自動(dòng)刪除文件。目前的默認(rèn)策略是刪除/trash中保留時(shí)間超過6小時(shí)的文件。將來，這個(gè)策略可以通過一個(gè)被良好定義的接口配置。

減少副本系數(shù)

當(dāng)一個(gè)文件的副本系數(shù)被減小后，Namenode會(huì)選擇過剩的副本刪除。下次心跳檢測時(shí)會(huì)將該信息傳遞給Datanode。Datanode遂即移除相應(yīng)的數(shù)據(jù)塊，集群中的空閑空間加大。同樣，在調(diào)用setReplication?API結(jié)束和集群中空閑空間增加間會(huì)有一定的延遲。

參考文檔

Hadoop – Apache Hadoop 2.7.7，hadoop官網(wǎng)

Hadoop – Apache Hadoop 3.4.0-SNAPSHOT

Hadoop分布式文件系統(tǒng)：架構(gòu)和設(shè)計(jì)

通過對比老版本的HDFS文檔，最新的HDFS文檔有了很大的變化，這也是走向成熟的一步吧文章來源地址http://www.zghlxwxcb.cn/news/detail-630665.html

到了這里，關(guān)于Hadoop理論及實(shí)踐-HDFS的Namenode及Datanode（參考Hadoop官網(wǎng)）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！