Hadoop2.6.0學(xué)習(xí)筆記（三）HDFS架構(gòu)

魯春利的工作筆記，誰說程序員不能有文藝范？

HDFS Architecture見：
http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
或下載的tar包解壓后的
hadoop-2.6.0/share/doc/hadoop/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

Hadoop分布式文件系統(tǒng)（Hadoop Distributed File System，簡稱HDFS）是一個分布式的文件系統(tǒng)，運行在廉價的硬件上。HDFS是高容錯的，被設(shè)計成在低成本硬件上部署，為應(yīng)用數(shù)據(jù)提供高吞吐量的訪問，適用于具有大規(guī)模數(shù)據(jù)集的應(yīng)用程序。

說明：分布式應(yīng)用中數(shù)據(jù)是分散在不同的機器上的，而通過分布式的文件系統(tǒng)，提供了統(tǒng)一的數(shù)據(jù)訪問方式，屏蔽了底層數(shù)據(jù)存儲位置的差異。

HDFS的設(shè)想和目標(biāo)
1、硬件故障
    在集中式環(huán)境下，總是假定機器是能夠穩(wěn)定持續(xù)運行的；而分布式環(huán)境恰恰相反，它認(rèn)為硬件錯誤是常態(tài)，而非異常情況。HDFS有成百上千的計算機節(jié)點組成，每個節(jié)點存儲部分?jǐn)?shù)據(jù)。大量的節(jié)點中，任意節(jié)點都有可能由于故障而無法提供服務(wù)，因此故障檢測，快速、自動的故障恢復(fù)是HDFS設(shè)計的核心架構(gòu)目標(biāo)。

2、流式數(shù)據(jù)訪問
    運行于HDFS之上的應(yīng)用程序需要以流式方式來進行數(shù)據(jù)集的讀取。HDFS不是為了通用的目的而設(shè)計的，它主要被設(shè)計用來實現(xiàn)批量數(shù)據(jù)處理，而非交互式的數(shù)據(jù)運算；高吞吐量的數(shù)據(jù)處理，而非低延遲的數(shù)據(jù)計算。

3、大數(shù)據(jù)集
    HDFS以支持大數(shù)據(jù)集合為目標(biāo)，一個存儲在上面的典型文件大小一般都在GB至TB，一個單一HDFS實例應(yīng)該能支撐數(shù)以千萬計的文件。

4、一致性模型
    HDFS應(yīng)用對文件要求的是write-one-read-many訪問模型。一個文件經(jīng)過創(chuàng)建、寫，關(guān)閉之后就不需要改變。這一假設(shè)簡化了數(shù)據(jù)一致性問題，使高吞吐量的數(shù)據(jù)訪問成為可能。

5、由移動數(shù)據(jù)到移動計算的轉(zhuǎn)移
    將計算移動到數(shù)據(jù)附近，比之將數(shù)據(jù)移動到應(yīng)用所在顯然更好，HDFS提供給應(yīng)用這樣的接口。

6、跨異構(gòu)硬件和軟件平臺的可移植性
    HDFS被設(shè)計成可輕易從一個平臺移動到另一個平臺。

HDFS Architecture
    HDFS采用主/從（master/slave）結(jié)構(gòu)，一個HDFS集群由一個NameNode（簡稱NN）節(jié)點和一定數(shù)量的DataNode（簡稱DN）節(jié)點組成。
    NN是HDFS集群的master server，是整個HDFS集群的核心，它管理HDFS集群的名稱空間，并接收客戶端的請求（具體請求還是由DN處理）。DN一般情況下每臺slave機器會配置一個，管理slave機器上存儲的數(shù)據(jù)。
    當(dāng)用戶上報數(shù)據(jù)時，數(shù)據(jù)以數(shù)據(jù)塊（Block）的形式存儲在數(shù)據(jù)節(jié)點上，一個文件可能被分割為一個或者多個數(shù)據(jù)塊。
    NN執(zhí)行文件系統(tǒng)的namespace操作，例如打開、關(guān)閉、重命名文件和目錄，同時維護了block到DN的映射關(guān)系。DN在NN的指揮下進行block的創(chuàng)建、刪除和復(fù)制，以及根據(jù)NN維護的block和DN的映射關(guān)系處理client的數(shù)據(jù)讀寫請求。

    說明：
        上述為單NN方式，NN存儲的是元數(shù)據(jù)信息，一旦出故障，那么整個HDFS集群就掛了。
        部署時一個主機可以同時配置NN和DN，也可以配置多個DN，但很少有人那么干。
        數(shù)據(jù)塊是有副本的，默認(rèn)為3，存儲為本機、同一機架內(nèi)機器、其他機架內(nèi)機器（機架感知）。
        Client端的讀寫請求都要先和NN打招呼，然后再通過DN真正干活。

HDFS Namespace
    HDFS支持傳統(tǒng)的層次型文件組織，與大多數(shù)其他文件系統(tǒng)類似，用戶可以創(chuàng)建目錄，并在其間創(chuàng)建、刪除、移動和重命名文件。HDFS不支持user quotas和訪問權(quán)限，也不支持鏈接（link)，不過當(dāng)前的架構(gòu)并不排除實現(xiàn)這些特性。Namenode維護文件系統(tǒng)的namespace，任何對文件系統(tǒng)namespace和文件屬性的修改都將被Namenode記錄下來。應(yīng)用可以設(shè)置HDFS保存的文件的副本數(shù)目，文件副本的數(shù)目稱為文件的 replication因子，這個信息也是由Namenode保存。
    說明：
        可以通過hdfs dfsadmin -setQuota可以對目錄進行限額。
        hdfs dfs -setrep可以動態(tài)調(diào)整副本數(shù)目。
        hdfs上任何的操作都會記錄在edits日志文件中，由參數(shù)dfs.namenode.edits.dir指定存放路徑。

HDFS Data Replication
    HDFS被設(shè)計成在一個大集群中可以跨機器地可靠地存儲海量的文件。它將每個文件存儲成block序列，除了最后一個block，所有的block都是同樣的大小。文件的所有block為了容錯都會被復(fù)制。每個文件的block大小和replication因子都是可配置的。Replication因子可以在文件創(chuàng)建的時候配置，以后也可以改變。
    HDFS中的文件是write-one，并且嚴(yán)格要求在任何時候只有一個writer。Namenode全權(quán)管理block的復(fù)制，它周期性地從集群中的每個Datanode接收心跳包和一個Blockreport。心跳包的接收表示該Datanode節(jié)點正常工作，而Blockreport包括了該Datanode上所有的block組成的列表。

1、副本存放
    默認(rèn)情況下，replication因子是3，HDFS的存放策略是第一個副本存放在client連接到的DN節(jié)點，一個副本放在同一機架上的另一個節(jié)點，最后一個副本放在不同機架上的一個節(jié)點。
    說明：
        HDFS的機架感知不是自適應(yīng)的，需要管理人員進行配置。
2、副本選擇
    為了降低整體的帶寬消耗和讀延時，HDFS會盡量讓reader讀最近的副本。
3、安全模式
     Namenode啟動時會進入一個稱為Safemode的特殊狀態(tài)，處在這個狀態(tài)的Namenode是不會進行數(shù)據(jù)塊的復(fù)制的。
    Namenode從所有的Datanode接收心跳包和Blockreport。Blockreport包括了某個Datanode所有的數(shù)據(jù)塊列表。
    每個block都有指定的最小數(shù)目的副本（dfs.namenode.replication.min），當(dāng)Namenode確認(rèn)了某個數(shù)據(jù)塊副本的最小數(shù)目，那么該block被認(rèn)為是安全的。
    如果一定百分比（dfs.namenode.safemode.threshold-pct）的數(shù)據(jù)塊檢測確認(rèn)是安全的，那么Namenode將退出Safemode狀態(tài)，接下來它會確定還有哪些數(shù)據(jù)塊的副本沒有達到指定數(shù)目，并將這些block復(fù)制到其他Datanode。

文件系統(tǒng)元數(shù)據(jù)的持久化
    NN存儲HDFS Namespace的元數(shù)據(jù)，任何對文件元數(shù)據(jù)的修改操作，NN都使用一個稱為Editlog的事務(wù)日志記錄下來。例如，在HDFS中創(chuàng)建一個文件，NN會在Editlog中插入一條記錄來表示；同樣，修改文件的replication因子也將往Editlog中插入一條記錄。NN在本地OS的文件系統(tǒng)上存儲Editlog文件，整個文件系統(tǒng)的namespace，包括block到文件的映射、文件的屬性，都存儲在稱為FsImage的文件中，這個文件也是存放在NN所在的文件系統(tǒng)上。
    NN在內(nèi)存中保存者整個文件系統(tǒng)namespace和文件Blockmap的映射，一個4G內(nèi)存的NN足夠支持海量的文件和目錄。當(dāng)NN啟動時，它從硬盤讀取Editlog和FsImage，講所有Editlog中的事務(wù)作用于FsImage文件，并將新版本的FsImage從內(nèi)存中flush到硬盤上，然后再truncate這舊的Editlog，因為這個舊的Editlog已經(jīng)被作用到FsImage上了，該過程稱為checkpoint。
    DN講文件保存在本地的文件系統(tǒng)上，但是它并知道關(guān)于文件的任何信息。DN不會在一個目錄中存放所有文件，相反，它用啟發(fā)式的方法來確定每個目錄中的最佳文件數(shù)目，并且在適當(dāng)?shù)臅r候創(chuàng)建子目錄。當(dāng)一個DN啟動時，它掃描本地文件系統(tǒng)，對這些本地文件產(chǎn)生相應(yīng)的一個所有HDFS數(shù)據(jù)塊的列表，然后發(fā)送報告到DN，這個報告就是BlockReport。

通信協(xié)議
    所有的HDFS通信協(xié)議都是構(gòu)建于TCP/IP協(xié)議之上?？蛻舳送ㄟ^一個可配置的端口與NN通信，通過ClientProtocol與NN通信；而DN使用DatanodeProtocol與NN通信。ClientProtocol與DatanodeProtocol協(xié)議都是基于RPC協(xié)議進行的封裝。在HDFS的設(shè)計中，NN不會主動發(fā)起RPC，而只是被動響應(yīng)DN和Client端的請求。

健壯性
    HDFS的主要目標(biāo)就是實現(xiàn)在失敗情況下數(shù)據(jù)存儲可靠性，常見的三種失敗為：NN failure、DN failure和網(wǎng)絡(luò)分割（network partition）。
   （1）硬盤數(shù)據(jù)錯誤、心跳檢測和重新復(fù)制
    DN定期向NN發(fā)送心跳信息，但是網(wǎng)絡(luò)切割可能導(dǎo)致部分DN失去與NN的連接。NN通過心跳包的缺失檢測到這一情況，將這些DN標(biāo)記為dead，不會再將新的IO請求發(fā)給它們。HDFS將無法再訪問處于dead狀態(tài)的DN上存儲的數(shù)據(jù)，因此一些block的副本數(shù)將低于配置的閥值。NN不斷跟蹤需要復(fù)制的數(shù)據(jù)塊，并在任何需要的時候啟動復(fù)制。在下述情況下可能觸發(fā)重新復(fù)制：DN失效、某個block損壞、DN節(jié)點磁盤錯誤或者副本因子增加。

   （2）集群均衡
    HDFS集群的自動均衡計劃，即當(dāng)DN節(jié)點的磁盤空間不足時自動將數(shù)據(jù)移動到其他節(jié)點，或者當(dāng)某個文件的請求數(shù)突然增加時， 復(fù)制數(shù)據(jù)到集群中的其他節(jié)點已滿足應(yīng)用需求，但該機制暫未實現(xiàn)。

   （3）數(shù)據(jù)完整性
    由于客戶端訪問時，由于存儲設(shè)備故障、網(wǎng)絡(luò)故障或者軟件BUG，都有可能導(dǎo)致數(shù)據(jù)塊損壞，HDFS實現(xiàn)了數(shù)據(jù)內(nèi)容校驗和，當(dāng)讀取數(shù)據(jù)時會自動檢驗數(shù)據(jù)塊的完整性，若存在問題，會嘗試從其他DN讀取數(shù)據(jù)。

   （4）元數(shù)據(jù)磁盤錯誤
    FsImage和Editlog是HDFS的核心數(shù)據(jù)結(jié)構(gòu)，它們的損壞將導(dǎo)致整個HDFS集群不可使用。因此，NN可以配置為FsImage和Editlog存儲多個副本（dfs.namenode.name.dir配置以逗號分割的多個路徑），所有的操作都會對多個副本同步更新。

    說明：
        NN在HDFS集群中存在單獨故障（SPOF）問題。當(dāng)NN節(jié)點失敗時，如果沒有配置HA則必須進行人工處理，或者講NN配置為HA模式。

   （5）快照
    HDFS does not currently support snapshots but will in a future release.

NameNode

    NN節(jié)點數(shù)據(jù)在本地存儲的位置由hdfs-site.xml文件中參數(shù)${dfs.namenode.name.dir}指定。

<property>
        <name>dfs.namenode.name.dir</name>
        <value>/usr/local/hadoop2.6.0/data/dfs/name</value>
</property>

    查看${dfs.namenode.name.dir}目錄：

[hadoop@nnode name]$ pwd
/usr/local/hadoop2.6.0/data/dfs/name
[hadoop@nnode name]$ ls
current
[hadoop@nnode name]$

    在第一次部署好Hadoop集群之后，需要在NN節(jié)點上格式化磁盤：

    $HADOOP_HOME/bin/hdfs namenode -format

    格式化完成后會在${dfs.namenode.name.dir}/current目錄下生成如下目錄結(jié)構(gòu)：

    current目錄下有四類文件：

        事務(wù)日志記錄文件（edits）；

        文件系統(tǒng)映像（fsp_w_picpath）；

        當(dāng)前文件系統(tǒng)映像應(yīng)用過的事務(wù)號（seen_txid）；

        VERSION文件。

[hadoop@nnode current]$ ll -h
-rw-rw-r-- 1 hadoop hadoop   42 Nov 21 17:21 edits_0000000000000035252-0000000000000035253
-rw-rw-r-- 1 hadoop hadoop   42 Nov 21 17:23 edits_0000000000000035254-0000000000000035255
-rw-rw-r-- 1 hadoop hadoop   42 Nov 21 17:25 edits_0000000000000035256-0000000000000035257
-rw-rw-r-- 1 hadoop hadoop   42 Nov 21 17:27 edits_0000000000000035258-0000000000000035259
-rw-rw-r-- 1 hadoop hadoop   42 Nov 21 17:28 edits_0000000000000035260-0000000000000035261
-rw-rw-r-- 1 hadoop hadoop 231K Nov 21 22:29 fsp_w_picpath_0000000000000035842
-rw-rw-r-- 1 hadoop hadoop   62 Nov 21 22:29 fsp_w_picpath_0000000000000035842.md5
-rw-rw-r-- 1 hadoop hadoop 231K Nov 21 23:29 fsp_w_picpath_0000000000000035930
-rw-rw-r-- 1 hadoop hadoop   62 Nov 21 23:29 fsp_w_picpath_0000000000000035930.md5
-rw-rw-r-- 1 hadoop hadoop    6 Nov 21 17:27 seen_txid
-rw-rw-r-- 1 hadoop hadoop  204 Nov 21 23:29 VERSION

    VERSION文件是屬性文件：

[hadoop@nnode current]$ cat VERSION 
#Sat Nov 21 23:29:03 CST 2015
# 文件系統(tǒng)唯一標(biāo)識,首次format時設(shè)置，DN注冊到NN之前是不知道該值的，可以區(qū)分新建的DN
namespaceID=339614018
# Cluster標(biāo)識，DN與這里的需要一致
clusterID=CID-61347f43-0510-4b07-ad99-956472c0e49f
# NN存儲的創(chuàng)建時間，當(dāng)NN升級后，該值會更新
cTime=0
# 存儲類型（DATA_NOME/NAME_NODE）
storageType=NAME_NODE
# block pool標(biāo)識，后續(xù)再介紹（192.168.1.117是原來配置的IP地址，后臺改成192.168.137.117了）
blockpoolID=BP-892593412-192.168.1.117-1431598212853
# 用一個負(fù)整數(shù)來表示HDFS永久數(shù)據(jù)結(jié)構(gòu)的版本號
layoutVersion=-60
[hadoop@nnode current]$

    seen_txid是記錄事務(wù)ID的文件，format之后是0，表示NN里面edit-*文件的尾數(shù)，事務(wù)最后一次被應(yīng)用到fsp_w_picpath的id。

-rw-rw-r-- 1 hadoop hadoop      42 Nov 21 17:27 edits_0000000000000035258-0000000000000035259
-rw-rw-r-- 1 hadoop hadoop      42 Nov 21 17:28 edits_0000000000000035260-0000000000000035261
-rw-rw-r-- 1 hadoop hadoop  236143 Nov 21 22:29 fsp_w_picpath_0000000000000035842
-rw-rw-r-- 1 hadoop hadoop      62 Nov 21 22:29 fsp_w_picpath_0000000000000035842.md5
-rw-rw-r-- 1 hadoop hadoop  236027 Nov 21 23:29 fsp_w_picpath_0000000000000035930
-rw-rw-r-- 1 hadoop hadoop      62 Nov 21 23:29 fsp_w_picpath_0000000000000035930.md5
-rw-rw-r-- 1 hadoop hadoop       6 Nov 21 17:27 seen_txid
-rw-rw-r-- 1 hadoop hadoop     204 Nov 21 23:29 VERSION
[hadoop@nnode current]$ cat seen_txid 
35260
[hadoop@nnode current]$

    edits文件為NN保存的事務(wù)日志文件，存儲位置由${dfs.namenode.edits.dir}指定，默認(rèn)取NN節(jié)點數(shù)據(jù)文件位置${dfs.namenode.name.dir}。

    fsp_w_picpath文件存儲的是NN節(jié)點的元數(shù)據(jù)文件。

    說明：

        當(dāng)namenode -format命令執(zhí)行的時候，在namenode節(jié)點和datanode節(jié)點的VERSION中都會產(chǎn)生一個namespaceID值，并且這兩個值必須相同。如果再次執(zhí)行格式化，那么namenode會產(chǎn)生一個新的namespaceID，但是datanode不會產(chǎn)生新的值。

    示例一：查看edits文件

bin/hdfs oev -i edits_0000000000000000057-0000000000000000186   -o edits.xml

    示例二：查看fsp_w_picpath文件

bin/hdfs oiv -p XML -i fsp_w_picpath_0000000000000000055  -o fsp_w_picpath.xml

DataNode

    DN節(jié)點數(shù)據(jù)的存儲位置也是通過hdfs-site.xml文件進行配置：

<property>
         <name>dfs.datanode.data.dir</name>
         <value>/usr/local/hadoop2.6.0/data/dfs/data</value>
</property>

    DN節(jié)點數(shù)據(jù)存儲結(jié)構(gòu)：

/usr/local/hadoop2.6.0/data/dfs/data
|---current
|------BP-892593412-192.168.1.117-1431598212853
|-------current
|---------------dfsUsed
|-------------------168801504 1448121566578
|---------------finalized
|-------------------subdir0
|-----------------------subdir0  subdir1  subdir10  subdir11  subdir2  ......  subdir9（目錄）
|-------------------------  -rw-rw-r-- 1 hadoop hadoop 1377 Nov 21 16:53 blk_1073744377
|-------------------------  -rw-rw-r-- 1 hadoop hadoop   19 Nov 21 16:53 blk_1073744377_3560.meta
|-------------------------  -rw-rw-r-- 1 hadoop hadoop 1438 Nov 21 16:53 blk_1073744378
|-------------------------  -rw-rw-r-- 1 hadoop hadoop   19 Nov 21 16:53 blk_1073744378_3561.meta
|-------------------------  -rw-rw-r-- 1 hadoop hadoop 1671 Nov 21 16:53 blk_1073744379
|-------------------------  -rw-rw-r-- 1 hadoop hadoop   23 Nov 21 16:53 blk_1073744379_3562.meta
|---------------rbw(空目錄)
|---------------VERSION
|-------------------#Sat Nov 28 12:03:36 CST 2015
|-------------------namespaceID=339614018
|-------------------cTime=0
|-------------------blockpoolID=BP-892593412-192.168.1.117-1431598212853
|-------------------layoutVersion=-56
|-----------dncp_block_verification.log.curr
|-----------dncp_block_verification.log.prev
|-----------tmp(空目錄)----------------
|-------VERSION
|-----------#Sat Nov 28 12:03:36 CST 2015
|-----------storageID=DS-e1bf6500-fc2f-4e73-bfe7-5712c9818965
|-----------clusterID=CID-61347f43-0510-4b07-ad99-956472c0e49f
|-----------cTime=0
|-----------datanodeUuid=33c2f4cb-cd26-4530-9d9b-40d0b748f8b8
|-----------storageType=DATA_NODE
|-----------layoutVersion=-56
|---in_use.lock
|-------14187(對應(yīng)的DataNode進程的進程號，可通過ps -ef|grep DataNode查看)

通過hdfs命令上傳一個文件到hdfs：

[hadoop@dnode1 subdir0]$ ll -h ~/httpdomainscan_192.168.1.101_0_20130913160407.hsl 
-rwxrwxr-x 1 hadoop hadoop 180M Nov 28 12:06 /home/hadoop/httpdomainscan_192.168.1.101_0_20130913160407.hsl

在DN節(jié)點目錄current/finalized/subdir0/subdir14下能看到新創(chuàng)建了兩個bock塊：

-rw-rw-r-- 1 hadoop hadoop 128M Nov 28 12:12 blk_1073745442
-rw-rw-r-- 1 hadoop hadoop 1.1M Nov 28 12:12 blk_1073745442_4628.meta
-rw-rw-r-- 1 hadoop hadoop  52M Nov 28 12:12 blk_1073745443
-rw-rw-r-- 1 hadoop hadoop 411K Nov 28 12:12 blk_1073745443_4629.meta

    說明：

        HDFS中block塊的大小固定為128M，但是當(dāng)一個數(shù)據(jù)文件的大小不足一個塊大小時，按實際大小分配空間。

        我的HDFS集群有兩個DN節(jié)點，副本的參數(shù)配置的為2，因此在主機dnode1和dnode2的subdir14目錄下都新創(chuàng)建了兩個節(jié)點。

NN節(jié)點edits文件

# 此時多了一個edits_inprogress_0000000000000036000的文件
-rw-rw-r-- 1 hadoop hadoop   42 Nov 21 17:28 edits_0000000000000035260-0000000000000035261
-rw-rw-r-- 1 hadoop hadoop 1.0M Nov 28 13:31 edits_inprogress_0000000000000036000
-rw-rw-r-- 1 hadoop hadoop 231K Nov 21 22:29 fsp_w_picpath_0000000000000035842
-rw-rw-r-- 1 hadoop hadoop   62 Nov 21 22:29 fsp_w_picpath_0000000000000035842.md5
-rw-rw-r-- 1 hadoop hadoop 231K Nov 21 23:29 fsp_w_picpath_0000000000000035930
-rw-rw-r-- 1 hadoop hadoop   62 Nov 21 23:29 fsp_w_picpath_0000000000000035930.md5
-rw-rw-r-- 1 hadoop hadoop    6 Nov 21 17:27 seen_txid
-rw-rw-r-- 1 hadoop hadoop  204 Nov 21 23:29 VERSION

    再次查看：

# 多了兩個事務(wù)日志，且seen_txid也更新了（36002）
-rw-rw-r-- 1 hadoop hadoop      42 Nov 21 17:28 edits_0000000000000035260-0000000000000035261
-rw-rw-r-- 1 hadoop hadoop      42 Nov 28 13:55 edits_0000000000000036000-0000000000000036001
-rw-rw-r-- 1 hadoop hadoop      42 Nov 28 13:56 edits_0000000000000036002-0000000000000036003
-rw-rw-r-- 1 hadoop hadoop  236143 Nov 21 22:29 fsp_w_picpath_0000000000000035842
-rw-rw-r-- 1 hadoop hadoop      62 Nov 21 22:29 fsp_w_picpath_0000000000000035842.md5
-rw-rw-r-- 1 hadoop hadoop  236027 Nov 21 23:29 fsp_w_picpath_0000000000000035930
-rw-rw-r-- 1 hadoop hadoop      62 Nov 21 23:29 fsp_w_picpath_0000000000000035930.md5
-rw-rw-r-- 1 hadoop hadoop       6 Nov 28 13:55 seen_txid
-rw-rw-r-- 1 hadoop hadoop     204 Nov 21 23:29 VERSION

    查看DN節(jié)點元數(shù)據(jù)信息：

hdfs oiv -p XML -i fsp_w_picpath_0000000000000035842 -o fsp_w_picpath.xml

    下載到本地并打開：

    到DN節(jié)點查找ID為1073741829的數(shù)據(jù)塊文件：

# cd current/finalized/subdir0
[hadoop@dnode1 subdir0]$ find . -name "*1073741829*.meta"
./subdir0/blk_1073741829_1008.meta

[hadoop@dnode1 subdir0]$ cd subdir0
[hadoop@dnode1 subdir0]$ ll|grep 1073741829
-rw-rw-r-- 1 hadoop hadoop       63 May 27  2015 blk_1073741829
-rw-rw-r-- 1 hadoop hadoop       11 May 27  2015 blk_1073741829_1008.meta
[hadoop@dnode1 subdir0]$ cat blk_1073741829
hello world!
lucl123456\r\nceshi\r\n123456\r\n
ceshi
123456

[hadoop@dnode1 subdir0]$ hdfs dfs -cat lucl.txt
hello world!
lucl123456\r\nceshi\r\n123456\r\n
ceshi
123456
[hadoop@dnode1 subdir0]$

    備注：上傳了一個hsl文件，但是從edits中未看到日志記錄，另外就是fsp_w_picpath一直修改時間一直不變。

    間隔一段時間后再查看current目錄：

-rw-rw-r-- 1 hadoop hadoop      42 Nov 28 19:38 edits_0000000000000036294-0000000000000036295
-rw-rw-r-- 1 hadoop hadoop      42 Nov 28 19:40 edits_0000000000000036296-0000000000000036297
-rw-rw-r-- 1 hadoop hadoop 1048576 Nov 28 19:40 edits_inprogress_0000000000000036298
-rw-rw-r-- 1 hadoop hadoop  235504 Nov 28 18:08 fsp_w_picpath_0000000000000036205
-rw-rw-r-- 1 hadoop hadoop      62 Nov 28 18:08 fsp_w_picpath_0000000000000036205.md5
-rw-rw-r-- 1 hadoop hadoop  235504 Nov 28 19:08 fsp_w_picpath_0000000000000036263
-rw-rw-r-- 1 hadoop hadoop      62 Nov 28 19:08 fsp_w_picpath_0000000000000036263.md5
-rw-rw-r-- 1 hadoop hadoop       6 Nov 28 19:40 seen_txid
-rw-rw-r-- 1 hadoop hadoop     204 Nov 21 23:29 VERSION

    查看edits文件：

<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
  <EDITS_VERSION>-60</EDITS_VERSION>
  <RECORD>
    <OPCODE>OP_START_LOG_SEGMENT</OPCODE>
    <DATA>
      <TXID>36029</TXID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_TIMES</OPCODE>
    <DATA>
      <TXID>36030</TXID>
      <LENGTH>0</LENGTH>
      <PATH>/user/hadoop/lucl.txt</PATH>
      <MTIME>-1</MTIME>
      <ATIME>1448694798698</ATIME>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_END_LOG_SEGMENT</OPCODE>
    <DATA>
      <TXID>36031</TXID>
    </DATA>
  </RECORD>
</EDITS>

    查看fsp_w_picpath文件：

<inode>
    <id>20980</id>
    <type>FILE</type>
    <name>httpdomainscan_192.168.1.101_0_20130913160407.hsl</name>
    <replication>2</replication>
    <mtime>1448683960850</mtime>
    <atime>1448683943208</atime>
    <perferredBlockSize>134217728</perferredBlockSize>
    <permission>hadoop:hadoop:rw-r--r--</permission>
    <blocks>
        <block>
            <id>1073745442</id>
            <genstamp>4628</genstamp>
            <numBytes>134217728</numBytes>
        </block>
        <block>
            <id>1073745443</id>
            <genstamp>4629</genstamp>
            <numBytes>53807068</numBytes>
        </block>
    </blocks>
</inode>

    說明：通過fsp_w_picpath能夠了解到文件與數(shù)據(jù)塊的關(guān)系，但是無法知道數(shù)據(jù)庫與節(jié)點的關(guān)系。

org.apache.hadoop.hdfs.server.namenode.NameNode

 * NameNode serves as both directory namespace manager and
 * "inode table" for the Hadoop DFS.  There is a single NameNode
 * running in any DFS deployment.  (Well, except when there
 * is a second backup/failover NameNode, or when using federated NameNodes.)
 *
 * The NameNode controls two critical tables:
 *   1)  filename->blocksequence (namespace)
 *   2)  block->machinelist ("inodes")
 *
 * The first table is stored on disk and is very precious.
 * The second table is rebuilt every time the NameNode comes up.

啟動過程會讀取fsp_w_picpath文件：

    NN在啟動時會去加載fsp_w_picpath中的數(shù)據(jù)，構(gòu)造元數(shù)據(jù)結(jié)構(gòu)。

    在啟動的過程中會處于safemode模式，此時HDFS的數(shù)據(jù)是不看操作的，默認(rèn)時間是30秒。

    啟動成功后sfaemode會被關(guān)閉

    NN節(jié)點顯示已啟動