本文目錄：
一、HDFS
\
二、MapReduce
三、Yarn
四、Hadoop3.x 新特性
五、Hadoop 大廠面試真題解析
Hadoop 涉及的知識點如下圖所示，本文将逐一講解：
本文檔參考了關于 Hadoop 的官網及其他衆多資料整理而成，為了整潔的排版及舒适的閱讀，對于模糊不清晰的圖檔及黑白圖檔進行重新繪制成了高清彩圖。
目前企業應用較多的是Hadoop2.x，是以本文是以Hadoop2.x為主，對于Hadoop3.x新增的内容會進行說明！
Hadoop 分布式系統架構中，首要的基礎功能就是檔案系統，在 Hadoop 中使用 FileSystem 這個抽象類來表示我們的檔案系統，這個抽象類下面有很多子實作類，究竟使用哪一種，需要看我們具體的實作類，在我們實際工作中，用到的最多的就是HDFS(分布式檔案系統)以及LocalFileSystem(本地檔案系統)了。
在現代的企業環境中，單機容量往往無法存儲大量資料，需要跨機器存儲。統一管理分布在叢集上的檔案系統稱為分布式檔案系統。
HDFS（Hadoop Distributed File System）是 Hadoop 項目的一個子項目。是 Hadoop 的核心元件之一， Hadoop 非常适于存儲大型資料 (比如 TB 和 PB)，其就是使用 HDFS 作為存儲系統. HDFS 使用多台計算機存儲檔案，并且提供統一的通路接口，像是通路一個普通檔案系統一樣使用分布式檔案系統。
HDFS是一個主/從（Mater/Slave）體系結構，由三部分組成： NameNode 和 DataNode 以及 SecondaryNamenode：
NameNode 負責管理整個檔案系統的中繼資料，以及每一個路徑（檔案）所對應的資料塊資訊。
DataNode 負責管理使用者的檔案資料塊，每一個資料塊都可以在多個 DataNode 上存儲多個副本，預設為3個。
Secondary NameNode 用來監控 HDFS 狀态的輔助背景程式，每隔一段時間擷取 HDFS 中繼資料的快照。最主要作用是輔助 NameNode 管理中繼資料資訊。
首先，它是一個檔案系統，用于存儲檔案，通過統一的命名空間目錄樹來定位檔案；
其次，它是分布式的，由很多伺服器聯合起來實作其功能，叢集中的伺服器有各自的角色。
1. master/slave 架構（主從架構）
HDFS 采用 master/slave 架構。一般一個 HDFS 叢集是有一個 Namenode 和一定數目的 Datanode 組成。Namenode 是 HDFS 叢集主節點，Datanode 是 HDFS 叢集從節點，兩種角色各司其職，共同協調完成分布式的檔案存儲服務。
2. 分塊存儲
HDFS 中的檔案在實體上是分塊存儲（block）的，塊的大小可以通過配置參數來規定，預設大小在 hadoop2.x 版本中是 128M。
3. 名字空間（NameSpace）
HDFS 支援傳統的層次型檔案組織結構。使用者或者應用程式可以建立目錄，然後将檔案儲存在這些目錄裡。檔案系統名字空間的層次結構和大多數現有的檔案系統類似：使用者可以建立、删除、移動或重命名檔案。 Namenode 負責維護檔案系統的名字空間，任何對檔案系統名字空間或屬性的修改都将被 Namenode 記錄下來。 HDFS 會給用戶端提供一個統一的抽象目錄樹，用戶端通過路徑來通路檔案，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。
4. NameNode 中繼資料管理
我們把目錄結構及檔案分塊位置資訊叫做中繼資料。NameNode 負責維護整個 HDFS 檔案系統的目錄樹結構，以及每一個檔案所對應的 block 塊資訊（block 的 id，及所在的 DataNode 伺服器）。
5. DataNode 資料存儲
檔案的各個 block 的具體存儲管理由 DataNode 節點承擔。每一個 block 都可以在多個 DataNode 上。DataNode 需要定時向 NameNode 彙報自己持有的 block 資訊。 存儲多個副本（副本數量也可以通過參數設定 dfs.replication，預設是 3）
6. 副本機制
為了容錯，檔案的所有 block 都會有副本。每個檔案的 block 大小和副本系數都是可配置的。應用程式可以指定某個檔案的副本數目。副本系數可以在檔案建立的時候指定，也可以在之後改變。
7. 一次寫入，多次讀出
HDFS 是設計成适應一次寫入，多次讀出的場景，且不支援檔案的修改。 正因為如此，HDFS 适合用來做大資料分析的底層存儲服務，并不适合用來做網盤等應用，因為修改不友善，延遲大，網絡開銷大，成本太高。
如果沒有配置 hadoop 的環境變量，則在 hadoop 的安裝目錄下的bin目錄中執行以下指令，如已配置 hadoop 環境變量，則可在任意目錄下執行
help
ls
lsr
mkdir
put
moveFromLocal
copyFromLocal
appendToFile
moveToLocal
get
getmerge
copyToLocal
mv
rm
cp
cat
tail
text
chmod
chown
df
du
count
setrep
expunge (慎用)
在多人共用HDFS的環境下，配置設定非常重要。特别是在 Hadoop 處理大量資料的環境，如果沒有配額管理，很容易把所有的空間用完造成别人無法存取。HDFS 的配額設定是針對目錄而不是針對賬号，可以讓每個賬号僅操作某一個目錄，然後對目錄設定配置。
HDFS 檔案的限額配置允許我們以檔案個數，或者檔案大小來限制我們在某個目錄下上傳的檔案數量或者檔案内容總量，以便達到我們類似百度網盤網盤等限制每個使用者允許上傳的最大的檔案的量。
結果：
在設定空間配額時，設定的空間至少是 block_size * 3 大小
生成任意大小檔案的指令:
清除空間配額限制
安全模式是hadoop的一種保護機制，用于保證叢集中的資料塊的安全性。當叢集啟動的時候，會首先進入安全模式。當系統處于安全模式時會檢查資料塊的完整性。
假設我們設定的副本數（即參數dfs.replication）是3，那麼在datanode上就應該有3個副本存在，假設隻存在2個副本，那麼比例就是2/3=0.666。hdfs預設的副本率0.999。我們的副本率0.666明顯小于0.999，是以系統會自動的複制副本到其他dataNode，使得副本率不小于0.999。如果系統中有5個副本，超過我們設定的3個副本，那麼系統也會删除多于的2個副本。
在安全模式狀态下，檔案系統隻接受讀資料請求，而不接受删除、修改等變更請求。在，當整個系統達到安全标準時，HDFS自動離開安全模式。30s
安全模式操作指令
HDFS 将所有的檔案全部抽象成為 block 塊來進行存儲，不管檔案大小，全部一視同仁都是以 block 塊的統一大小和形式進行存儲，友善我們的分布式檔案系統對檔案的管理。
所有的檔案都是以 block 塊的方式存放在 hdfs 檔案系統當中，在 Hadoop 1 版本當中，檔案的 block 塊預設大小是 64M，Hadoop 2 版本當中，檔案的 block 塊大小預設是128M，block塊的大小可以通過 hdfs-site.xml 當中的配置檔案進行指定。
1) 一個檔案有可能大于叢集中任意一個磁盤
10T*3/128 = xxx塊 2T，2T，2T 檔案方式存—–>多個block塊，這些block塊屬于一個檔案
2) 使用塊抽象而不是檔案可以簡化存儲子系統
3) 塊非常适合用于資料備份進而提供資料容錯能力和可用性
通常 DataNode 從磁盤中讀取塊，但對于通路頻繁的檔案，其對應的塊可能被顯示的緩存在 DataNode 的記憶體中，以堆外塊緩存的形式存在。預設情況下，一個塊僅緩存在一個DataNode的記憶體中，當然可以針對每個檔案配置DataNode的數量。作業排程器通過在緩存塊的DataNode上運作任務，可以利用塊緩存的優勢提高讀操作的性能。
例如：
連接配接（join）操作中使用的一個小的查詢表就是塊緩存的一個很好的候選。 使用者或應用通過在緩存池中增加一個cache directive來告訴namenode需要緩存哪些檔案及存多久。緩存池（cache pool）是一個擁有管理緩存權限和資源使用的管理性分組。
例如:
一個檔案 130M，會被切分成2個block塊，儲存在兩個block塊裡面，實際占用磁盤130M空間，而不是占用256M的磁盤空間
hdfs的檔案權限機制與linux系統的檔案權限機制類似
r:read w:write x:execute
權限x對于檔案表示忽略，對于檔案夾表示是否有權限通路其内容
如果linux系統使用者zhangsan使用hadoop指令建立一個檔案，那麼這個檔案在HDFS當中的owner就是zhangsan
HDFS檔案權限的目的，防止好人做錯事，而不是阻止壞人做壞事。HDFS相信你告訴我你是誰，你就是誰
為了保證block塊的安全性，也就是資料的安全性，在hadoop2當中，檔案預設儲存三個副本，我們可以更改副本數以提高資料的安全性
在hdfs-site.xml當中修改以下配置屬性，即可更改檔案的副本數
Client 發起檔案上傳請求，通過 RPC 與 NameNode 建立通訊, NameNode 檢查目标檔案是否已存在，父目錄是否存在，傳回是否可以上傳；
Client 請求第一個 block 該傳輸到哪些 DataNode 伺服器上；
NameNode 根據配置檔案中指定的備份數量及機架感覺原理進行檔案配置設定, 傳回可用的 DataNode 的位址如：A, B, C；
Hadoop 在設計時考慮到資料的安全與高效， 資料檔案預設在 HDFS 上存放三份， 存儲政策為本地一份，同機架内其它某一節點上一份，不同機架的某一節點上一份。
Client 請求 3 台 DataNode 中的一台 A 上傳資料（本質上是一個 RPC 調用，建立 pipeline ），A 收到請求會繼續調用 B，然後 B 調用 C，将整個 pipeline 建立完成， 後逐級傳回 client；
Client 開始往 A 上傳第一個 block（先從磁盤讀取資料放到一個本地記憶體緩存），以 packet 為機關（預設64K），A 收到一個 packet 就會傳給 B，B 傳給 C。A 每傳一個 packet 會放入一個應答隊列等待應答；
資料被分割成一個個 packet 資料包在 pipeline 上依次傳輸，在 pipeline 反方向上， 逐個發送 ack（指令正确應答），最終由 pipeline 中第一個 DataNode 節點 A 将 pipelineack 發送給 Client；
當一個 block 傳輸完成之後，Client 再次請求 NameNode 上傳第二個 block，重複步驟 2；
在本地網絡中，兩個節點被稱為“彼此近鄰”是什麼意思？在海量資料進行中，其主要限制因素是節點之間資料的傳輸速率——帶寬很稀缺。這裡的想法是将兩個節點間的帶寬作為距離的衡量标準。
節點距離：兩個節點到達最近的共同祖先的距離總和。
例如，假設有資料中心d1機架r1中的節點n1。該節點可以表示為/d1/r1/n1。利用這種标記，這裡給出四種距離描述。
Distance(/d1/r1/n1, /d1/r1/n1)=0（同一節點上的程序）
Distance(/d1/r1/n1, /d1/r1/n2)=2（同一機架上的不同節點）
Distance(/d1/r1/n1, /d1/r3/n2)=4（同一資料中心不同機架上的節點）
Distance(/d1/r1/n1, /d2/r4/n2)=6（不同資料中心的節點）
1) 低版本Hadoop副本節點選擇
第一個副本在client所處的節點上。如果用戶端在叢集外，随機選一個。
第二個副本和第一個副本位于不相同機架的随機節點上。
第三個副本和第二個副本位于相同機架，節點随機。
2) Hadoop2.7.2 副本節點選擇
第二個副本和第一個副本位于相同機架，随機節點。
第三個副本位于不同機架，随機節點。
Client向NameNode發起RPC請求，來确定請求檔案block所在的位置；
NameNode會視情況傳回檔案的部分或者全部block清單，對于每個block，NameNode 都會傳回含有該 block 副本的 DataNode 位址； 這些傳回的 DN 位址，會按照叢集拓撲結構得出 DataNode 與用戶端的距離，然後進行排序，排序兩個規則：網絡拓撲結構中距離 Client 近的排靠前；心跳機制中逾時彙報的 DN 狀态為 STALE，這樣的排靠後；
Client 選取排序靠前的 DataNode 來讀取 block，如果用戶端本身就是DataNode，那麼将從本地直接擷取資料(短路讀取特性)；
底層上本質是建立 Socket Stream（FSDataInputStream），重複的調用父類 DataInputStream 的 read 方法，直到這個塊上的資料讀取完畢；
當讀完清單的 block 後，若檔案讀取還沒有結束，用戶端會繼續向NameNode 擷取下一批的 block 清單；
讀取完一個 block 都會進行 checksum 驗證，如果讀取 DataNode 時出現錯誤，用戶端會通知 NameNode，然後再從下一個擁有該 block 副本的DataNode 繼續讀。
read 方法是并行的讀取 block 資訊，不是一塊一塊的讀取；NameNode 隻是傳回Client請求包含塊的DataNode位址，并不是傳回請求塊的資料；
最終讀取來所有的 block 會合并成一個完整的最終檔案。
從 HDFS 檔案讀寫過程中，可以看出，HDFS 檔案寫入時是串行寫入的，資料包先發送給節點A，然後節點A發送給B，B在給C；而HDFS檔案讀取是并行的， 用戶端 Client 直接并行讀取block所在的節點。
namenode工作機制
第一次啟動namenode格式化後，建立fsimage和edits檔案。如果不是第一次啟動，直接加載編輯日志和鏡像檔案到記憶體。
用戶端對中繼資料進行增删改的請求。
namenode記錄記錄檔，更新滾動日志。
namenode在記憶體中對資料進行增删改查。
secondary namenode
secondary namenode詢問 namenode 是否需要 checkpoint。直接帶回 namenode 是否檢查結果。
secondary namenode 請求執行 checkpoint。
namenode 滾動正在寫的edits日志。
将滾動前的編輯日志和鏡像檔案拷貝到 secondary namenode。
secondary namenode 加載編輯日志和鏡像檔案到記憶體，并合并。
生成新的鏡像檔案 fsimage.chkpoint。
拷貝 fsimage.chkpoint 到 namenode。
namenode将 fsimage.chkpoint 重新命名成fsimage。
所有的中繼資料資訊都儲存在了FsImage與Eidts檔案當中，這兩個檔案就記錄了所有的資料的中繼資料資訊，中繼資料資訊的儲存目錄配置在了 hdfs-site.xml 當中
用戶端對hdfs進行寫檔案時會首先被記錄在edits檔案中。
edits修改時中繼資料也會更新。
每次hdfs更新時edits先更新後用戶端才會看到最新資訊。
fsimage：是namenode中關于中繼資料的鏡像，一般稱為檢查點。
一般開始時對namenode的操作都放在edits中，為什麼不放在fsimage中呢？
因為fsimage是namenode的完整的鏡像，内容很大，如果每次都加載到記憶體的話生成樹狀拓撲結構，這是非常耗記憶體和CPU。
fsimage内容包含了namenode管理下的所有datanode中檔案及檔案block及block所在的datanode的中繼資料資訊。随着edits内容增大，就需要在一定時間點和fsimage合并。
使用指令 hdfs oiv
檢視指令 hdfs oev
secnonaryNN通知NameNode切換editlog。
secondaryNN從NameNode中獲得FSImage和editlog(通過http方式)。
secondaryNN将FSImage載入記憶體，然後開始合并editlog，合并之後成為新的fsimage。
secondaryNN将新的fsimage發回給NameNode。
NameNode用新的fsimage替換舊的fsimage。
完成合并的是 secondarynamenode，會請求namenode停止使用edits，暫時将新寫操作放入一個新的檔案中（edits.new)。
secondarynamenode從namenode中通過http get獲得edits，因為要和fsimage合并，是以也是通過http get 的方式把fsimage加載到記憶體，然後逐一執行具體對檔案系統的操作，與fsimage合并，生成新的fsimage，然後把fsimage發送給namenode，通過http post的方式。
namenode從secondarynamenode獲得了fsimage後會把原有的fsimage替換為新的fsimage，把edits.new變成edits。同時會更新fsimage。
hadoop進入安全模式時需要管理者使用dfsadmin的save namespace來建立新的檢查點。
secondarynamenode在合并edits和fsimage時需要消耗的記憶體和namenode差不多，是以一般把namenode和secondarynamenode放在不同的機器上。
fsimage與edits的合并時機取決于兩個參數，第一個參數是預設1小時fsimage與edits合并一次。
第一個參數：時間達到一個小時fsimage與edits就會進行合并
第二個參數：hdfs操作達到1000000次也會進行合并
第三個參數：每隔多長時間檢查一次hdfs的操作次數
為了保證中繼資料的安全性，我們一般都是先确定好我們的磁盤挂載目錄，将中繼資料的磁盤做RAID1
namenode的本地目錄可以配置成多個，且每個目錄存放内容相同，增加了可靠性。
具體配置方案:
hdfs-site.xml
在我們的secondaryNamenode對namenode當中的fsimage和edits進行合并的時候，每次都會先将namenode的fsimage與edits檔案拷貝一份過來，是以fsimage與edits檔案在secondarNamendoe當中也會儲存有一份，如果namenode的fsimage與edits檔案損壞，那麼我們可以将secondaryNamenode當中的fsimage與edits拷貝過去給namenode繼續使用，隻不過有可能會丢失一部分資料。這裡涉及到幾個配置選項
namenode儲存fsimage的配置路徑
namenode儲存edits檔案的配置路徑
secondaryNamenode儲存fsimage檔案的配置路徑
secondaryNamenode儲存edits檔案的配置路徑
接下來我們來模拟namenode的故障恢複功能
殺死namenode程序: 使用jps檢視namenode的程序号 , kill -9 直接殺死。
删除namenode的fsimage檔案和edits檔案。
根據上述配置, 找到namenode放置fsimage和edits路徑. 直接全部rm -rf 删除。
拷貝secondaryNamenode的fsimage與edits檔案到namenode的fsimage與edits檔案夾下面去。
根據上述配置, 找到secondaryNamenode的fsimage和edits路徑, 将内容 使用cp -r 全部複制到namenode對應的目錄下即可。
重新啟動namenode, 觀察資料是否存在。
datanode工作機制
一個資料塊在datanode上以檔案形式存儲在磁盤上，包括兩個檔案，一個是資料本身，一個是中繼資料包括資料塊的長度，塊資料的校驗和，以及時間戳。
DataNode啟動後向namenode注冊，通過後，周期性（1小時）的向namenode上報所有的塊資訊。(dfs.blockreport.intervalMsec)。
心跳是每3秒一次，心跳傳回結果帶有namenode給該datanode的指令如複制塊資料到另一台機器，或删除某個資料塊。如果超過10分鐘沒有收到某個datanode的心跳，則認為該節點不可用。
叢集運作中可以安全加入和退出一些機器。
資料完整性
當DataNode讀取block的時候，它會計算checksum。
如果計算後的checksum，與block建立時值不一樣，說明block已經損壞。
client讀取其他DataNode上的block。
datanode在其檔案建立後周期驗證checksum。
掉線時限參數設定
datanode程序死亡或者網絡故障造成datanode無法與namenode通信，namenode不會立即把該節點判定為死亡，要經過一段時間，這段時間暫稱作逾時時長。HDFS預設的逾時時長為10分鐘+30秒。如果定義逾時時間為timeout，則逾時時長的計算公式為：
timeout = 2 dfs.namenode.heartbeat.recheck-interval + 10 dfs.heartbeat.interval。
而預設的dfs.namenode.heartbeat.recheck-interval 大小為5分鐘，dfs.heartbeat.interval預設為3秒。
需要注意的是hdfs-site.xml 配置檔案中的heartbeat.recheck.interval的機關為毫秒，dfs.heartbeat.interval的機關為秒。
DataNode的目錄結構
和namenode不同的是，datanode的存儲目錄是初始階段自動建立的，不需要額外格式化。
在/opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas/current這個目錄下檢視版本号
具體解釋:
storageID：存儲id号。
clusterID叢集id，全局唯一。
cTime屬性标記了datanode存儲系統的建立時間，對于剛剛格式化的存儲系統，這個屬性為0；但是在檔案系統更新之後，該值會更新到新的時間戳。
datanodeUuid：datanode的唯一識别碼。
storageType：存儲類型。
layoutVersion是一個負整數。通常隻有HDFS增加新特性時才會更新這個版本号。
datanode多目錄配置
datanode也可以配置成多個目錄，每個目錄存儲的資料不一樣。即：資料不是副本。具體配置如下：
隻需要在value中使用逗号分隔出多個存儲目錄即可
需求說明:
随着公司業務的增長，資料量越來越大，原有的資料節點的容量已經不能滿足存儲資料的需求，需要在原有叢集基礎上動态添加新的資料節點。
複制一台新的虛拟機出來
将我們純淨的虛拟機複制一台出來，作為我們新的節點
修改mac位址以及IP位址
關閉防火牆，關閉selinux
更改主機名
四台機器更改主機名與IP位址映射
node04伺服器關機重新開機
node04安裝jdk
然後解壓jdk安裝包，配置環境變量
解壓hadoop安裝包
将node01關于hadoop的配置檔案全部拷貝到node04
建立dfs.hosts檔案
node01編輯hdfs-site.xml添加以下配置
在namenode的hdfs-site.xml配置檔案中增加dfs.hosts屬性
重新整理namenode
node01執行以下指令重新整理namenode
更新resourceManager節點
node01執行以下指令重新整理resourceManager
namenode的slaves檔案增加新服務節點主機名稱
node01編輯slaves檔案，并添加新增節點的主機，更改完後，slaves檔案不需要分發到其他機器上面去
單獨啟動新增節點
使用負載均衡指令，讓資料均勻負載所有機器
建立dfs.hosts.exclude配置檔案
在namenod所在伺服器的/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop目錄下建立dfs.hosts.exclude檔案，并添加需要退役的主機名稱
編輯namenode所在機器的hdfs-site.xml
編輯namenode所在的機器的hdfs-site.xml配置檔案，添加以下配置
重新整理namenode，重新整理resourceManager
節點退役完成，停止該節點程序
等待退役節點狀态為decommissioned（所有塊已經複制完成），停止該節點及節點資料總管。注意：如果副本數是3，服役的節點小于等于3，是不能退役成功的，需要修改副本數後才能退役。
從include檔案中删除退役節點
node01執行一下指令重新整理namenode，重新整理resourceManager
從namenode的slave檔案中删除退役節點
如果資料負載不均衡，執行以下指令進行均衡負載
所有的資料都是以一個個的block塊存儲的，隻要我們能夠将檔案的所有block塊全部找出來，拼接到一起，又會成為一個完整的檔案，接下來我們就來通過指令将檔案進行拼接:
上傳一個大于128M的檔案到hdfs上面去
我們選擇一個大于128M的檔案上傳到hdfs上面去，隻有一個大于128M的檔案才會有多個block塊。
這裡我們選擇将我們的jdk安裝包上傳到hdfs上面去。
node01執行以下指令上傳jdk安裝包
web浏覽器界面檢視jdk的兩個block塊id
這裡我們看到兩個block塊id分别為
1073742699和1073742700
那麼我們就可以通過blockid将我們兩個block塊進行手動拼接了。
根據我們的配置檔案找到block塊所在的路徑
執行block塊的拼接
在我們實際工作當中，極有可能會遇到将測試叢集的資料拷貝到生産環境叢集，或者将生産環境叢集的資料拷貝到測試叢集，那麼就需要我們在多個叢集之間進行資料的遠端拷貝，hadoop自帶也有指令可以幫我們實作這個功能
本地檔案拷貝scp
叢集之間的資料拷貝distcp
每個檔案均按塊存儲，每個塊的中繼資料存儲在namenode的記憶體中，是以hadoop存儲小檔案會非常低效。因為大量的小檔案會耗盡namenode中的大部分記憶體。但注意，存儲小檔案所需要的磁盤容量和存儲這些檔案原始内容所需要的磁盤空間相比也不會增多。例如，一個1MB的檔案以大小為128MB的塊存儲，使用的是1MB的磁盤空間，而不是128MB。
Hadoop存檔檔案或HAR檔案，是一個更高效的檔案存檔工具，它将檔案存入HDFS塊，在減少namenode記憶體使用的同時，允許對檔案進行透明的通路。具體說來，Hadoop存檔檔案可以用作MapReduce的輸入。
建立歸檔檔案
第一步：建立歸檔檔案
注意：歸檔檔案一定要保證yarn叢集啟動
第二步：檢視歸檔檔案内容
第三步：解壓歸檔檔案
快照顧名思義，就是相當于對我們的hdfs檔案系統做一個備份，我們可以通過快照對我們指定的檔案夾設定備份，但是添加快照之後，并不會立即複制所有檔案，而是指向同一個檔案。當寫入發生時，才會産生新檔案
快照使用基本文法
快照操作實際案例
任何一個檔案系統，基本上都會有垃圾桶機制，也就是删除的檔案，不會直接徹底清掉，我們一把都是将檔案放置到垃圾桶當中去，過一段時間之後，自動清空垃圾桶當中的檔案，這樣對于檔案的安全删除比較有保證，避免我們一些誤操作，導緻誤删除檔案或者資料
資源回收筒配置兩個參數
預設值fs.trash.interval=0，0表示禁用資源回收筒，可以設定删除檔案的存活時間。
預設值fs.trash.checkpoint.interval=0，檢查資源回收筒的間隔時間。
要求fs.trash.checkpoint.interval<=fs.trash.interval。
啟用資源回收筒
修改所有伺服器的core-site.xml配置檔案
檢視資源回收筒
資源回收筒在叢集的 /user/root/.Trash/ 這個路徑下
通過javaAPI删除的資料，不會進入資源回收筒，需要調用moveToTrash()才會進入資源回收筒
恢複資源回收筒資料
hdfs dfs -mv trashFileDir hdfsdir
trashFileDir ：資源回收筒的檔案路徑
hdfsdir ：将檔案移動到hdfs的哪個路徑下
清空資源回收筒
hdfs dfs -expunge