Hadoop學習筆記（一）

HDFS
適合一次寫入，屢次讀取
NameNode將文件系統的元數據存儲在內存中，所以HDFS所能存儲的文件總數受限於NameNode容量
類：IOUtil Progressable
URL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory());
distcp並行複製
數據校驗 壓縮（文件，map/reduce輸入輸出） 序列化（RPC使用,AVRO）

HDFS存儲容量(中間文件和日誌文件佔約30%)

fsck 文件健康情況檢查
http://node16:50075/blockScannerReport
Datanode塊掃描器
均衡器

優化：
增大io.file.buffer.size。如64KB或128KB

安全：
Kerberos

文件屬性：
Block ID: 1073741852
Block Pool ID: BP-720723591-172.17.20.166-1449572898218
Generation Stamp: 1028
Size: 2268
Availability:
node17
node18
node16

#列出當前hadoop正在執行的jobs
./hadoop job -list
#殺掉job
./hadoop job -kill job_201212111628_11166

# Notice
When we run a JAR file by using the hadoop jar command, the dependencies of the JAR file
must be included in Hadoop's class path

 

NameNode數據目錄結構
NameNode的數據目錄由dfs.namenode.name.dir配置，其目錄結構以下所示：
[${dfs.namenode.name.dir}]
└[current]
├VERSION
├edits_<last transactionId_1>_<then transactionId_1>
├edits_<last transactionId_2>_<then transactionId_2>
┊......
├edits_<last transactionId_n><then transactionIdn>
├edits_inprogress_<current transactionId>
├fsimage_<old transactionId>
├fsimage_<old transactionId>.md5
 └seen_txid
VERSION文件包含了當前運行的HDFS集羣的版本信息，以下所示:
#Fri Jan 04 14:40:48 CST 2013
namespaceID=2066014563
clusterID=CID-a1d53d26-3cf6-41ae-9aa6-c84306cf803d
cTime=0
storageType=NAME_NODE
blockpoolID=BP-1167604030-172.10.39.247-1357281648247
layoutVersion=-40

• CDHv1.0使用clusterID來代替namespaceID，但仍然提供namespaceID以實現向下兼容。clusterID是文件系統的惟一標識符，在文件系統格式化時建立。DataNode上也會記錄這個clusterID。NameNode只接受具備相同ClusterID的DataNode的鏈接。
• cTime是一個計數器，記錄NameNode的更新次數，HDFS每升級一次，該值就會被加1。
• storageType表示當前目錄的類型，對於NameNode，該值爲"NAME_NODE"，對於DataNode，該值爲"DATA_NODE"。
• blockpoolID是當前NameNode管理的數據塊池ID，對於Federation HDFS，不一樣的NameNode管理不一樣的數據塊池，同一個DataNode管理多個數據塊池。blockpoolID的命名方式以下：

BP-<random num><namenode ip><namenode create time(UTC)>

• layoutVersion是一個負數，表示當前版本的HDFS使用的數據持久化方案版本。

fsimage文件是HDFS元數據檢查點的持久化文件，包含了文件系統目錄和文件inode信息(inode表示一個文件或目錄的元數據，與Unix系統相似)。並非每一次HDFS操做都會被寫入fsimage中，fsimage中的數據與NameNode內存中的數據並不一致。NameNode啓動時首先將fsimage載入內存重建NameNode元數據到最近的檢查點，而後，從新執行Edit log中記錄的操做，將元數據更新到最新狀態。
Edit Log(編輯日誌)是記錄了與NameNode的每一次RPC操做。EditLog能夠存放在不一樣的存儲系統中，如本地文件系統、NFS、Bookkeeper等，HDFS使用基於transactionId的日誌管理方法來實現EditLog的事務性。
seen_txid存放了transactionId，第一次format時該值爲0

SecondaryNameNode的主要工做是爲NameNode建立檢查點、輔助NameNode處理fsimage和EditLog，防止NameNode上的EditLog過於龐大。SecondaryNameNode能夠爲單節點的HDFS集羣提供必定的數據恢復能裏，並加快NameNode的啓動速度。
注意：在Hadoop官方設計文檔中提到，SecondaryNameNode已經被Checkpoint Node和Backup Node取代，可是，咱們認爲Checkpoint Node和Backup Node都沒有像SecondaryNameNode那樣通過生產實踐檢驗，其可靠性還需驗證，所以，目前仍然使用SecondaryNameNode來完成NameNode檢查點的建立、輔助處理NameNode鏡像文件和編輯日誌。

DataNode數據目錄
DataNode在第一次啓動時按照配置自動建立存儲目錄，其數據目錄結構以下所示：
[${dfs.datanode.data.dir}]
└[current]
├VERSION
└[<blockpool Id>]
├dncp_block_verification.log.curr
├dncp_block_verification.log.prev
├[tmp]
└[current]
├VERSION
├[rbw]
│ ├blk_<id_1>
│ ├blk_<id_1>.meta
│ ┊......
│ ├blk_<id_n>
│ └blk_<id_n>.meta
└[finalized]
├blk_<id_1'>
├blk_<id_1'>.meta
├......
├blk_<id_n>
├blk_<id_n>.meta
├[subdir 0]
├[subdir 1]
┊......
└[subdir n]
DataNode的數據目錄相對NameNode的要複雜的多，這裏介紹幾個關鍵的目錄和文件進行說明。
頂部的VERSION與NameNode數據目錄下的VERSION文件相似，記錄了該DataNode的版本信息，包括storageID、clusterID、storageType、layoutVersion和cTime。
以BlockPool ID命名的目錄是對應數據塊池的數據存儲目錄，其下存儲了該數據塊池的全部數據。該目錄下的dncp_block_verification.log.[prev|curr]文件爲DataNode塊掃描操做的日誌，DataNode塊掃描相關內容參見3.2.1節相關內容。tmp保存了臨時備份數據塊，current目錄爲該數據塊池的數據目錄，其下的VERSION文件記錄了該數據塊池的版本信息，包括namespaceID、cTime、blockpoolID和layoutVersion。rbw目錄和finalized目錄分別存儲了處於RBW/RWR/RUR狀態的數據副本和已經完成備份的數據副本（Finalized狀態）。表3-1對數據塊的狀態進行了說明。
表3-1 數據副本狀態

塊狀態	存儲目錄	說明
Finalized	${BP_HOME}/current/finalized	表示該副本已經完成了全部數據的寫入。
RBW  (Replica Being Written To)	${BP_HOME}/current/rbw	表示該副本正在寫入或追加數據。
RWR  (Replica Waiting to be Recovered)	${BP_HOME}/current/rbw	若是DataNode宕機或重啓，處於RBW狀態的副本將轉換爲RWR狀態，不會在接受新數據的寫入。
RUR  (Replica Under Recovery)	${BP_HOME}/current/rbw	當租約到期，NameNode將爲客戶端關閉其所佔用的副本，這將使該副本進入RUR狀態。
Temporary	${BP_HOME}/tmp	表示該副本正在被建立。

*${BP_HOME}爲${datanode.data.dir}/current/<blockpool_id>
一個數據塊由兩個文件組成，一個爲塊數據文件(以blk_爲前綴)，一個爲該數據塊的元數據文件(以.meta爲後綴)，該文件包括了數據塊的版本、類型和一系列區域檢驗和。當數據目錄中的塊文件達到64個以後，DataNode會在該目錄下創建一個子目錄(subdirn)，將這些塊文件移動到該目錄下，以免一個目錄存儲過多的文件，影響了系統的性能。

 

管理HDFS集羣

HDFS爲集羣管理者提供了一系列管理工具，經過這些管理工具，管理員能夠及時瞭解集羣運行狀態。下面對幾個經常使用的工具進行介紹：
dfsadmin
dfsadmin是Hadoop提供的命令行形式的多功能管理工具，經過該工具能夠查看Hadoop集羣的運行狀態、管理Hadoop集羣。該工具的調用方式爲:
$ bin/dfs dfsadmin <command> [params...]
dfsadmin提供的功能如表3-2所示。
表3-2 dfsadmin命令

命令	格式	說明
-report	-report	顯示文件系統的統計信息及集羣的運行狀態。
-safemode	-safemode <enter	leave	get	wait>	改變、查詢安全模式狀態
-saveNamespace	-saveNamespace	將當前內存中的文件系統映像保持爲一個新的fsimage文件，重置edits文件。  *該操做僅在安全模式下進行  *須要superusesr權限
-restoreFailedStorage	-restoreFailedStorage <true	false	check>	設置/取消/檢查NameNode中恢復失敗存儲的可用副本的標記。  *須要superusesr權限
-refreshNodes	-refreshNodes	更新容許鏈接到namenode的datanode列表。該操做會使namenode從新讀取dfs.hosts、dfs.host.exclude的配置。  *詳細狀況，請參見3.2.3平常維護中的"加入和接觸節點"一節
-finalizeUpgrade	-finalizeUpgrade	移除datanode和namenode存儲目錄下的舊版本數據。通常在升級完成後進行。  *CDHv1.0是第一個CDH發行版，關於系統升級的說明將在CDHv2.0的說明文檔中闡述
-upgradeProgress	-upgradeProgress <status	details	force>	獲取HDFS的升級進度，或強制升級。  *關於系統升級的說明將在CDHv2.0的說明文檔中闡述
-metasave	-metasave filename	將HDFS部分信息存儲到Hadoop日誌目錄下的指定文件中。這些信息包括:  正在被複制或刪除的塊信息  鏈接上的datanode列表
-refreshServiceAcl	-refreshServiceAcl	刷新namenode的服務級受權策略文件
-refreshUserToGroupsMappings	-refreshUserToGroupsMappings	刷新用戶組信息
-refreshSuperUserGroupsConfiguration	-refreshSuperUserGroupsConfiguration	刷新超級用戶代理組信息
-printTopology	-printTopology	顯示集羣拓撲結構
refreshNamenodes	-refreshNamenodes <datanodehost:port>	使給定datanode從新載入配置文件，中止管理舊的block-pools，並開始管理新的block-pools
-deleteBlockPool	-deleteBlockPool  <datanode-host:port blockpoolId>  [force]	刪除指定datanode下給定的blockpool。  force參數將刪除blockpool對於的數據目錄，不管他是否爲空  該命令只有在blockpool已下線的狀況下執行，可以使用refreshNamenodes命令來中止一個blockpool
-setQuota	-setQuota  <quota> <dirname>...<dirname>	設置目錄配額，即該目錄下最多包含多少個目錄和文件。該配置主要用於防止用戶建立大量的小文件，以保護namenode的內存安全。
-clrQuota	-clrQuota <dirname>...<dirname>	清除指定目錄的配額。
-setSpaceQuota	-setSpaceQuota  <quota> <dirname>...<dirname>	設置目錄的空間配額，以限制目錄的規模。通常用戶用於給多個用戶分配存儲空間。
-clrSpaceQuota	-clrSpaceQuota <dirname>...<dirname>	清理目錄的空間配額。
-setBalancerBandwidth	-setBalancerBandwidth  <bandwidth in bytes per second>	設置負載均衡器的帶寬限制。限制負載均衡器的帶寬十分有必要。
-fetchImage	-fetchImage <local directory>	下載最新的fsimage文件到指定的本地目錄下。

fsck
HDFS提供fsck工具來查找HDFS上的文件缺失的塊、副本缺失的塊和副本過多的塊。使用方式以下：
$ bin/hdfs fsck <path> [-move| -delete|-openforwrite] [-files[-blocks[-locations|-racks]]]
表3-3 fsck命令選項

命令選項	說明
<path>	要檢查的目錄或文件的HDFS路徑
-move	將損壞的文件移動到 /lost+found
-delete	刪除損壞的文件
-openforwrite	顯示正在寫入的文件
-files	顯示被檢查的文件
-blocks	顯示文件中的各個塊信息
-locations	顯示每一塊的位置
-racks	顯示每一個塊的機架位置和DataNode地址

下面給出一個示例，並解釋其中的含義。
$ bin/hdfs fsck /
打印結果以下：
Connecting to namenode via http://node1:50070
FSCK started by root (auth:SIMPLE) from /172.10.39. ••• for path / at Sat Jan 05 15:39:26 CST 2013
..............Status: HEALTHY
Total size: 215543188002 B ①
Total dirs: 788
Total files: 1146 (Files currently being written: 3)
Total blocks (validated): 4045 (avg. block size 53286325 B) (Total open file blocks (not validated): 3)
Minimally replicated blocks: 4045 (100.0 %) ②
Over-replicated blocks: 0 (0.0 %) ③
Under-replicated blocks: 0 (0.0 %) ④
Mis-replicated blocks: 0 (0.0 %) ⑤
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0 ⑥
Missing replicas: 0 (0.0 %) ⑦
Number of data-nodes: 3
Number of racks: 1
FSCK ended at Sat Jan 05 15:39:26 CST 2013 in 76 milliseconds 
The filesystem under path '/' is HEALTHY
fsck掃描結果很是直觀明瞭，下面對部分條目進行解釋。

1. 顯示了掃描的目錄的一些統計信息，包括佔的空間大小、目錄數、文件數、正在寫入的文件數、總塊數及塊的其餘信息；
2. 達到默認副本數的塊 默認備份數由配置項dfs.replication設定；
3. 過多備份數的塊 指超出默認備份級別的塊，過多的副本會被HDFS自動刪除；
4. 備份數不夠的塊 指備份數低於默認備份級別的塊，HDFS會自動爲這些塊建立副本(若是集羣條件不容許建立新的副本(如單機模式下配置了超過1個的備份級別)，HDFS會一直進行嘗試，直到知足默認複製級別爲止)。可使用dfsadmin –metasave命令查看正在複製和等待複製的塊的信息；
5. 錯誤的備份塊 指不符合副本放置策略的副本塊，這種狀況一般發生在修改機架感應配置以後。須要手動修復錯誤的備份塊，具體方式以下：
6. 使用hadoop fs –setrep命令增長錯誤塊對應文件的備份數；
7. 等待副本被建立
8. 使用hadoop fs –setrep命令將錯誤塊對應文件的備份數恢復的原來級別。
9. 損壞的塊 指那些全部副本都已經損壞的塊。
10. 丟失的塊 指那些沒有任何副本的塊。

塊損壞和丟失意味着數據丟失，HDFS沒法修復出現數據丟失的文件，不過fsck提供一些選項來處理這些損壞的文件，以減小數據丟失帶來的損失，包括-move選項和-delete選項。-move選項將損壞的文件移動到/lost+found目錄下，-delete選項則會直接刪除損壞的文件。
注意：fsck工具只是掃描namenode上的元數據，而沒有正真的掃描datanode上的塊數據，所以，掃描結果與實際的HDFS狀況有可能不一致。
DataNode塊掃描
每一個DataNode在後臺都會執行一個塊掃描任務，按期檢測該節點上全部塊的狀態，以便及時檢測和修復有錯誤的塊。塊掃描器每隔3周(可經過配置項"dfs.datanode.scan.period.hours"配置)執行一次檢測任務，在此過程當中，損壞的塊將被及時上報到NameNode進行處理。能夠經過HDFS的Web接口獲取塊掃描報告，Web接口以下，可經過listblocks參數獲取該datanode下的全部塊信息。
http://<datanode host>:50075/blockScannerReport[?listblocks]
下面是一份塊掃描報告示例，能夠看出，該DataNode當前管理的Block Pool中有4210個塊，最近四周驗證了268個塊,當前驗證週期完成進度爲8%。同時能夠看出，DataNode對塊掃描的速度進行了限制(1024KB/s)。
Block report for block pool: BP-1167604030-172.10.39.247-1357281648247 
Total Blocks : 4210
Verified in last hour : 59
Verified in last day : 252
Verified in last week : 268
Verified in last four weeks : 268
Verified in SCAN_PERIOD : 268
Not yet verified : 3942
Verified since restart : 2414
Scans since restart : 2414
Scan errors since restart : 0
Transient scan errors : 0
Current scan rate limit KBps : 1024
Progress this period : 8%
Time left in cur period : 94.98%
當使用listblocks參數時，將獲取全部4210個塊的詳細信息。下面是節選的示例：
Block report for block pool: BP-1167604030-172.10.39.247-1357281648247
blk_7157586640620185565_45291 : status : ok type : none scan time : 0 
not yet verified
blk_5595226818506773378_45318 : status : ok type : none scan time : 0 
not yet verified
......
blk_4076176118522921159_43689: status : ok type : local scan time: 1357376657973 
2013-01-05 17:04:17,973
blk_1045572311214380377_44883 : status : ok type : local scan time : 1357376678774 
2013-01-05 17:04:38,774 
Total Blocks : 4210
Verified in last hour : 62
......
Time left in cur period : 94.96%
上述列表中，每一行顯示一個塊的信息，顯示格式以下:
<block id>:status:<ok|failed> type:<local|remote|none> scan time:<"0 not yet verified" | UTCTime yyyy-mm-dd hh:mm:ss,sss>

• 塊的狀態有兩種，ok表示正常，failed表示損壞。
• 塊的類型有三種，local表示本地塊，remote表示遠程塊，none表示還沒有掃描。若是掃描操做由後臺線程執行，則爲local，若是掃描操做由客戶端或其餘datanode執行，則爲remote類型。

負載均衡
雖然HDFS在寫入數據時進行了負載均衡，可是，隨着系統的運行，每一個datanode上的塊分佈仍然可能會不均衡，從而致使熱點，並削弱MapReduce的數據本地化優點，所以，要避免這種狀況出現。HDFS提供了負載均衡器程序，可將負載較重的DataNode上的塊數據轉移到空閒的DataNode上。集羣均衡的標準爲LmeigeDataNode的使用率和集羣的使用率之間的差異小於閾值(默認爲10%)。當集羣的負載達到均衡標準後，負載均衡器就自動退出了。啓動負載均衡器的方式以下所示
$ sbin/start-balancer.sh [–threshold n] [-policy [datanode|blockpool]]
下面是一個負載均衡器的輸出示例：
13/01/05 17:29:50 INFO balancer.Balancer: Using a threshold of 1.0
13/01/05 17:29:50 INFO balancer.Balancer: namenodes = [hdfs://node1:8020]
13/01/05 17:29:50 INFO balancer.Balancer: p =
Balancer.Parameters[BalancingPolicy.Node, threshold=1.0]
Time Stamp Iteration# Bytes Already Moved Bytes Left To Move Bytes Being Moved
13/01/05 17:29:51 INFO net.NetworkTopology: Adding a new node: /default-rack/172.10.39.246:50010
13/01/05 17:29:51 INFO net.NetworkTopology: Adding a new node: /default-rack/172.10.39.247:50010
13/01/05 17:29:51 INFO net.NetworkTopology: Adding a new node: /default-rack/172.10.39.245:50010
13/01/05 17:29:51 INFO balancer.Balancer: 0 over-utilized: []
13/01/05 17:29:51 INFO balancer.Balancer: 0 underutilized: []
The cluster is balanced. Exiting...
Balancing took 1.461 seconds
haadmin
CDHv1.0提供hdfs haadmin來管理HA集羣。可經過hdfs haadmin –help <command>獲取特定命令的幫助信息。

3.2.2 狀態監控

審計日誌
有些CDHv1.0用戶可能須要對CDH的平常運行進行審計，HDFS經過配置log4j的級別爲INFO來實現日誌審計功能，使每一個HDFS事件都可在NameNode的日誌中生成一行記錄。CDH v1.0默認開啓日誌審計功能。爲了避免與NameNode監控日誌混在一塊兒，最好將審計日誌單獨輸出。具體作法請參見Hadoop Wiki: http://wiki.apache.org/hadoop/HowToConfigure。
監控日誌
CDH v1.0中全部組件都會產生日誌文件，這些文件有助於查明系統故障的緣由。經過在hadoop-env.sh文件中加入下述環境變量，可配置Hadoop日誌目錄：
export HADOOP_LOG_DIR=/var/log/hadoop
CDH v1.0各組件的日誌分爲兩類，第一類以.log爲後綴，由log4j生成，CDHv1.0的大部分日誌都會記錄在這類日誌文件中；第二類以.out爲後綴，主要記錄標準輸出和標準錯誤日誌，這些日誌基本爲空，所以在故障排查時，因首先檢查log4j日誌。
說明：CDH v1.0全部組件都提供審計日誌和監控日誌，日誌管理方式與HDFS一致。本文檔只介紹HDFS日誌配置，其餘組件的日誌配置類推。
JVM堆棧
CDH v1.0提供一個Web接口對正在守護進程中運行的JVM中的線程執行線程轉儲，可得到對應守護進程內的線程堆棧信息。如獲取namenode的線程堆棧信息，可在瀏覽器中輸入:http://namenode:50070/stacks，得到的結果以下所示：
Process Thread Dump: 
27 active threads
Thread 41 (1843720310@qtp-1619519236-7):
State: RUNNABLE
Blocked count: 52
Waited count: 1509
Stack:
sun.management.ThreadImpl.getThreadInfo1(Native Method)
sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:156)
sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:121)
org.apache.hadoop.util.ReflectionUtils.printThreadInfo(ReflectionUtils.java:162)
org.apache.hadoop.http.HttpServer$StackServlet.doGet(HttpServer.java:816)
javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
......
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
Thread 35 (org.apache.hadoop.hdfs.server.namenode.LeaseManager$Monitor@3a32ea4):
State: TIMED_WAITING
......
度量信息
CDH各組件都有一套完整而獨立的度量系統，用於收集CDH各組件的運行信息。度量從屬於特定的上下文(所謂上下文是指應用程序運行期間，系統爲其提供的完整的運行時環境，包括軟件環境和硬件環境)。HDFS使用的上下文包括"dfs"、"rpc"、"ugi"、"jvm"。上下文是度量發佈的單位，即度量以上下文爲單位輸出給度量接受組件，如本地文件、Ganglia、JMX等。度量在etc/hadoop/hadoop-metrics.properties和etc/hadoop/hadoop-metrics2.properties中進行配置，該文件每一節對應一個上下文，並指定一個類來管理該上下文中的度量，這個類必須實現MetricsContext接口。CDHv1.0提供了幾個預約義的度量類，如表3-4所示。默認狀況下，全部上下文都被配置成不發佈狀態。
表3-4 CDH v1.0預約義的度量類

類名	說明
NullContext	不輸出也不更新度量
NullContextWithUpdateThread	輸出度量到本地文件，適合調試工做，不適合在生產環境中使用
GangliaContext	輸出到Ganglia，詳情參見下一節
NullContextWithUpdateThread	刷新但不輸出度量，可用於JMX
CompositeContext	可將多個度量接受組件輸出同一組度量

一些開源的集羣監控項目
可用於hadoop的集羣的分佈式監控系統不少，比較有名的有：

• Chukwa 一個基於HDFS和MapReduce的集羣監控系統，主要在日誌挖掘、大規模數據統計方面存在優點。
• Ganglia 一個正對超大規模集羣的開源分佈式監控系統，佔用資源少，界面美觀，可擴展性好。

CDHv1.0沒有包含集羣監控組件，但CDHv1.0兼容上述兩種開源監控系統，若是須要，請參考相關項目官方網站獲取技術支持。
預告：CDH v2.0將包含一個基於Web的部署、管理和監控服務組件。

3.2.3 平常維護

元數據備份
NameNode保存了HDFS的名字空間，若是哦NameNode上的數據丟失或損壞，將致使整個文件系統都沒法運行，所以，有必要對元數據進行備份。若是使用HDFS HA特性，HDFS元數據會自動備份和恢復，無需人工干預。若是沒有啓動HDFS HA特性，則須要手動備份和恢復元數據。
最簡單的元數據備份方法就是經過cron按期執行元數據備份腳本，將SecondaryNameNode節點的previous.checkpoint目錄打包複製到遠程站點下存儲。恢復時，首先，將備份的元數據歸檔文件將解壓到新的NameNode節點的數據目錄下(由dfs.namenode.name.dir配置)，而後，啓動NameNode加載備份數據，使HDFS上線工做。恢復前，可使用Offline Image Viewer工具檢查備份元數據的完整性。
說明：

• Cron的使用請參考下列網址: http://en.wikipedia.org/wiki/Cron
• Offline Image Viewer請參考下列網址: http://hadoop.apache.org/docs/hdfs/current/hdfs_imageviewer.html

數據備份
和全部存儲系統同樣，HDFS也沒法避免數據丟失的現象發生。HDFS雖然在設計時充分考慮了數據可靠性問題，可是HDFS的副本冗餘備份技術仍然沒法保證數據不會由於硬件故障、軟件bug等緣由而丟失，所以，仍然有必要對關鍵數據進行備份。
通常來講，對於業務數據，並不須要所有備份，只須要備份那些沒法從新得到的關鍵數據便可。數據備份的方式不少，如可使用HDFS的distcp工具將數據以分佈式的方式存儲到其餘HDFS集羣中。
系統維護
對於HDFS這樣的分佈式存儲系統，在運行過程當中不免會出現一些錯誤，形成數據損傷，所以，建議按期運行fsck工具對HDFS進行檢查，以儘早發現錯誤並及時糾正。按期運行負載均衡器有助於保持HDFS健康、持續高效的運行。
HDFS在運行過程當中會產生大量日誌，不按期清理這些日誌文件會致使磁盤空間的浪費。同時，過多的日誌文件和不恰當的日誌目錄設置(如設置在系統分區下)，可能致使系統運行異常，甚至沒法啓動。CDH v1.0引入了日誌清理功能，可按期檢查日誌目錄的大小，清除過時日誌，該功能在hdfs-site.xml中配置，具體配置項以下：
表3-5 日誌清理配置選項

配置項	配置說明
log.clean.scan.interval	定時掃描目錄的時間間隔，默認36000s;
log.clean.delete.uplimit	當目錄佔所在磁盤的比例在配置值之上將觸發一次清理操做，默認爲0.8(80%),
log.clean.delete.lowlimit	一次清理操做將是清理的目錄的磁盤佔有率降低到本項配置的比率之下，默認爲0.2(20%);
log.clean.monitor.dir	要監控並清理的目錄，多個目錄用逗號","隔開，默認爲空，這將致使LogCleaner啓動失敗。

注意：

• 日誌目錄清理功能目前只能在DataNode節點上使用
• 日誌目錄清理功能清理不限於HDFS的日誌，也能夠是其餘組件的日誌

添加節點
在CDH運行過程當中咱們可能須要向集羣添加節點以擴大集羣的容量，提升集羣的性能。對於HDFS，通常添加的節點都是做爲DataNode來運行的。下面的步驟說明如何向HDFS集羣添加DataNode節點。

• 將新節點的主機名添加到include文件中(include文件爲配置項dfs.hosts指向的文件)；
• 部署、配置新節點上的HDFS組件
• 運行dfsadmin -refreshNodes命令，使NameNode更新最新的DataNode列表:

$ bin/hdfs dfsadmin -refreshNodes

• 將新節點的主機名加入slaves文件中，以使HDFS控制腳本能控制這些節點；
• 在新節點上運行下列命令，啓動新的datanode：

$ bin/dfs datanode

• 經過dfsadmin –report命令或Web UI確認新節點是否已經加入集羣。

說明：若是新加入的節點不少，能夠在任何一臺節點上從新執行start-dfs.sh腳本便可啓動全部新節點上的DataNode，已啓動DataNode或NameNode的節點不會從新啓動。
注意：在爲HDFS添加節點以前，最好作一些審覈工做，已肯定加入的節點徹底屬於集羣控制之下。未經審覈的節點上可能會運行其餘集羣的組件，被其餘集羣控制，隨時都有可能斷開與HDFS集羣的鏈接，存在數據丟失的隱患。
解除節點
HDFS可以很好的應對少許DataNode故障的情形，這並不意味着能夠隨意關閉DataNode節點。若是關閉的DataNode個數超過HDFS配置的默認備份數，HDFS就有較大機率出現數據丟失(這個機率隨集羣規模的增大而減小)。所以，在非DataNode故障的狀況下關閉一個DataNode，最好先通知NameNode，以便其能在該節點停機前將數據轉移到其餘DataNode上。與添加節點對應，HDFS採用exclude文件來指定排除的節點(exclude文件爲dfs.hosts.exclude指定的文件)。解除節點的步驟以下：

• 將須要解除的節點主機名加入exclude文件中；
• 運行dfsadmin -refreshNodes命令，使NameNode更新最新的DataNode列表；
• 經過dfsadmin –report命令或Web UI查看待解除節點的狀態是否處於Decommission狀態，該狀態代表該節點正在轉移數據到其餘節點；
• 當待解除節點的狀態變爲Decommissioned時，說明數據已轉移，能夠任意關閉該節點；
• 從include文件中移除待解除節點的主機名，並使用dfsadmin -refreshNodes命令再次更新NameNode上的DataNode列表；
• 從slaves文件中移除這些節點，解除集羣對這些節點的控制。

須要注意的是，include文件和exclude文件可能出現衝突，有些節點既出如今include文件中，也出如今exclude文件中，HDFS經過節點在include文件和exclude文件的狀態來肯定DataNode所處的狀態，具體如表3-6所示。
表3-6 DataNode狀態

在include中	在exclude中	DataNode狀態
否	否	不屬於HDFS的節點或已經解除的節點
否	是	已經解除的節點(集羣重啓時)  將被解除的節點(集羣運行中解除節點)
是	否	通常節點
是	是	將被解除的節點