一、HDFS是什麼？
HDFS（Hadoop Distributed File System）是Hadoop項目的核心子項目，是Hadoop主要應用的一個分佈式文件系統。“主要”表示Hadoop還有其他分佈式文件系統，“分佈式文件系統”說明HDFS的核心是一個文件系統，認識並把握住核心才能很好的理解HDFS。
文件系統的目的是用來管理怎樣存儲和讀取文件的，講到管理，就不得不瞭解其組織結構和運行規則。HDFS的組織結構是主從結構（master-slaves），運行規則指的是在主從結構中，master負責做什麼、slaves負責做什麼等。（wikipedia的解釋：The structure and logic rules used to manage the groups of information and their names is called a "file system".）
1、基礎介紹
數據塊（Block）
文件都是以塊的形式存儲在磁盤上，塊的大小就是系統讀/寫可操作的最小文件大小，一個磁盤的Block通常是512B。HDFS的塊是個抽象的概念，默認大小是64MB。把Block設置得這麼大，是因爲HDFS上的文件普遍都是大文件，如果Block很小，那一個文件就要存放在很多Block上，而這些位置信息都要被NameNode所記錄，一來浪費NameNode的存儲空間，二來檢索一個文件的時候開銷也比較高。當一個文件的長度小於一個Blocksize時，它會單獨佔用一個Block，但它佔用的磁盤空間仍然是其真實的長度。
NameNode和DataNode
NameNode（Master）管理集羣中的執行調度，管理文件系統的命名空間，維護整個文件系統的文件目錄樹及這些文件的索引目錄，DataNode（Slaves）是具體任務的執行節點。從NameNode中你可以獲得每個文件的每個塊所在的DataNode，需要注意的是，這些信息不是永久保存的，NameNode會在每次系統啓動時動態地重建這些信息。DataNode是真正存儲數據的地方。一般情況下一個Block會存放在多個不同的DataNode上，以提高容錯性。（SecondaryNameNode並不是NameNode出現問題後的備用節點，其主要功能是週期性地將NameNode的命名空間鏡像文件namespace
image和修改日誌edit log合併，以防日誌文件過大）
2、體系架構
HDFS採用Master-Slave架構對文件系統進行管理，一個集羣由一個NameNode和一定數目的DataNode組成。客戶端聯繫NameNode以獲取文件的元數據，而真正的文件I/O操作是直接和DataNode進行交互的。
寫文件
Client向NameNode發起文件寫入的請求。NameNode根據文件大小和文件塊配置情況，返回給Client它所管理部分DataNode的信息。Client將文件劃分爲多個Block，根據DataNode的地址信息，按順序寫入到每一個DataNode塊中。
讀文件
Client向NameNode發起文件讀取的請求。NameNode返回文件存儲的DataNode的信息。Client讀取文件信息。
二、HDFS能做什麼？
1、優點
A：處理超大文件
存儲並處理超大文件，上G、T甚至P的超大文件。
B：流式的訪問數據
HDFS的設計建立在更多地響應"一次寫入、多次讀寫"任務的假設上。這意味着一個數據集一旦由數據源生成，就會被複制分發到不同的存儲節點中，然後響應各種各樣的數據分析任務請求。在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說，請求讀取整個數據集要比讀取一條記錄更加高效。
C：搭建在普通商業機羣上
Hadoop設計對硬件需求比較低，只須運行在低廉的商用硬件集羣上，而無需昂貴的高可用性機器上。廉價的商用機器也就意味着大型集羣中出現節點故障情況的概率非常高。這就要求設計HDFS時要充分考慮數據的可靠性、安全性及高可用性。
2、缺點
A：低延時訪問
HDFS不適合於那些要求低延時（數十毫秒）訪問的應用程序，因爲HDFS是設計用於處理大吞吐量數據的，這是以一定延時爲代價的。HDFS是單Master的，所有的對文件的請求都要經過它，當請求多時，肯定會有延時。當前，對於那些有低延時要求的應用程序，HBase是一個更好的選擇，它的口號就是goes real time。
使用緩存或多master設計可以降低client的數據請求壓力，以減少延時。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延時了，HDFS不是萬能的銀彈。
B：大量小文件
因爲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節點組成。
C：多用戶寫，任意文件修改
目前Hadoop只支持單用戶寫，不支持併發多用戶寫。可以使用Append操作在文件的末尾添加數據，但不支持在文件的任意位置進行修改。這些特性可能會在將來的版本中加入，但是這些特性的加入將會降低Hadoop的效率，就拿GFS來說吧，這篇文章裏就說了google自己的人都用着Multiple Writers很不爽。
利用Chubby、ZooKeeper之類的分佈式協調服務來解決一致性問題。
參考書目：《Hadoop實戰》《Hadoop權威指南》《Hadoop技術內幕》