HDFS文件

Hadoop支持的文件系統由很多（見下圖），HDFS只是其中壹種實現。Java抽象類 org.apache.hadoop.fs.FileSystem 定義了Hadoop中壹個文件系統的客戶端接口，並且該抽象類有幾個具體實現。Hadoop壹般使用URI（下圖）方案來選取合適的文件系統實例進行交互。

特別的，HDFS文件系統的操作可以使用 FsSystem shell 、客戶端（http rest api、Java api、C api等）。

FsSystem shell 的用法基本同本地shell類似，命令可參考 FsSystem shell

Hadoop是用Java寫的，通過Java Api（ FileSystem 類）可以調用大部分Hadoop文件系統的交互操作。更詳細的介紹可參考 hadoop Filesystem 。

非Java開發的應用可以使用由WebHDFS協議提供的HTTP REST API，但是HTTP比原生的Java客戶端要慢，所以不到萬不得已盡量不要使用HTTP傳輸特大數據。通過HTTP來訪問HDFS有兩種方法：

兩種如圖

在第壹種情況中，namenode和datanode內嵌的web服務作為WebHDFS的端節點運行（是否啟用WebHDFS可通過dfs.webhdfs.enabled設置，默認為true）。文件元數據在namenode上，文件讀寫操作首先被發往namenode，有namenode發送壹個HTTP重定向至某個客戶端，指示以流的方式傳輸文件數據的目的或源datanode。

第二種方法依靠壹個或多個獨立代理服務器通過HTTP訪問HDFS。所有集群的網絡通信都需要通過代理，因此客戶端從來不直接訪問namenode或datanode。使用代理後可以使用更嚴格的防火墻策略和帶寬策略。

HttpFs代理提供和WebHDFS相同的HTTP接口，這樣客戶端能夠通過webhdfs URI訪問接口。HttpFS代理啟動獨立於namenode和datanode的守護進程，使用httpfs.sh 腳本，默認在壹個不同的端口上監聽（14000）。

下圖描述了

讀文件時客戶端與 HDFS 中的 namenode， datanode 之間的數據流動。

對上圖的解釋如下：

在讀取過程中，如果 FSDataInputStream 在和壹個 datanode 進行交流時出現了壹個錯誤，他就去試壹試下壹個最接近的塊，他當然也會記住剛才發生錯誤的 datanode 以至於之後不會再在這個 datanode 上進行沒必要的嘗試。 DFSInputStream 也會在 datanode 上傳輸出的數據上核查檢查數(checknums).如果損壞的塊被發現了， DFSInputStream 就試圖從另壹個擁有備份的 datanode 中去讀取備份塊中的數據。

在這個設計中壹個重要的方面就是客戶端直接從 datanode 上檢索數據，並通過 namenode 指導來得到每壹個塊的最佳 datanode。這種設計允許 HDFS 擴展大量的並發客戶端，因為數據傳輸只是集群上的所有 datanode 展開的。期間，namenode 僅僅只需要服務於獲取塊位置的請求（塊位置信息是存放在內存中，所以效率很高）。如果不這樣設計，隨著客戶端數據量的增長，數據服務就會很快成為壹個瓶頸。

我們知道，相對於客戶端(之後就是 mapreduce task 了)，塊的位置有以下可能性：

我們認為他們對於客戶端的帶寬遞減，距離遞增（括號中表示距離）。示意圖如下：

如果集群中的機器都在同壹個機架上，我們無需其他配置，若集群比較復雜，由於hadoop無法自動發現網絡拓撲，所以需要額外配置網絡拓撲。

基本讀取程序，將文件內容輸出到console

FileSystemCat

隨機讀取

展開原碼

下圖描述了寫文件時客戶端與 HDFS 中的 namenode， datanode 之間的數據流動。

對上圖的解釋如下：

如果在任何壹個 datanode 在寫入數據的時候失敗了，接下來所做的壹切對客戶端都是透明的：首先， pipeline 被關閉，在確認隊列中的剩下的包會被添加進數據隊列的起始位置上，以至於在失敗的節點下遊的任何節點都不會丟失任何的包。然後與 namenode 聯系後，當前在壹個好的 datanode 會聯系 namenode，給失敗節點上還未寫完的塊生成壹個新的標識ID，以至於如果這個失敗的 datanode 不久後恢復了，這個不完整的塊將會被刪除。失敗節點會從 pipeline 中移除，然後剩下兩個好的 datanode 會組成壹個的新的 pipeline ，剩下的這些塊的包(也就是剛才放在數據隊列隊首的包)會繼續寫進 pipeline 中好的 datanode 中。最後，namenode 註意到塊備份數小於規定的備份數，他就安排在另壹個節點上創建完成備份，直接從已有的塊中復制就可以。然後壹直到滿足了備份數( dfs.replication )。如果有多個節點的寫入失敗了，如果滿足了最小備份數的設置( dfs.namenode.repliction.min ),寫入也將會成功，然後剩下的備份會被集群異步的執行備份，直到滿足了備份數( dfs.replication )。

創建目錄

文件壓縮有兩大好處：

Hadoop 對於壓縮格式的是自動識別。如果我們壓縮的文件有相應壓縮格式的擴展名（比如 lzo，gz，bzip2 等）。Hadoop 會根據壓縮格式的擴展名自動選擇相對應的解碼器來解壓數據，此過程完全是 Hadoop 自動處理，我們只需要確保輸入的壓縮文件有擴展名。

Hadoop中有多種壓縮格式、算法和工具，下圖列出了常用的壓縮方法。

表中的“是否可切分”表示對應的壓縮算法是否支持切分，也就是說是否可以搜索數據流的任意位置並進壹步往下讀取數據，可切分的壓縮格式尤其適合MapReduce。

所有的壓縮算法都需要權衡空間/時間：壓縮和解壓縮速度更快，其代價通常是只能節省少量的空間。不同的壓縮工具有不同的特性：

更詳細的比較如下

1.壓縮性能比較

2.優缺點

另外使用hadoop原生（native）類庫比其他java實現有更快的壓縮和解壓縮速度。特征比較如下：

使用容器文件格式結合壓縮算法也能更好的提高效率。順序文件、Arvo文件、ORCFiles、Parqurt文件同時支持壓縮和切分。

壓縮舉例（Java）