Hadoop Distributed File System，簡稱HDFS，是一個分佈式文件系統。HDFS有着高容錯性（fault-tolerent）的特點，並且設計用來部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有着超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX（可移植操作系統接口Portable
Operating System Interface ，縮寫爲 POSIX 是爲了讀音更像 UNIX）的要求（requirements）這樣可以實現流的形式訪問（streaming access）文件系統中的數據。HDFS開始是爲開源的apache項目nutch的基礎結構而創建，HDFS是hadoop項目的一部分，而hadoop又是lucene的一部分。
ps：下面某些地方增加了自己的一些理解；名字節點（NameNode）、數據節點（DataNode）
特點和目標：
硬件故障
硬件故障是常態，而不是異常。整個HDFS系統將由數百或數千個存儲着文件數據片斷的服務器組成。實際上它裏面有非常巨大的組成部分，每一個組成部分都會頻繁地出現故障，這就意味着HDFS裏的一些組成部分是總是失效的，因此，故障的檢測和自動快速恢復是HDFS一個很核心的結構目標。
流式的數據訪問
運行在HDFS之上的應用程序必須流式地訪問它們的數據集，它不是典型的運行在常規的文件系統之上的常規程序。HDFS是設計成適合批量處理的，而不是用戶交互式的。重點是在數據吞吐量，而不是數據訪問的反應時間，POSIX強制的很多硬性需求對很多應用不是必須的，去掉POSIX的很多關鍵地方的語義以獲得更好的數據吞吐率。
大數據集
運行在HDFS之上的程序有很大量的數據集。這意味着典型的HDFS文件是GB到TB的大小，所以，HDFS是很好地支持大文件。它應該提供很高的聚合數據帶寬，應該一個集羣中支持數百個節點，還應該支持一個集羣中千萬的文件。
簡單一致性模型
大部分的HDFS程序對文件操作需要的是一次寫入，多次讀取的。一個文件一旦創建、寫入、關閉之後就不需要修改了。這個假定簡單化了數據一致的問題和高吞吐量的數據訪問。Map-Reduce程序或者網絡爬蟲程序都是非常完美地適合這個模型。有一個計劃在將來實現文件的附加寫入。
移動計算比移動數據更經濟
在靠近要被計算的數據所存儲的位置來進行計算是最理想的狀態，尤其是在數據集特別巨大的時候。這樣消除了網絡的擁堵，提高了系統的整體吞吐量。這個假定就是將計算離數據更近比將文件移動到程序運行的位置更好。HDFS提供了接口，來讓程序將自己移動到離數據存儲的位置更近。
輕便的訪問異構的軟硬件平臺
HDFS應該設計成這樣的一種方式，就是簡單輕便地從一個平臺到另外一個平臺，這將推動需要大數據集的應用更廣泛地採用HDFS作爲平臺。
名字節點和數據節點
HDFS是一個主從結構的體系，一個HDFS集羣是由一個名字節點，它是一個管理文件的命名空間和調節客戶端訪問文件的主服務器，當然還有的數據節點，一個節點一個Datanode，它來管理存儲。HDFS暴露文件命名空間和允許用戶數據存儲成文件。
內部機制是將一個文件分割成一個或多個的塊（默認是64M），這些塊存儲在一組數據節點中。名字節點操作文件命名空間的文件或目錄操作，如打開，關閉，重命名，等等。它同時確定塊與數據節點的映射。數據節點來負責來自文件系統客戶的讀寫請求。
數據節點同時還要執行塊的創建，刪除，和來自名字節點的塊複製指示。
名字節點和數據節點都是軟件運行在普通的機器之上，機器典型的都是linux，HDFS是用java來寫的，任何支持java的機器都可以運行名字節點或數據節點，利用java語言的超輕便性，很容易將HDFS部署到大範圍的機器上。典型的部署時將有一個專門的機器來運行名字節點軟件（因爲運行Namenode消耗大量的內存和I/O資源，所以爲了減輕機器的負載，駐留Namenode的服務器通常不會存儲用戶數據或者執行MapReduce程序的計算任務。這也意味着Namenode服務器不會同時是Datanode或者TaskTracker，當然，這裏針對的是完全分佈式模式），機羣中的其他機器運行一個數據節點實例。體系結構排斥在一個機器上運行多個數據節點的實例，但是實際的部署不會有這種情況。
集羣中只有一個名字節點極大地簡單化了系統的體系。名字節點是仲裁者和所有HDFS的元數據的倉庫。系統設計成用戶的實際數據不經過名字節點（即客戶端要訪問HDFS中的一個文件，Client端首先從namenode獲得組成這個文件的數據塊位置列表，它根據列表知道存儲數據塊的datanode，然後Client端直接訪問datanode獲取數據，其中Namenode並不參與數據實際傳輸）。
文件命名空間
HDFS支持傳統的繼承式的文件組織。一個用戶或一個程序可以創建目錄，存儲文件到很多目錄之中。文件系統的名字空間層次和其他的文件系統相似。可以創建、移動文件，將文件從一個目錄移動到另外一個，或重命名。HDFS現在還沒有實現用戶的配額和訪問控制。HDFS還不支持硬鏈接和軟鏈接。然而，HDFS結構不排斥在將來實現這些功能。
名字節點維護文件的系統的命名空間，任何文件命名空間的改變和或屬性都被名字節點記錄。應用程序可以指定文件的複製數，文件的副本數被稱作文件的複製（replication）因子，這些信息由名字空間來負責存儲。
(複製因子由配置文件"hdfs-site.xml"裏的配置項目"dfs.replication "設置的)
數據複製
HDFS設計成可靠地在集羣中的大量機器之間存儲非常大量的文件，它以塊序列的形式存儲每一個文件。文件的除了最後一個塊的其他塊都是相同的大小（默認是64M，大小可以自定義）。屬於文件的塊爲了故障容錯而被複制。塊的大小和複製數可以爲每個文件配置。HDFS中的文件都是嚴格地任何時候只有一個寫操作。程序可以特別地爲某個文件指定複製數，文件的複製數可以在文件的創建的時候指定或者以後改變。名字節點來做所有的塊複製，它週期性地接收來自集羣中數據節點的心跳信號和塊報告（blockreport）（Datanode在啓動時，它會遍歷本地文件系統，產生一份hdfs數據塊和本地文件的對應關係列表（blockreport）彙報給namenode）。一個心跳的收條表示這個數據節點是健康的，是渴望服務數據的。一個塊報告包括該數據節點上的所有的塊列表。
複製塊的放置位置。第一個塊的階段
複製塊的放置位置的選擇嚴重影響HDFS的可靠性和性能。這個特徵是HDFS和其他的分佈式文件系統的區別。這個特徵需要很多的調節和經驗。根據機架的複製佈局目的就是提高數據的可靠性，可用性和網絡帶寬的利用。
當前的這方面的實現方式是在這個方向上的第一步。短期的目標實現是這個方式要在生產環境下去驗證，以得到它的行爲和實現一個爲將來的測試和研究更佳的方式的基礎。
HDFS運行在跨越很多機架的集羣機器之上。兩個不同機架上的節點通信是通過交換機的，在大多數情況下，兩個在相同機架上的節點之間的網絡帶寬是優於在不同的機架之上的兩個機器。
在開始的時候，每一個數據節點自檢它所屬的機架，然後在向名字節點註冊的時候告知它的機架id。HDFS提供接口以便很容易地掛載檢測機架標示的模塊。一個簡單但不是最優的方式就是將複製跨越不同的機架，這樣以保證在這個機架出現故障而不丟失數據，還能在讀數據的時候充分利用不同機架的帶寬。這個方式均勻地將複製分散在集羣中以簡單化地實現了組件實效的負載均衡，然而，這個方式增加了寫的成本，因爲寫的時候需要傳輸文件塊到很多的機架。
在大多數複製數爲3的普通的情況下，HDFS放置方式是將第一個放在本地節點，將第二個複製放到本地機架上的另外一個節點而將第三個複製放到不同機架上的節點。這種方式減少了機架內的寫流量，提高了寫的性能。機架失效的機會遠小於機器實效的。這種方式沒有影響數據的可靠性和可用性的保證。但是它減少了讀操作的網絡聚合帶寬，因爲文件塊存在兩個不同的機架， 而不是三個（而不是三個不同的機架上）。文件的複製不是均勻地分佈在機架當中。1/3在同一個節點上，第二個1/3複製在同一個機架的另外節點上，另外1/3是均勻地分佈在其他的機架上。這種方式提高了寫性能，而沒有影響數據的可靠性和讀性能。
上面的實現方式正在進行中。
複製的選擇
HDFS嘗試滿足一個讀操作來自離它最近的複製。假如在讀節點的同一個機架上就有這個複製，就直接讀這個，如果HDFS集羣是跨越多個數據中心，那麼本地數據中心的複製是優先於遠程的複製。
安全模式
在啓動的時候，名字節點進入一個特殊的狀態叫做安全模式。安全模式是不發生文件塊的複製的。名字節點接收來自數據節點的心跳和塊報告。一個塊報告包括的是數據節點向名字節點報告數據塊的列表。
每一個塊有一個特定的最小複製數。當名字節點檢查這個塊已經大於最小的複製數就被認爲是安全地複製了，在一定比例（可設置）的數據塊被確定爲“安全”後，再過若干時間（30s），名字節點就退出安全模式。它將檢測數據塊的列表，將小於特定複製數的塊
複製到其他的數據節點(假設最小複製數爲3，block_1只有兩個備份，所以block_1是不安全的，需要將其的備份數增加到3)。
文件系統的元數據的持久化
HDFS的命名空間是由名字節點來存儲的。名字節點用事務日誌叫做EditLog來持久化每一個對文件系統的元數據的改變，例如，在HDFS中創建一個新的文件，名字節點將會插入一條記錄到EditLog來標示這個改變。類似地，改變文件的複製因子也會向EditLog中插入一條記錄。名字節點在本地文件系統中用一個文件來存儲這個EditLog。
完整的文件系統命名空間、文件塊的映射和文件系統的配置都存在一個叫FsImage（映像文件）的文件中，FsImage也是名字節點的本地文件系統中。
名字節點在內存中有一個完整的文件系統命名空間和文件塊的映射鏡像。這個元數據時設計成緊湊的，這樣4G的內存的名字節點就能很輕鬆地處理非常大文件數和目錄，當名字節點啓動，它將從磁盤中讀取FsImage和EditLog應用EditLog中的所有的事務到內存中的FsImage表示方法，然後將新的元數據刷新到本地磁盤的新的FsImage中這樣可以截去舊的EditLog，因爲事務已經被處理並已經持久化的FsImage中。這個過程叫做檢查點。在現在的實現檢查點在名字節點啓動的時候發生。支持週期性的檢查點正在進行中。
數據節點存儲HDFS數據到本地的文件系統中。數據節點沒有關於HDFS文件的信息。它以單獨的文件存儲每一個HDFS的塊到本地文件系統中。數據節點不產生所有的文件到同一個目錄中，而是它用啓發式的檢測最優的每一個目錄的文件數。它在適當的時候創建子目錄。在本地文件的同一個目錄下創建所有的文件不是最優的，因爲本地文件系統可能單個目錄裏有數目巨大的文件效率較差。當數據節點啓動的時候，它將掃描它的本地文件系統，根據本地的文件產生一個所有HDFS數據塊的列表並報告給名字節點，這個報告稱作塊報告。
通信協議
所有的通信協議都是在TCP/IP協議之上的。一個客戶端和明確的配置端口的名字節點建立連接之後，它和名字節點的協議是ClientProtocal。數據節點和名字節點之間用DatanodeProtocal。詳細的這些協議將在後面解釋。
RPC抽象地包裝了ClientProtocol和DataNodeProtocol。根據設計，名字節點不會發起一個RPC，它只是對數據節點和客戶端發起的RPC做出反饋。
魯莽性
HDFS的主要目標就是在存在故障的情況下可靠地存儲數據。三個普通的故障是名字節點實效，數據節點實效，和網絡斷開
磁盤故障，心跳和重新複製
一個數據節點週期性發送一個心跳信息到名字節點。網絡斷開會造成一個數據節點子集和名字節點失去聯繫。名字節點發現這種情況是根據有沒有了心跳信息。名字節點標記這些數據節點是死掉了，就不再將新的IO請求轉發到這些數據節點上。而這些數據節點上的數據將對HDFS不再可用。這將導致一些塊的複製因子降低到指定的值。
名字節點檢查所有的需要複製的塊，並開始複製他們到其他的數據節點上。重新複製會因爲很多原因而必須 例如：數據節點變得比可用，被破壞了的複製，數據節點上的磁盤損壞或增加了文件的複製因子。
集羣的重新均衡
HDFS體系結構是兼容數據的重新平衡方案的。在數據節點的可用空間降低到一個極限時數據可能自動的從一個數據節點移動到另外一個，而且一個突然地對一個特殊的文件發生高請求時也會引發額外的複製，將集羣中的其他數據重新均衡。這種類型的重新均衡方案還沒有實現。
數據正確性
從數據節點上取一個文件塊有可能出現損壞的情況，這種情況可能會發生是因爲存儲設備，差勁的網絡，軟件的缺陷。HDFS客戶端實現了校驗去檢查HDFS的文件內容。當一個客戶端創建一個HDFS文件，它爲每一個文件快計算一個校驗碼並存儲校驗碼在同一個HDFS名字空間中的一個單獨的隱藏文件中。當客戶端找回這個文件內容時，它再根據這個校驗碼來驗證從數據節點接受到的數據。如果不對，客戶端可以從另外一個有該塊複製的數據節點取這個塊。
元數據磁盤實效
FsImage和Editlog是HDFS的中心數據結構。這些文件的損壞會導致整個集羣的不工作。應爲這個原因，名字節點可以配置成多個FsImage和EditLog的拷貝。任何的不管對FsImage和EditLog的更新都會同步地更新每一個拷貝。
這個同步的更新多個EditLog可能降低了名字節點的可支持名字空間的每秒交易數。但是這個降低是可接受的，因爲HDFS程序都是自然地對數據要求強烈，而不是對元數據的要求強烈。名字節點重新啓動時，選擇最新的一致的FsImage和EditLog。
名字節點隊以HDFS集羣是單點實效的。假如名字節點實效，手工的干涉是必要的，當前，自動的重啓和切換到另外的名字節點目前還不支持。
快照
快照支持在一個特定時間存儲一個數據拷貝，快照的一個用途可以將實效的集羣回滾到之前的一個正常時間點上。HDFS目前還不支持快照，但是將被將來的版本支持。
數據組織
數據塊 HDFS是設計成支持大文件數的。程序也是和HDFS一樣地處理大數據集。這些程序寫數據僅一次，讀數據一次或多次，需要一個比較好的流讀取速度。HDFS支持文件的寫一次讀多次的。HDFS典型的塊大小是64M，一個HDFS文件可以最多被切分成128MB個塊，每一個塊分佈在不同的數據節點上。
分段運輸
當一個客戶端請求創建一個文件的時候，並不是立即請求名字節點，事實是，HDFS客戶端在本地的文件中緩存文件數據，應用程序的寫操作明顯地轉移到這個臨時的本地文件。當本地文件堆積到大於HDFS塊大小的時候，客戶端聯繫名字節點。名字節點插入文件名到文件系統層次當中，然後構造一個數據塊。名字節點回應客戶端的請求包括數據節點（可能多個）的標識和目標數據塊，客戶端再將本地的臨時文件刷新指定的數據節點數據塊中。
當文件關閉，還有一些沒有刷新的本地臨時文件被傳遞到數據節點。客戶端就通知名字節點，這個文件已經關閉。這個時間和，名字節點提交文件的創建操作到持久化存儲。假如名字節點在文件關閉之前死掉，文件就丟掉了。
上面的方式在仔細地考慮運行在HDFS之上的目標程序之後被採用。應用程序需要流式地寫文件。如果客戶端直接寫到遠程文件系統，而沒有本地的緩衝對網速和網絡吞吐量產生相當的影響。這種方式也不是沒有前科，早期的分佈是文件系統，例如AFS也用客戶端的緩衝來提高性能，POSIX需求也不拘束高性能的數據上傳的實現。
流水線操作
當客戶端寫數據到HDFS文件中，像上面所講數據首先寫道本地文件中，假設HDFS的複製因子是3，當本地文件堆積到一塊大小的數據，客戶端從名字節點獲得一個數據節點的列表。這個列表描述一些數據節點將接管塊的複製。客戶端刷新數據塊到第一個數據節點。第一個數據節點開始接收數據到一個很小的位置（4kb），寫每一個部分到本地的庫中，而且傳輸每一個部分到列表中的第二個數據節點，這樣就輪到第二個數據節點，第二個數據節點如同第一個數據節點給第三個數據節點，第三個數據節點直接寫到本地的庫中。一個數據節點可以接受來自前一個的節點的數據，同時還可以將數據流水式傳遞給下一個節點，所以，數據時流水式地從一個數據節點傳遞到下一個。
可訪問
HDFS可以由應用程序多種方式存取，自然地，HDFS提供爲程序提供java api，爲c語言包裝的java api也是可以的，還有一個HTTP瀏覽HDFS中的文件，通過WebDAV協議訪問HDFS內容庫正在進行。
DFSShell
HDFS允許用戶數據由文件和文件夾式的管理，它提供一個接口叫DFSShell，讓用戶和HDFS中的數據交互
命令集的語法跟其他的shells（bash,csh）相似
創建目錄foodir : hadoop dfs -mkdir /foodir
查看文件 /foodir/myfile.txt : hadoop dfs -cat /foodir/myfile.txt
刪除文件/foodir/myfile.txt : hadoop dfs -rm /foodir myfile.txt
DFSAdmin
DFSAdmin命令集是用於管理dfs集羣的，這些命令只由HDFS管理員使用
將集羣設置成安全模式 : bin/hadoop dfsadmin -safemode enter
產生一個數據節點的列表 : bin/hadoop dfsadmin -report
去掉一個數據節點: bin/hadoop dfsadmin -decommission datanodename
瀏覽接口
典型的HDFS安裝配置了一個web 服務去暴露HDFS的命名空間，允許web瀏覽器去瀏覽HDFS的命名空間和查看
HDFS文件的內容
空間回收
文件刪除和恢復刪除
當一個文件被用戶或程序刪除，它並不是立即從HDFS中刪除，而是HDFS將它重新命名到/trash目錄下的文件，這個文件只要還在/trash目錄下保留就可以重新快速恢復。當這個文件在/trach裏呆夠配置的時間，名字節點就將它從名字空間中刪除，這個刪除將導致這個文件的文件塊都被釋放。這個時間間隔可以被感知，從用戶刪除文件到HDFS的空閒空間的增加。
用戶可以在刪除一個文件之後，它還在/trash目錄下的情況下，恢復刪除一個文件，如果一個用戶希望恢復刪除他已經刪除的文件，可以瀏覽/trash目錄，重新獲得這個文件。/trash目錄之保存最新版本的刪除文件。/trash目錄也像其他目錄一樣，只有一個特殊的功能，就是HDFS應用一個特定的規則，自動地刪除這個目錄裏的文件，當前默認的規則是刪除在此目錄呆夠6小時的文件，將來這個規則將由一個接口來配置。
減少複製因子
當文件的複製因子減少了，名字節點選擇過度的複製去刪除掉，下一次的心跳的時候傳遞這個信息給數據節點。數據節點移除相應的塊，相應的空閒空間將顯示在集羣中，這一點要注意的就是這個可能會有段時間過程在完成setReplication和顯示集羣的空閒空間。