1.1體系結構簡單介紹
HDFS是一個主/從（Mater/Slave）體系結構。從終於用戶的角度來看，它就像傳統的文件系統一樣，能夠通過文件夾路徑對文件運行CRUD（Create、Read、Update和Delete）操作。但因為分布式存儲的性質，HDFS集群擁有一個NameNode和一些DataNode。NameNode管理文件系統的元數據，DataNode存儲實際的數據。
client通過同NameNode和DataNodes的交互訪問文件系統。
client聯系NameNode以獲取文件的元數據，而真正的文件I/O操作是直接和DataNode進行交互的。 下圖為HDFS整體結構示意圖
1.1.1 NameNode
NameNode能夠看作是分布式文件系統中的管理者。主要負責管理文件系統的命名空間、集群配置信息和存儲塊的復制等。NameNode會將文件系統的Meta-data存儲在內存中，這些信息主要包含了文件信息、每個文件相應的文件塊的信息和每個文件塊在DataNode的信息等。
l Masterl 管理HDFS的名稱空間l 管理數據塊映射信息l 配置副本策略l 處理client讀寫請求
1.1.2 Secondary namenode
並不是NameNode的熱備； 輔助NameNode，分擔其工作量； 定期合並fsimage和fsedits，推送給NameNode； 在緊急情況下。可輔助恢復NameNode。
1.1.3 DataNode
DataNode是文件存儲的基本單元，它將Block存儲在本地文件系統中，保存了Block的Meta-data，同一時候周期性地將全部存在的Block信息發送給NameNode。
Slavel 存儲實際的數據塊 運行數據塊讀/寫
1.1.4 Client
文件切分 與NameNode交互，獲取文件位置信息； 與DataNode交互。讀取或者寫入數據； 管理HDFS。 訪問HDFS。
1.1.5 文件寫入
1) Client向NameNode發起文件寫入的請求。 2) NameNode依據文件大小和文件塊配置情況。返回給Client它所管理部分DataNode的信息。 3) Client將文件划分為多個Block，依據DataNode的地址信息，按順序寫入到每個DataNode塊中。
1.1.6 文件讀取
1) Client向NameNode發起文件讀取的請求。 2) NameNode返回文件存儲的DataNode的信息。
3) Client讀取文件信息。
HDFS典型的部署是在一個專門的機器上執行NameNode，集群中的其它機器各執行一個DataNode；也能夠在執行NameNode的機器上同一時候執行DataNode，或者一台機器上執行多個DataNode。一個集群僅僅有一個NameNode的設計大大簡化了系統架構。
1.2長處
1.2.1 處理超大文件
這里的超大文件一般是指百MB、設置數百TB大小的文件。眼下在實際應用中，HDFS已經能用來存儲管理PB級的數據了。
1.2.2 流式的訪問數據
HDFS的設計建立在很多其它地響應"一次寫入、多次讀寫"任務的基礎上。
這意味着一個數據集一旦由數據源生成。就會被復制分發到不同的存儲節點中，然后響應各種各樣的數據分析任務請求。
在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說。請求讀取整個數據集要比讀取一條記錄更加高效。
1.2.3 執行於便宜的商用機器集群上
hadoop設計對硬件需求比較低。僅僅須執行在低廉的商用硬件集群上，而無需昂貴的高可用性機器上。便宜的商用機也就意味着大型集群中出現節點故障情況的概率很高。這就要求設計HDFS時要充分考慮數據的可靠性，安全性及高可用性。
1.3 缺點
1.3.1 不適合低延遲數據訪問
假設要處理一些用戶要求時間比較短的低延遲應用請求。則HDFS不適合。HDFS是為了處理大型數據集分析任務的，主要是為達到高的數據吞吐量而設計的，這就可能要求以高延遲作為代價。
改進策略：
對於那些有低延時要求的應用程序，HBase是一個更好的選擇。
通過上層數據管理項目來盡可能地彌補這個不足。在性能上有了非常大的提升，它的口號就是goes real time。
使用緩存或多master設計能夠降低client的數據請求壓力，以降低延時。還有就是對HDFS系統內部的改動，這就得權衡大吞吐量與低延時了，HDFS不是萬能的銀彈。
1.3.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集群拖在一個虛擬server后面。形成一個大的Hadoop集群。google也是這么干過的。多Master設計，這個作用顯而易見了。正在研發中的GFS II也要改為分布式多Master設計，還支持Master的Failover。並且Block大小改為1M。有意要調優處理小文件啊。
附帶個Alibaba DFS的設計，也是多Master設計。它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節點和一個查詢Master節點組成。
1.3.3 不支持多用戶寫入及隨意改動文件
在HDFS的一個文件里僅僅有一個寫入者，並且寫操作僅僅能在文件末尾完畢。即僅僅能運行追加操作。
眼下HDFS還不支持多個用戶對同一文件的寫操作，以及在文件任何位置進行改動。