1、HDFS簡介
HDFS（Hadoop Distributed File System）是Hadoop項目的核心子項目，是分佈式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用服務器上。它所具有的高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率等特徵爲海量數據提供了不怕故障的存儲，爲超大數據集（Large Data Set）的應用處理帶來了很多便利。
Hadoop整合了衆多文件系統，在其中有一個綜合性的文件系統抽象，它提供了文件系統實現的各類接口，HDFS只是這個抽象文件系統的一個實例。提供了一個高層的文件系統抽象類org.apache.hadoop.fs.FileSystem，這個抽象類展示了一個分佈式文件系統，並有幾個具體實現，如下表1-1所示。
表1-1 Hadoop的文件系統
|
文件系統 |
URI方案 |
Java實現 （org.apache.hadoop） |
定義 |
|
Local |
file |
fs.LocalFileSystem |
支持有客戶端校驗和本地文件系統。帶有校驗和的本地系統文件在fs.RawLocalFileSystem中實現。 |
|
HDFS |
hdfs |
hdfs.DistributionFileSystem |
Hadoop的分佈式文件系統。 |
|
HFTP |
hftp |
hdfs.HftpFileSystem |
支持通過HTTP方式以只讀的方式訪問HDFS，distcp經常用在不同的HDFS集羣間複製數據。 |
|
HSFTP |
hsftp |
hdfs.HsftpFileSystem |
支持通過HTTPS方式以只讀的方式訪問HDFS。 |
|
HAR |
har |
fs.HarFileSystem |
構建在Hadoop文件系統之上，對文件進行歸檔。Hadoop歸檔文件主要用來減少NameNode的內存使用。 |
|
KFS |
kfs |
fs.kfs.KosmosFileSystem |
Cloudstore（其前身是Kosmos文件系統）文件系統是類似於HDFS和Google的GFS文件系統，使用C++編寫。 |
|
FTP |
ftp |
fs.ftp.FtpFileSystem |
由FTP服務器支持的文件系統。 |
|
S3（本地） |
s3n |
fs.s3native.NativeS3FileSystem |
基於Amazon S3的文件系統。 |
|
S3（基於塊） |
s3 |
fs.s3.NativeS3FileSystem |
基於Amazon S3的文件系統，以塊格式存儲解決了S3的5GB文件大小的限制。 |
Hadoop提供了許多文件系統的接口，用戶可以使用URI方案選取合適的文件系統來實現交互。
2、HDFS基礎概念
2.1 數據塊（block）
-
HDFS(Hadoop Distributed File System)默認的最基本的存儲單位是64M的數據塊。
-
和普通文件系統相同的是，HDFS中的文件是被分成64M一塊的數據塊存儲的。
-
不同於普通文件系統的是，HDFS中，如果一個文件小於一個數據塊的大小，並不佔用整個數據塊存儲空間。
2.2 NameNode和DataNode
HDFS體系結構中有兩類節點，一類是NameNode，又叫"元數據節點"；另一類是DataNode，又叫"數據節點"。這兩類節點分別承擔Master和Worker具體任務的執行節點。
1）元數據節點用來管理文件系統的命名空間
-
其將所有的文件和文件夾的元數據保存在一個文件系統樹中。
-
這些信息也會在硬盤上保存成以下文件：命名空間鏡像(namespace image)及修改日誌(edit log)
-
其還保存了一個文件包括哪些數據塊，分佈在哪些數據節點上。然而這些信息並不存儲在硬盤上，而是在系統啓動的時候從數據節點收集而成的。
2）數據節點是文件系統中真正存儲數據的地方。
-
客戶端(client)或者元數據信息(namenode)可以向數據節點請求寫入或者讀出數據塊。
-
其週期性的向元數據節點回報其存儲的數據塊信息。
3）從元數據節點（secondary namenode）
-
從元數據節點並不是元數據節點出現問題時候的備用節點，它和元數據節點負責不同的事情。
-
其主要功能就是週期性將元數據節點的命名空間鏡像文件和修改日誌合併，以防日誌文件過大。這點在下面會相信敘述。
-
合併過後的命名空間鏡像文件也在從元數據節點保存了一份，以防元數據節點失敗的時候，可以恢復。
2.3 元數據節點目錄結構
VERSION文件是java properties文件，保存了HDFS的版本號。
-
layoutVersion是一個負整數，保存了HDFS的持續化在硬盤上的數據結構的格式版本號。
-
namespaceID是文件系統的唯一標識符，是在文件系統初次格式化時生成的。
-
cTime此處爲0
-
storageType表示此文件夾中保存的是元數據節點的數據結構。
namespaceID=1232737062
cTime=0
storageType=NAME_NODE
layoutVersion=-18
2.4 數據節點的目錄結構
-
數據節點的VERSION文件格式如下：
namespaceID=1232737062
storageID=DS-1640411682-127.0.1.1-50010-1254997319480
cTime=0
storageType=DATA_NODE
layoutVersion=-18
-
blk_<id>保存的是HDFS的數據塊，其中保存了具體的二進制數據。
-
blk_<id>.meta保存的是數據塊的屬性信息：版本信息，類型信息，和checksum
-
當一個目錄中的數據塊到達一定數量的時候，則創建子文件夾來保存數據塊及數據塊屬性信息。
2.5 文件系統命名空間映像文件及修改日誌
-
當文件系統客戶端(client)進行寫操作時，首先把它記錄在修改日誌中(edit log)
-
元數據節點在內存中保存了文件系統的元數據信息。在記錄了修改日誌後，元數據節點則修改內存中的數據結構。
-
每次的寫操作成功之前，修改日誌都會同步(sync)到文件系統。
-
fsimage文件，也即命名空間映像文件，是內存中的元數據在硬盤上的checkpoint，它是一種序列化的格式，並不能夠在硬盤上直接修改。
-
同數據的機制相似，當元數據節點失敗時，則最新checkpoint的元數據信息從fsimage加載到內存中，然後逐一重新執行修改日誌中的操作。
-
從元數據節點就是用來幫助元數據節點將內存中的元數據信息checkpoint到硬盤上的
-
checkpoint的過程如下：
-
從元數據節點通知元數據節點生成新的日誌文件，以後的日誌都寫到新的日誌文件中。
-
從元數據節點用http get從元數據節點獲得fsimage文件及舊的日誌文件。
-
從元數據節點將fsimage文件加載到內存中，並執行日誌文件中的操作，然後生成新的fsimage文件。
-
從元數據節點獎新的fsimage文件用http post傳回元數據節點
-
元數據節點可以將舊的fsimage文件及舊的日誌文件，換爲新的fsimage文件和新的日誌文件(第一步生成的)，然後更新fstime文件，寫入此次checkpoint的時間。
-
這樣元數據節點中的fsimage文件保存了最新的checkpoint的元數據信息，日誌文件也重新開始，不會變的很大了。
-
3、HDFS體系結構
HDFS是一個主/從（Mater/Slave）體系結構，從最終用戶的角度來看，它就像傳統的文件系統一樣，可以通過目錄路徑對文件執行CRUD（Create、Read、Update和Delete）操作。但由於分佈式存儲的性質，HDFS集羣擁有一個NameNode和一些DataNode。NameNode管理文件系統的元數據，DataNode存儲實際的數據。客戶端通過同NameNode和DataNodes的交互訪問文件系統。客戶端聯繫NameNode以獲取文件的元數據，而真正的文件I/O操作是直接和DataNode進行交互的。
圖3.1 HDFS總體結構示意圖
1）NameNode、DataNode和Client
-
NameNode可以看作是分佈式文件系統中的管理者，主要負責管理文件系統的命名空間、集羣配置信息和存儲塊的複製等。NameNode會將文件系統的Meta-data存儲在內存中，這些信息主要包括了文件信息、每一個文件對應的文件塊的信息和每一個文件塊在DataNode的信息等。
-
DataNode是文件存儲的基本單元，它將Block存儲在本地文件系統中，保存了Block的Meta-data，同時週期性地將所有存在的Block信息發送給NameNode。
-
Client就是需要獲取分佈式文件系統文件的應用程序。
2）文件寫入
-
Client向NameNode發起文件寫入的請求。
-
NameNode根據文件大小和文件塊配置情況，返回給Client它所管理部分DataNode的信息。
-
Client將文件劃分爲多個Block，根據DataNode的地址信息，按順序寫入到每一個DataNode塊中。
3）文件讀取
-
Client向NameNode發起文件讀取的請求。
-
NameNode返回文件存儲的DataNode的信息。
-
Client讀取文件信息。
HDFS典型的部署是在一個專門的機器上運行NameNode，集羣中的其他機器各運行一個DataNode；也可以在運行NameNode的機器上同時運行DataNode，或者一臺機器上運行多個DataNode。一個集羣只有一個NameNode的設計大大簡化了系統架構。
4、HDFS的優缺點
4.1 HDFS的優點
1）處理超大文件
這裏的超大文件通常是指百MB、設置數百TB大小的文件。目前在實際應用中，HDFS已經能用來存儲管理PB級的數據了。
2）流式的訪問數據
HDFS的設計建立在更多地響應"一次寫入、多次讀寫"任務的基礎上。這意味着一個數據集一旦由數據源生成，就會被複製分發到不同的存儲節點中，然後響應各種各樣的數據分析任務請求。在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說，請求讀取整個數據集要比讀取一條記錄更加高效。
3）運行於廉價的商用機器集羣上
Hadoop設計對硬件需求比較低，只須運行在低廉的商用硬件集羣上，而無需昂貴的高可用性機器上。廉價的商用機也就意味着大型集羣中出現節點故障情況的概率非常高。這就要求設計HDFS時要充分考慮數據的可靠性，安全性及高可用性。
4.2 HDFS的缺點
1）不適合低延遲數據訪問
如果要處理一些用戶要求時間比較短的低延遲應用請求，則HDFS不適合。HDFS是爲了處理大型數據集分析任務的，主要是爲達到高的數據吞吐量而設計的，這就可能要求以高延遲作爲代價。
改進策略：對於那些有低延時要求的應用程序，HBase是一個更好的選擇。通過上層數據管理項目來儘可能地彌補這個不足。在性能上有了很大的提升，它的口號就是goes real time。使用緩存或多master設計可以降低client的數據請求壓力，以減少延時。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延時了，HDFS不是萬能的銀彈。
2）無法高效存儲大量小文件
因爲Namenode把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是由Namenode的內存大小來決定。一般來說，每一個文件、文件夾和Block需要佔據150字節左右的空間，所以，如果你有100萬個文件，每一個佔據一個Block，你就至少需要300MB內存。當前來說，數百萬的文件還是可行的，當擴展到數十億時，對於當前的硬件水平來說就沒法實現了。還有一個問題就是，因爲Map task的數量是由splits來決定的，所以用MR處理大量的小文件時，就會產生過多的Maptask，線程管理開銷將會增加作業時間。舉個例子，處理10000M的文件，若每個split爲1M，那就會有10000個Maptasks，會有很大的線程開銷；若每個split爲100M，則只有100個Maptasks，每個Maptask將會有更多的事情做，而線程的管理開銷也將減小很多。
改進策略：要想讓HDFS能處理好小文件，有不少方法。
-
利用SequenceFile、MapFile、Har等方式歸檔小文件，這個方法的原理就是把小文件歸檔起來管理，HBase就是基於此的。對於這種方法，如果想找回原來的小文件內容，那就必須得知道與歸檔文件的映射關係。
-
橫向擴展，一個Hadoop集羣能管理的小文件有限，那就把幾個Hadoop集羣拖在一個虛擬服務器後面，形成一個大的Hadoop集羣。google也是這麼幹過的。
-
多Master設計，這個作用顯而易見了。正在研發中的GFS II也要改爲分佈式多Master設計，還支持Master的Failover，而且Block大小改爲1M，有意要調優處理小文件啊。
-
附帶個Alibaba DFS的設計，也是多Master設計，它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節點和一個查詢Master節點組成。
3）不支持多用戶寫入及任意修改文件
在HDFS的一個文件中只有一個寫入者，而且寫操作只能在文件末尾完成，即只能執行追加操作。目前HDFS還不支持多個用戶對同一文件的寫操作，以及在文件任意位置進行修改。
5、HDFS常用操作
先說一下"hadoop fs 和hadoop dfs的區別"，看兩本Hadoop書上各有用到，但效果一樣，求證與網絡發現下面一解釋比較中肯。
粗略的講，fs是個比較抽象的層面，在分佈式環境中，fs就是dfs，但在本地環境中，fs是local file system，這個時候dfs就不能用。
5.1 文件操作
1）列出HDFS文件
此處爲你展示如何通過"-ls"命令列出HDFS下的文件：
hadoop fs -ls
執行結果如圖5-1-1所示。在這裏需要注意：在HDFS中未帶參數的"-ls"命名沒有返回任何值，它默認返回HDFS的"home"目錄下的內容。在HDFS中，沒有當前目錄這樣一個概念，也沒有cd這個命令。
圖5-1-1 列出HDFS文件
2）列出HDFS目錄下某個文檔中的文件
此處爲你展示如何通過"-ls 文件名"命令瀏覽HDFS下名爲"input"的文檔中文件：
hadoop fs –ls input
執行結果如圖5-1-2所示。
圖5-1-2 列出HDFS下名爲input的文檔下的文件
3）上傳文件到HDFS
此處爲你展示如何通過"-put 文件1 文件2"命令將"Master.Hadoop"機器下的"/home/hadoop"目錄下的file文件上傳到HDFS上並重命名爲test：
hadoop fs –put ~/file test
執行結果如圖5-1-3所示。在執行"-put"時只有兩種可能，即是執行成功和執行失敗。在上傳文件時，文件首先複製到DataNode上。只有所有的DataNode都成功接收完數據，文件上傳纔是成功的。其他情況（如文件上傳終端等）對HDFS來說都是做了無用功。
圖5-1-3 成功上傳file到HDFS
4）將HDFS中文件複製到本地系統中
此處爲你展示如何通過"-get 文件1 文件2"命令將HDFS中的"output"文件複製到本地系統並命名爲"getout"。
hadoop fs –get output getout
執行結果如圖5-1-4所示。
圖5-1-4 成功將HDFS中output文件複製到本地系統
備註：與"-put"命令一樣，"-get"操作既可以操作文件，也可以操作目錄。
5）刪除HDFS下的文檔
此處爲你展示如何通過"-rmr 文件"命令刪除HDFS下名爲"newoutput"的文檔：
hadoop fs –rmr newoutput
執行結果如圖5-1-5所示。
圖5-1-5 成功刪除HDFS下的newoutput文檔
6）查看HDFS下某個文件
此處爲你展示如何通過"-cat 文件"命令查看HDFS下input文件中內容：
hadoop fs -cat input/*
執行結果如圖5-1-6所示。
圖5-1-6 HDFS下input文件的內容
"hadoop fs"的命令遠不止這些，本小節介紹的命令已可以在HDFS上完成大多數常規操作。對於其他操作，可以通過"-help commandName"命令所列出的清單來進一步學習與探索。
5.2 管理與更新
1）報告HDFS的基本統計情況
此處爲你展示通過"-report"命令如何查看HDFS的基本統計信息：
hadoop dfsadmin -report
執行結果如圖5-2-1所示。
圖5-2-1 HDFS基本統計信息
2）退出安全模式
NameNode在啓動時會自動進入安全模式。安全模式是NameNode的一種狀態，在這個階段，文件系統不允許有任何修改。安全模式的目的是在系統啓動時檢查各個DataNode上數據塊的有效性，同時根據策略對數據塊進行必要的複製或刪除，當數據塊最小百分比數滿足的最小副本數條件時，會自動退出安全模式。
系統顯示"Name node is in safe mode"，說明系統正處於安全模式，這時只需要等待17秒即可，也可以通過下面的命令退出安全模式：
hadoop dfsadmin –safemode enter
成功退出安全模式結果如圖5-2-2所示。
圖5-2-2 成功退出安全模式
3）進入安全模式
在必要情況下，可以通過以下命令把HDFS置於安全模式：
hadoop dfsadmin –safemode enter
執行結果如圖5-2-3所示。
圖5-2-3 進入HDFS安全模式
4）添加節點
可擴展性是HDFS的一個重要特性，向HDFS集羣中添加節點是很容易實現的。添加一個新的DataNode節點，首先在新加節點上安裝好Hadoop，要和NameNode使用相同的配置（可以直接從NameNode複製），修改"/usr/hadoop/conf/master"文件，加入NameNode主機名。然後在NameNode節點上修改"/usr/hadoop/conf/slaves"文件，加入新節點主機名，再建立到新加點無密碼的SSH連接，運行啓動命令：
start-all.sh
5）負載均衡
HDFS的數據在各個DataNode中的分佈肯能很不均勻，尤其是在DataNode節點出現故障或新增DataNode節點時。新增數據塊時NameNode對DataNode節點的選擇策略也有可能導致數據塊分佈的不均勻。用戶可以使用命令重新平衡DataNode上的數據塊的分佈：
start-balancer.sh
執行命令前，DataNode節點上數據分佈情況如圖5-2-4所示。
負載均衡完畢後，DataNode節點上數據的分佈情況如圖5-2-5所示。
執行負載均衡命令如圖5-2-6所示。
6、HDFS API詳解
Hadoop中關於文件操作類基本上全部是在"org.apache.hadoop.fs"包中，這些API能夠支持的操作包含：打開文件，讀寫文件，刪除文件等。
Hadoop類庫中最終面向用戶提供的接口類是FileSystem，該類是個抽象類，只能通過來類的get方法得到具體類。get方法存在幾個重載版本，常用的是這個：
static FileSystem get(Configuration conf);
該類封裝了幾乎所有的文件操作，例如mkdir，delete等。綜上基本上可以得出操作文件的程序庫框架：
operator()
{
得到Configuration對象
得到FileSystem對象
進行文件操作
}
6.1 上傳本地文件
通過"FileSystem.copyFromLocalFile（Path src，Patch dst）"可將本地文件上傳到HDFS的制定位置上，其中src和dst均爲文件的完整路徑。具體事例如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class CopyFile {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
//本地文件
Path src =new Path("D:\\HebutWinOS");
//HDFS爲止
Path dst =new Path("/");
hdfs.copyFromLocalFile(src, dst);
System.out.println("Upload to"+conf.get("fs.default.name"));
FileStatus files[]=hdfs.listStatus(dst);
for(FileStatus file:files){
System.out.println(file.getPath());
}
}
}
運行結果可以通過控制檯、項目瀏覽器和SecureCRT查看，如圖6-1-1、圖6-1-2、圖6-1-3所示。
1）控制檯結果
圖6-1-1 運行結果（1）
2）項目瀏覽器
圖6-1-2 運行結果（2）
3）SecureCRT結果
圖6-1-3 運行結果（3）
6.2 創建HDFS文件
通過"FileSystem.create（Path f）"可在HDFS上創建文件，其中f爲文件的完整路徑。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class CreateFile {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
byte[] buff="hello hadoop world!\n".getBytes();
Path dfs=new Path("/test");
FSDataOutputStream outputStream=hdfs.create(dfs);
outputStream.write(buff,0,buff.length);
}
}
運行結果如圖6-2-1和圖6-2-2所示。
1）項目瀏覽器
圖6-2-1 運行結果（1）
2）SecureCRT結果
圖6-2-2 運行結果（2）
6.3 創建HDFS目錄
通過"FileSystem.mkdirs（Path f）"可在HDFS上創建文件夾，其中f爲文件夾的完整路徑。具體實現如下：
package com.hebut.dir;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class CreateDir {
public static void main(String[] args) throws Exception{
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path dfs=new Path("/TestDir");
hdfs.mkdirs(dfs);
}
}
運行結果如圖6-3-1和圖6-3-2所示。
1）項目瀏覽器
圖6-3-1 運行結果（1）
2）SecureCRT結果
圖6-3-2 運行結果（2）
6.4 重命名HDFS文件
通過"FileSystem.rename（Path src，Path dst）"可爲指定的HDFS文件重命名，其中src和dst均爲文件的完整路徑。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class Rename{
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path frpaht=new Path("/test"); //舊的文件名
Path topath=new Path("/test1"); //新的文件名
boolean isRename=hdfs.rename(frpaht, topath);
String result=isRename?"成功":"失敗";
System.out.println("文件重命名結果爲："+result);
}
}
運行結果如圖6-4-1和圖6-4-2所示。
1）項目瀏覽器
圖6-4-1 運行結果（1）
2）SecureCRT結果
圖6-4-2 運行結果（2）
6.5 刪除HDFS上的文件
通過"FileSystem.delete（Path f，Boolean recursive）"可刪除指定的HDFS文件，其中f爲需要刪除文件的完整路徑，recuresive用來確定是否進行遞歸刪除。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class DeleteFile {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path delef=new Path("/test1");
boolean isDeleted=hdfs.delete(delef,false);
//遞歸刪除
//boolean isDeleted=hdfs.delete(delef,true);
System.out.println("Delete?"+isDeleted);
}
}
運行結果如圖6-5-1和圖6-5-2所示。
1）控制檯結果
圖6-5-1 運行結果（1）
2）項目瀏覽器
圖6-5-2 運行結果（2）
6.6 刪除HDFS上的目錄
同刪除文件代碼一樣，只是換成刪除目錄路徑即可，如果目錄下有文件，要進行遞歸刪除。
6.7 查看某個HDFS文件是否存在
通過"FileSystem.exists（Path f）"可查看指定HDFS文件是否存在，其中f爲文件的完整路徑。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class CheckFile {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path findf=new Path("/test1");
boolean isExists=hdfs.exists(findf);
System.out.println("Exist?"+isExists);
}
}
運行結果如圖6-7-1和圖6-7-2所示。
1）控制檯結果
圖6-7-1 運行結果（1）
2）項目瀏覽器
圖6-7-2 運行結果（2）
6.8 查看HDFS文件的最後修改時間
通過"FileSystem.getModificationTime()"可查看指定HDFS文件的修改時間。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class GetLTime {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path fpath =new Path("/user/hadoop/test/file1.txt");
FileStatus fileStatus=hdfs.getFileStatus(fpath);
long modiTime=fileStatus.getModificationTime();
System.out.println("file1.txt的修改時間是"+modiTime);
}
}
運行結果如圖6-8-1所示。
圖6-8-1 控制檯結果
6.9 讀取HDFS某個目錄下的所有文件
通過"FileStatus.getPath（）"可查看指定HDFS中某個目錄下所有文件。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class ListAllFile {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path listf =new Path("/user/hadoop/test");
FileStatus stats[]=hdfs.listStatus(listf);
for(int i = 0; i < stats.length; ++i)
{
System.out.println(stats[i].getPath().toString());
}
hdfs.close();
}
}
運行結果如圖6-9-1和圖6-9-2所示。
1）控制檯結果
圖6-9-1 運行結果（1）
2）項目瀏覽器
圖6-9-2 運行結果（2）
6.10 查找某個文件在HDFS集羣的位置
通過"FileSystem.getFileBlockLocation（FileStatus file，long start，long len）"可查找指定文件在HDFS集羣上的位置，其中file爲文件的完整路徑，start和len來標識查找文件的路徑。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.BlockLocation;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
public class FileLoc {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);
Path fpath=new Path("/user/hadoop/cygwin");
FileStatus filestatus = hdfs.getFileStatus(fpath);
BlockLocation[] blkLocations = hdfs.getFileBlockLocations(filestatus, 0, filestatus.getLen());
int blockLen = blkLocations.length;
for(int i=0;i<blockLen;i++){
String[] hosts = blkLocations[i].getHosts();
System.out.println("block_"+i+"_location:"+hosts[0]);
}
}
}
運行結果如圖6-10-1和6.10.2所示。
1）控制檯結果
圖6-10-1 運行結果（1）
2）項目瀏覽器
圖6-10-2 運行結果（2）
6.11 獲取HDFS集羣上所有節點名稱信息
通過"DatanodeInfo.getHostName（）"可獲取HDFS集羣上的所有節點名稱。具體實現如下：
package com.hebut.file;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.hdfs.DistributedFileSystem;
import org.apache.hadoop.hdfs.protocol.DatanodeInfo;
public class GetList {
public static void main(String[] args) throws Exception {
Configuration conf=new Configuration();
FileSystem fs=FileSystem.get(conf);
DistributedFileSystem hdfs = (DistributedFileSystem)fs;
DatanodeInfo[] dataNodeStats = hdfs.getDataNodeStats();
for(int i=0;i<dataNodeStats.length;i++){
System.out.println("DataNode_"+i+"_Name:"+dataNodeStats[i].getHostName());
}
}
}
運行結果如圖6-11-1所示。
圖6-11-1 控制檯結果
7、HDFS的讀寫數據流
7.1 文件的讀取剖析
文件讀取的過程如下：
1）解釋一
-
客戶端(client)用FileSystem的open()函數打開文件。
-
DistributedFileSystem用RPC調用元數據節點，得到文件的數據塊信息。
-
對於每一個數據塊，元數據節點返回保存數據塊的數據節點的地址。
-
DistributedFileSystem返回FSDataInputStream給客戶端，用來讀取數據。
-
客戶端調用stream的read()函數開始讀取數據。
-
DFSInputStream連接保存此文件第一個數據塊的最近的數據節點。
-
Data從數據節點讀到客戶端(client)。
-
當此數據塊讀取完畢時，DFSInputStream關閉和此數據節點的連接，然後連接此文件下一個數據塊的最近的數據節點。
-
當客戶端讀取完畢數據的時候，調用FSDataInputStream的close函數。
-
在讀取數據的過程中，如果客戶端在與數據節點通信出現錯誤，則嘗試連接包含此數據塊的下一個數據節點。
-
失敗的數據節點將被記錄，以後不再連接。
2）解釋二
-
使用HDFS提供的客戶端開發庫，向遠程的Namenode發起RPC請求；
-
Namenode會視情況返回文件的部分或者全部block列表，對於每個block，Namenode都會返回有該block拷貝的datanode地址；
-
客戶端開發庫會選取離客戶端最接近的datanode來讀取block；
-
讀取完當前block的數據後，關閉與當前的datanode連接，併爲讀取下一個block尋找最佳的datanode；
-
當讀完列表的block後，且文件讀取還沒有結束，客戶端開發庫會繼續向Namenode獲取下一批的block列表。
-
讀取完一個block都會進行checksum驗證，如果讀取datanode時出現錯誤，客戶端會通知Namenode，然後再從下一個擁有該block拷貝的datanode繼續讀。
7.2 文件的寫入剖析
寫入文件的過程比讀取較爲複雜：
1）解釋一
-
客戶端調用create()來創建文件
-
DistributedFileSystem用RPC調用元數據節點，在文件系統的命名空間中創建一個新的文件。
-
元數據節點首先確定文件原來不存在，並且客戶端有創建文件的權限，然後創建新文件。
-
DistributedFileSystem返回DFSOutputStream，客戶端用於寫數據。
-
客戶端開始寫入數據，DFSOutputStream將數據分成塊，寫入data queue。
-
Data queue由Data Streamer讀取，並通知元數據節點分配數據節點，用來存儲數據塊(每塊默認複製3塊)。分配的數據節點放在一個pipeline裏。
-
Data Streamer將數據塊寫入pipeline中的第一個數據節點。第一個數據節點將數據塊發送給第二個數據節點。第二個數據節點將數據發送給第三個數據節點。
-
DFSOutputStream爲發出去的數據塊保存了ack queue，等待pipeline中的數據節點告知數據已經寫入成功。
-
如果數據節點在寫入的過程中失敗：
-
關閉pipeline，將ack queue中的數據塊放入data queue的開始。
-
當前的數據塊在已經寫入的數據節點中被元數據節點賦予新的標示，則錯誤節點重啓後能夠察覺其數據塊是過時的，會被刪除。
-
失敗的數據節點從pipeline中移除，另外的數據塊則寫入pipeline中的另外兩個數據節點。
-
元數據節點則被通知此數據塊是複製塊數不足，將來會再創建第三份備份。
-
-
當客戶端結束寫入數據，則調用stream的close函數。此操作將所有的數據塊寫入pipeline中的數據節點，並等待ack queue返回成功。最後通知元數據節點寫入完畢。
2）解釋二
-
使用HDFS提供的客戶端開發庫，向遠程的Namenode發起RPC請求；
-
Namenode會檢查要創建的文件是否已經存在，創建者是否有權限進行操作，成功則會爲文件創建一個記錄，否則會讓客戶端拋出異常；
-
當客戶端開始寫入文件的時候，開發庫會將文件切分成多個packets，並在內部以"data queue"的形式管理這些packets，並向Namenode申請新的blocks，獲取用來存儲replicas的合適的datanodes列表，列表的大小根據在Namenode中對replication的設置而定。
-
開始以pipeline（管道）的形式將packet寫入所有的replicas中。開發庫把packet以流的方式寫入第一個datanode，該datanode把該packet存儲之後，再將其傳遞給在此pipeline中的下一個datanode，直到最後一個datanode，這種寫數據的方式呈流水線的形式。
-
最後一個datanode成功存儲之後會返回一個ack packet，在pipeline裏傳遞至客戶端，在客戶端的開發庫內部維護着"ack queue"，成功收到datanode返回的ack packet後會從"ack queue"移除相應的packet。
-
如果傳輸過程中，有某個datanode出現了故障，那麼當前的pipeline會被關閉，出現故障的datanode會從當前的pipeline中移除，剩餘的block會繼續剩下的datanode中繼續以pipeline的形式傳輸，同時Namenode會分配一個新的datanode，保持replicas設定的數量。
文章下載地址：http://files.cnblogs.com/xia520pi/HadoopCluster_Vol.8.rar
出處：http://www.cnblogs.com/xia520pi/archive/2012/05/28/2520813.html