hdfsjava目錄大小

A. HDFS 系統架構

HDFS Architecture

Hadoop Distributed File System (HDFS) 是設計可以運行於普通商業硬體上的分布式文件系統。它跟現有的分布式文件系統有很多相通的地方，但是區別也是顯著的。HDFS具有高度容錯性能，被設計運行於低成本硬體上。HDFS可以向應用提供高吞吐帶寬，適合於大數據應用。HDFS 放寬了一些 POSIX 的要求，以開啟對文件系統數據的流式訪問。HDFS 最初是作為Apache Nutch web 搜索引擎項目的基礎設施開發的。HDFS 現在是 Apache Hadoop 核心項目的一部分。

HDFS是主從架構。一個HDFS集群包含一個NameNode，一個管理文件系統命名空間和控制客戶端訪問文件的master server。以及，若乾的 DataNodes，通常集群的每個node一個，管理運行DataNode的節點上的存儲。HDFS 發布一個文件系統命名空間，並允許用戶數據已文件的形式存儲在上面。內部，一個文件被分成一個或多個塊，存儲在一組DataNodes上。NameNode 執行文件系統命名空間操作，比如：打開、關閉、重命名文件或目錄。它還確定塊到DataNodes的映射。DataNodes 負責向文件系統客戶端提供讀寫服務。DataNodes 根據 NameNode 的指令執行塊的創建、刪除以及復制。

NameNode 和 DataNode 是設計運行於普通商業機器的軟體。這些機器通常運行 GNU/Linux 操作系統。HDFS 是java 語言編寫的；任何支持Java的機器都可以運行NameNode or DataNode 軟體。使用高移植性Java語言，意味著HDFS可以部署在很大范圍的機器上。一個典型的部署就是一台特定的機器只運行NameNode 軟體，而集群內的其他機器運行DataNode 軟體的一個實例。這種架構不排除一台機器上運行多個DataNodes ，但是在實際部署中很少見。

單 NameNode 節點的存在大大簡化了架構。NameNode 是所有HDFS 元數據的仲裁和倉庫。系統設計上，用戶數據永遠不經過NameNode。

HDFS 支持傳統的文件分級組織。用戶或應用可以創建目錄，並在目錄內存儲文件。 文件系統命名空間的層次結構跟其他文件系統類似；可以創建、刪除、移動、重命名文件。HDFS 支持 user quotas 和 access permissions 。 HDFS 不支持軟、硬鏈接。但是，HDFS 架構不排除實現這些功能。

雖然HDFS遵守 文件系統命名約定 ，一些路徑和名稱 (比如/.reserved 和.snapshot ) 保留了。比如功能 transparent encryption 和 snapshot 就使用的保留路徑。

NameNode 維護文件系統命名空間。任何文件系統命名空間或屬性的變化，都會被NameNode記錄。 應用可以指定HDFS應維護的文件副本數量。文件副本的數量被稱為該文件的復制因子 replication factor 。該信息存儲於NameNode。

HDFS 被設計用於在一個大規模集群上跨機器可靠地存儲巨大的文件。它以一序列的塊的方式存儲文件。每個文件都可以配置塊尺寸和復制因子。

一個文件除了最後一個塊外，其他的塊一樣大。在 append 和 hsync 添加了可變長度塊的支持後，用戶可以啟動一個新的塊，而不用填充最後一個塊到配置的塊大小。

應用可以指定一個文件的副本數量。復制因子可以在創建的時候指定，也可以以後更改。HDFS的文件只寫一次(除了 appends 和 truncates) ，並在任何時候只允許一個 writer 。

NameNode 指定塊復制的所有決策。它周期性的從集群的每個DataNodes 接受 Heartbeat 和 Blockreport。Heartbeat 的接受代表 DataNode 工作正常。Blockreport 包含了DataNode上所有塊的清單。

副本的位置對HDFS的可靠性和性能至關重要。副本位置的優化是HDFS和其他大多數分布式文件系統的區別。這是一個需要大量調優和經驗的特性。Rack-aware 復制策略的目的就是提高數據可靠性，可用性和網路帶寬利用率。當前副本位置策略的實現是這個方向的第一步。實施該策略的短期目標是在生產環境驗證它，了解其更多的行為，為測試和研究更復雜的策略打下基礎。

大型HDFS實例運行在跨多個Rack的集群伺服器上。不同rack的兩個node通信需要通過交換機。大多數情況下，同一rack內的帶寬大於rack之間的帶寬。

NameNode 通過在 Hadoop Rack Awareness 內的進程描述 判斷DataNode 屬於哪個rack id。一個簡單但是並非最佳的策略是將副本分布於不同的racks。這可以防止整個機架發生故障時丟失數據，並允許在讀取數據時使用多個機架的帶寬。該策略在群集中均勻地分布副本，使得組件故障時很容易平衡負載。 但是，該策略會增加寫入成本，因為寫入操作需要將塊傳輸到多個機架。

一般，復制因子設置為3， HDFS 的分布策略是：如果writer在datanode上則將一個副本放到本地機器， 如果writer不在datanode上則將一個副本放到writer所在機櫃的隨機datanode 上；另一個副本位於不同機架的node上；最後一個副本位於同一遠程機架的不同node上。 該策略減少了機架間的寫流量，提升了寫性能。機架故障的概率遠小於節點故障的概率；此策略不會影響數據可靠性和可用性承諾。但是，在讀取數據時，它確實減少了聚合帶寬，因為塊存儲於兩個機櫃而不是三個機櫃內。使用此策略，副本不會均勻的分布於機架上。1/3 副本 位於同一節點， 2/3 副本位於同一機架， 另1/3副本位於其他機架。該策略提升了寫性能而不影響數據可靠性和讀性能。

如果復制因子大於3，那麼第4個及以後的副本則隨機放置，只要滿足每個機架的副本在(replicas - 1) / racks + 2)之下。

因為 NameNode 不允許 DataNodes 擁有同一個塊的多個副本，所以副本的最大數就是DataNodes的數量。

在把對 存儲類型和存儲策略 的支持添加到 HDFS 後，除了上面介紹的rack awareness外， NameNode 會考慮其他副本排布的策略。NameNode 先基於rack awareness 選擇節點，然後檢查候選節點有文件關聯的策略需要的存儲空間。 如果候選節點沒有該存儲類型， NameNode 會查找其他節點。如果在第一條路徑中找不到足夠的節點來放置副本，NameNode會在第二條路徑中查找具有回滾存儲類型的節點。 、

當前，這里描述的默認副本排布策略正在使用中。

為了最小化全局帶寬消耗和讀取延遲， HDFS 會嘗試從最靠近reader的副本響應讀取請求。如果在reader節點的同一機架上上存在副本，則該副本有限響應讀請求。如果HDFS集群跨多個數據中心，則本地數據中心優先。

啟動時，NameNode 會進入一個稱為 Safemode 的特殊狀態。當NameNode處於Safemode狀態時，不會復制數據塊。NameNode從DataNodes接收Heartbeat和Blockreport消息。Blockreport包含DataNode託管的數據塊列表。每個塊都指定了最小副本數。當數據塊的最小副本數已與NameNode簽入時，該塊被認為是安全復制的。在NameNode簽入安全復制數據塊的已配置百分比（加上額外的30秒）後，NameNode退出Safemode狀態。然後，它判斷列表內的數據塊清單是否少於副本指定的數量。NameNode 然後復制這些塊給其他 DataNodes。

HDFS 命名空間由 NameNode 存儲。NameNode 使用事務日誌 EditLog 來持久化的保存系統元數據的每次變更。比如，在HDFS創建一個新文件，NameNode會在 EditLog 插入一條記錄來指示該變更。類似的，變更文件的復制因子也會在 EditLog 插入一條新記錄。NameNode 以文件的形式，將 EditLog 保存在本地OS文件系統上。整個文件系統命名空間，包括塊到文件的映射、文件系統屬性，都存儲於名字為 FsImage 的文件內。 FsImage 也以文件的形式，存儲在NameNode的本地文件系統上。

NameNode 將包含整個文件系統和塊映射的image保存在內存中。當NameNode啟動時，或檢查點被預先定義的閾值觸發時，它會從磁碟讀取 FsImage 和 EditLog ，把 EditLog 內的事物應用到內存中的FsImage，再將新版本刷新回磁碟的新 FsImage 。然後會截斷舊的 EditLog ，因為它的事物已經應用到了持久化的 FsImage 上。 這個過程稱為檢查點 checkpoint 。檢查點的目的是通過對文件系統元數據進行快照並保存到FsImage，來確保HDFS擁有文件系統元數據的一致性視圖。盡管讀取 FsImage 是高效的，但是對 FsImage 直接增量修改是不高效的。不是對每次編輯修改 FsImage ，而是將每次編輯保存到 Editlog 。在檢查點期間，將 Editlog 的變更應用到 FsImage 。一個檢查點可以在固定周期(dfs.namenode.checkpoint.period)(以秒為單位)觸發，也可以文件系統事物數量達到某個值(dfs.namenode.checkpoint.txns)的時候觸發。

DataNode 在本地文件系統上以文件的形式存儲 HDFS data 。DataNode 不知道 HDFS 文件。它將HDFS data 的每個塊以獨立的文件存儲於本地文件系統上。DataNode 不在同一目錄創建所有的文件。而是，使用heuristic來確定每個目錄的最佳文件數量，並適當的創建子目錄。在一個目錄創建所有的本地文件是不好的，因為本地文件系統可能不支持單目錄的海量文件數量。當DataNode啟動的時候，它掃描本地文件系統，生成與本地文件系統一一對應的HDFS數據塊列表，然後報告給NameNode。這個報告稱為 Blockreport。

所有的HDFS通信協議都在TCP/IP協議棧上。客戶端與NameNode指定的埠建立連接。與NameNode以ClientProtocol 通信。DataNodes與NameNode以DataNode Protocol進行通信。遠程過程調用(RPC)封裝了Client Protocol 和 DataNode Protocol。設計上，NameNode從不啟動任何RPCs。相反，它只應答DataNodes or clients發出的RPC請求。

HDFS的主要目標是可靠的存儲數據，即使是在故障的情況下。常見故障類型有三種： NameNode failures , DataNode failures 和 network partitions 。

每個DataNode都周期性的向NameNode發送心跳信息。 一個 network partition 可能導致DataNodes子集丟失與NameNode的連接。NameNode會基於心跳信息的缺失來偵測這種情況。NameNode將沒有心跳信息的DataNodes標記為 dead ，並不再轉發任何IO請求給它們。任何注冊到dead DataNode的數據對HDFS將不再可用。DataNode death會導致某些塊的復制因子低於它們指定的值。NameNode不斷跟蹤需要復制的塊，並在必要時啟動復制。很多因素會導致重新復制：DataNode不可用，副本損壞，DataNode上硬碟故障，復制因子增加。

標記 DataNodes dead 的超時時間保守地設置了較長時間 (默認超過10分鍾) 以避免DataNodes狀態抖動引起的復制風暴。對於性能敏感的應用，用戶可以設置較短的周期來標記DataNodes為過期，讀寫時避免過期節點。

HDFS 架構支持數據再平衡schemes。如果一個DataNode的空餘磁碟空間低於閾值，sheme就會將數據從一個DataNode 移動到另外一個。在某些文件需求突然增長的情況下，sheme可能會在集群內動態的創建額外的副本，並再平衡其他數據。這些類型的數據再平衡schemes還沒有實現。

有可能從DataNode獲取的數據塊，到達的時候損壞了。這種損壞可能是由於存儲設備故障、網路故障、軟體bug。HDFS客戶端軟體會HDFS的內容進行校驗。當客戶端創建HDFS文件的時候，它計算文件每個塊的校驗值，並以獨立的隱藏文件存儲在同一HDFS命名空間內。當客戶端檢索文件時候，它會校驗從每個DataNode獲取的數據，是否與關聯校驗文件內的校驗值匹配。 如果不匹配，客戶端可以從另外擁有副本塊的DataNode檢索。

FsImage 和 EditLog 是HDFS的核心數據結構。這些文件的損壞將導致HDFS實例異常。 因此，NameNode可以配置為支持多 FsImage 和 EditLog 副本模式。任何對 FsImage or EditLog 的更新都會導致每個 FsImages 和 EditLogs 的同步更新。 FsImage 和 EditLog 的同步更新會導致降低命名空間每秒的事物效率。但是，這種降級是可以接受的，因為HDFS應用是數據密集型，而不是元數據密集型。當NameNode重啟的時候，它會選擇最新的一致的 FsImage 和 EditLog 。

另外一種提供故障恢復能力的辦法是多NameNodes 開啟HA，以 shared storage on NFS or distributed edit log (called Journal)的方式。推薦後者。

Snapshots - 快照，支持在特定時刻存儲數據的副本。快照功能的一個用法，可以回滾一個故障的HDFS實例到已知工作良好的時候。

HDFS被設計與支持超大的文件。與HDFS適配的軟體都是處理大數據的。這些應用都只寫一次，但是它們會讀取一或多次，並且需要滿足流式讀速度。HDFS支持文件的 一次寫入-多次讀取 語義。 HDFS典型的塊大小是128 MB.。因此，HDFS文件被分割為128 MB的塊，可能的話每個塊都位於不同的DataNode上。

當客戶端以復制因子3寫入HDFS文件時，NameNode以 復制目標選擇演算法 replication target choosing algorithm 檢索DataNodes 列表。該列表包含了承載該數據塊副本的DataNodes清單。然後客戶端寫入到第一個DataNode。第一DataNode逐步接受數據的一部分，將每一部分內容寫入到本地倉庫，並將該部分數據傳輸給清單上的第二DataNode。第二DataNode，按順序接受數據塊的每個部分，寫入到倉庫，然後將該部分數據刷新到第三DataNode。最終，第三DataNode將數據寫入到其本地倉庫。
因此，DataNode從管道的前一個DataNode獲取數據，同時轉發到管道的後一個DataNode。因此，數據是以管道的方式從一個DataNode傳輸到下一個的。

應用訪問HDFS有很多方式。原生的，HDFS 提供了 FileSystem Java API 來給應用調用。還提供了 C language wrapper for this Java API 和 REST API 。另外，還支持HTTP瀏覽器查看HDFS實例的文件。 通過使用 NFS gateway ，HDFS還可以掛載到客戶端作為本地文件系統的一部分。

HDFS的用戶數據是以文件和目錄的形式組織的。它提供了一個命令行介面 FS shell 來提供用戶交互。命令的語法類似於其他shell (比如：bash, csh)。如下是一些範例：

FS shell 的目標是向依賴於腳本語言的應用提供與存儲數據的交互。

DFSAdmin 命令用於管理HDFS集群。這些命令僅給HDFS管理員使用。如下範例：

如果啟用了回收站配置，那麼文件被 FS Shell 移除時並不會立即從HDFS刪除。HDFS會將其移動到回收站目錄(每個用戶都有回收站，位於 /user/<username>/.Trash )。只要文件還在回收站內，就可以快速恢復。

最近刪除的文件大多數被移動到 current 回收站目錄 ( /user/<username>/.Trash/Current )，在配置周期內，HDFS給 current目錄內的文件創建檢查點 checkpoints (位於 /user/<username>/.Trash/<date> ) ，並刪除舊的檢查點。參考 expunge command of FS shell 獲取更多關於回收站檢查點的信息。

在回收站過期後，NameNode從HDFS命名空間刪除文件。刪除文件會將文件關聯的塊釋放。注意，在用戶刪除文件和HDFS增加free空間之間，會有一個明顯的延遲。

如下範例展示了FS Shell如何刪除文件。我們在delete目錄下創建兩個文件(test1 & test2)

我們刪除文件 test1。如下命令顯示文件被移動到回收站。

現在我們嘗試以skipTrash參數刪除文件，該參數將不將文件發送到回收站。文件將會從HDFS完全刪除。

我們檢查回收站，只有文件test1。

如上，文件test1進了回收站，文件test2被永久刪除了。

當縮減文件的復制因子時，NameNode選擇可以被刪除的多餘副本。下一個Heartbeat會通報此信息給DataNode。DataNode然後會刪除響應的塊，相應的剩餘空間會顯示在集群內。同樣，在setReplication API調用完成和剩餘空間在集群顯示之間會有一個時間延遲。

Hadoop JavaDoc API .

HDFS source code: http://hadoop.apache.org/version_control.html

B. 如何使用Java API訪問HDFS為目錄設置配額

Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬體(commodity hardware)上的分布式文件系統。它和現有的分布式文件系統有很多共同點。但同時，它和其他的分布式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取文件系統數據的目的。HDFS在最開始是作為Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。
HDFS有著高容錯性（fault-tolerant）的特點，並且設計用來部署在低廉的（low-cost）硬體上。而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求（requirements）這樣可以實現流的形式訪問（streaming access）文件系統中的數據。

C. java web怎麼讀取hdfs文件大小

用org.apache.hadoop.fs.DF public String toString() { return "df -k " + mount +"\n" + filesystem + "\t" + getCapacity() / 1024 + "\t" + getUsed() / 1024 + "\t" + getAvailable() / 1024 + "\t" + getPercentUsed() + "%\t" + mount; }

D. Hadoop如何處理如何增強Hadoop 安全

Hadoop是由Apache開源軟體基金會開發的，運行於大規模普通伺服器上的分布式系統基礎架構，用於大規模數據的存儲、計算、分析等。通過使用Hadoop平台用戶可以在不了解分布式底層細節的情況下，開發分布式程序，充分利用集群的威力進行高速運算和存儲。2007年雅虎發布了第一個Apache Hadoop版本0.14.1；2008年雅虎用Hadoop做到全網尺度的搜索；2009年雅虎把內部版本全部開源，於是IBM也加入Hadoop的開發陣營；2010年Facebook宣布正式運行世界最大的Hadoop集群；2011年Apache Hadoop1.0版本發布；2012年Apache Hadoop2.0版本發布。下面具體介紹一下Hadoop系統的架構。

Hadoop由許多元素構成，如下圖圖所示，包括HBase、Hive、Pig、Chukwa、Oozie和ZooKeeper等，但是其核心組件為HDFS和MapRece。

JobTraker和NameNode運行在同一個伺服器上，我們稱為Hadoop集群的主節點，負責接收客戶端提交的作業，並將任務分配到不同的計算節點TaskTracker上，同時監控作業的運行情況，完成作業的更新和容錯處理；Tasktracker通常和DataNode裝在一起，稱為Hadoop集群的從節點，它調用Map和Rece執行JobTracker指派的任務，並發送心跳消息給JobTracker，向JobTracker匯報可運行任務的數量。

Hadoop安全機制

Hadoop 一直缺乏安全機制，主要表現在以下幾個方面。

• User to Service：NameNode或者JobTracker缺乏安全認證機制；DataNode缺乏安全授權機制；JobTracker缺乏安全授權機制。
• Service to Service安全認證：Datanode與TaskTracker缺乏安全授權機制，這使得用戶可以隨意啟動假的DataNode和TaskTracker。
• 磁碟或者通信連接沒有經過加密。

為了增強Hadoop的安全機制， 從2009年起Apache專門抽出一個團隊為Hadoop增加安全認證和授權機制，Apache Hadoop 1.0.0版本之後的版本添加了安全機制，但是升級到該版本後可能會導致Hadoop的一些應用不可用。

E. Hadoop生態系統-新手快速入門（含HDFS、HBase系統架構）

Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。

用戶可以在不了解分布式底層細節的情況下，開發分布式程序。充分利用集群的威力進行高速運算和存儲。

Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上；而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。

Hadoop的框架最核心的設計就是：HDFS和MapRece。HDFS為海量的數據提供了存儲，而MapRece則為海量的數據提供了計算。

廣義的Hadoop，一般稱為Hadoop生態系統，如下所示。

Hadoop生態系統中這些軟體的作用：

HDFS 採用了主從（Master/Slave）結構模型，一個HDFS集群包括一個名稱節點（NameNode）和若干個數據節點（DataNode）。

HDFS採用Java語言開發，因此任何支持JVM的機器都可以部署名稱節點和數據節點。

在配置好Hadoop 集群之後，可以通過瀏覽器訪問 http://[NameNodeIP]:9870，查詢HDFS文件系統。通過該Web界面，可以查看當前文件系統中各個節點的分布信息。

HBase系統架構如下所示，包括客戶端、Zookeeper伺服器、Master主伺服器、Region伺服器。一般而言，HBase會採用HDFS作為底層數據存儲。

在HBase伺服器集群中，包含了一個Master和多個Region伺服器，Master是HBase集群的「總管」，它必須知道Region伺服器的狀態。

HBase中可以啟動多個Master，但是Zookeeper 可以幫助選舉出一個Master 作為集群的總管，並保證在任何時刻總有唯一一個Master在運行，這樣可以避免Master單點失效的問題。

Region伺服器是HBase中最核心的模塊，負責維護分配給自己的Region，並響應用戶的讀寫請求。

Store是Region伺服器的核心。每個Store對應了表中的一個列族的存儲。每一個Store包含了一個MemStore緩存和若干個StoreFile文件。

HBase採用HLog來保證系統發生故障時，能夠恢復到正確的狀態。HLog是磁碟上面的記錄文件，它記錄著所有的更新操作。

HBase系統為每個Region伺服器配置了一個HLog文件，它是一種預寫式日誌（Write Ahead Log），也就是說，用戶更新數據必須首先被記入日誌後，才能寫入MemStore緩存。

此外，Pig和Hive還為HBase提供了高層語言支持，使得在HBase上進行數據統計處理變的非常簡單。 Sqoop則為HBase提供了方便的RDBMS數據導入功能，使得傳統資料庫數據向HBase中遷移變的非常方便。

注意：Hadoop 安裝完成之後，只包含HDFS和MapRece，並不含HBase，因此需要在Hadoop 之上繼續安裝HBase。

F. 如何使用Java API讀寫HDFS

HDFS是Hadoop生態系統的根基，也是Hadoop生態系統中的重要一員，大部分時候，我們都會使用Linuxshell命令來管理HDFS，包括一些文件的創建，刪除，修改，上傳等等，因為使用shell命令操作HDFS的方式，相對比較簡單，方便，但是有時候，我們也需要通過編程的方式來實現對文件系統的管理。比如有如下的一個小需求，要求我們實現讀取HDFS某個文件夾下所有日誌，經過加工處理後在寫入到HDFS上，或者存進Hbase里，或者存進其他一些存儲系統。這時候使用shell的方式就有點麻煩了，所以這時候我們就可以使用編程的方式來完成這件事了，當然散仙在這里使用的是原生的Java語言的方式，其他的一些語言例如C++,PHP,Python都可以實現，散仙在這里不給出演示了，（其實散仙也不會那些語言，除了剛入門的Python）。下面，散仙給出代碼，以供參考：viewsourceprint?packagecom.java.api.hdfs;importjava.io.BufferedReader;importjava.io.IOException;importjava.io.InputStream;importjava.io.InputStreamReaderimportorg.apache.hadoop.conf.Configuration;importorg.apache.hadoop.fs.FileStatus;importorg.apache.hadoop.fs.FileSystem;importorg.apache.hadoop.fs.Path;/***@author三劫散仙*JavaAPI操作HDFS*工具類****/publicclassOperaHDFS{publicstaticvoidmain(String[]args)throwsException{//System.out.println("aaa");//uploadFile();//createFileOnHDFS();//deleteFileOnHDFS();//createDirectoryOnHDFS();//deleteDirectoryOnHDFS();//renameFileOrDirectoryOnHDFS();readHDFSListAll();}/****載入配置文件***/staticConfigurationconf=newConfiguration();/***重名名一個文件夾或者文件()throwsException{FileSystemfs=FileSystem.get(conf);Pathp1=newPath("hdfs://10.2.143.5:9090/root/myfile/my.txt");fs.rename(p1,p2);System.out.println("重命名文件夾或文件成功..");}/*****讀取HDFS某個文件夾的所有*文件，並列印****/()throwsException{//流讀入和寫入InputStreamin=null;//獲取HDFS的conf//讀取HDFS上的文件系統FileSystemhdfs=FileSystem.get(conf);//使用緩沖流，進行按行讀取的功能BufferedReaderbuff=null;//獲取日誌文件的根目錄Pathlistf=newPath("hdfs://10.2.143.5:9090/root/myfile/");//獲取根目錄下的所有2級子文件目錄FileStatusstats[]=hdfs.listStatus(listf);//自定義j，方便查看插入信息intj=0;for(inti=0;i

G. 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 僅僅只需要服務於獲取塊位置的請求（塊位置信息是存放在內存中，所以效率很高）。如果不這樣設計，隨著客戶端數據量的增長，數據服務就會很快成為一個瓶頸。

我們知道，相對於客戶端(之後就是 maprece 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中有多種壓縮格式、演算法和工具，下圖列出了常用的壓縮方法。

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

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

更詳細的比較如下

1.壓縮性能比較

2.優缺點

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

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

壓縮舉例（Java）

壓縮

解壓縮

六、文件序列化

序列化是指將結構化數據轉換為位元組流以便在網路上傳輸或寫到磁碟進行永久存儲。反序列化獅子將位元組流轉換回結構化對象的逆過程。

序列化用於分布式數據處理的兩大領域：進程間通信和永久存儲。

對序列化的要求時是格式緊湊（高效使用存儲空間）、快速（讀寫效率高）、可擴展（可以透明地讀取老格式數據）且可以互操作（可以使用不同的語言讀寫數據）。

Hadoop使用的是自己的序列化格式 Writable ，它絕對緊湊、速度快，但不太容易用java以外的語言進行擴展或使用。

當然，用戶也可以使用其他序列化框架或者自定義序列化方式，如 Avro 框架。

Hadoop內部還使用了 Apache Thrift 和 Protocal Buffers 來實現RPC和數據交換。