解讀HDFS
是蠻久木有寫過關於hadoop的博客了額，雖然最近也看了一些關於linux的基礎知識，但似乎把這個東西忘記了，其實時不時回顧一下以前的知識還是蠻有意思的，且行且憶！
我們Hadoop 主要由HDFS和MapReduce 引擎兩部分組成。最底部是HDFS，它存儲Hadoop 集羣中所有存儲節點上的文件。HDFS 的上一層是MapReduce 引擎，該引擎由JobTrackers 和TaskTrackers組成。
這篇博客就主要來講講HDFS吧~~~
HDFS是Hadoop Distributed File System的簡稱，既然是分佈式文件系統，首先它必須是一個文件系統，那麼在hadoop上面的文件系統會不會也像一般的文件系統一樣由目錄結構和一組文件構成呢？！分佈式是不是就是將文件分成幾部分分別存儲在不同的機器上呢？！HDFS到底有什麼優點值得這麼小題大作呢？！......
好吧，讓我們帶着疑問一個個去探索吧！
一、HDFS基本概念
1、數據塊
HDFS默認的最基本的存儲單位是64M的數據塊，這個數據塊可以理解和一般的文件裏面的分塊是一樣的
2、元數據節點和數據節點
元數據節點（namenode）用來管理文件系統的命名空間，它將所有的文件和文件夾的元數據保存在一個文件系統樹中。
數據節點（datanode）就是用來存儲數據文件的。
從元數據節點（secondarynamenode）不是我們所想象的元數據節點的備用節點，其實它主要的功能是主要功能就是週期性將元數據節點的命名空間鏡像文件和修改日誌合併，以防日誌文件過大。
這裏先來弄清楚這個三種節點的關係吧！其實元數據節點上存儲的東西就相當於一般文件系統中的目錄，也是有命名空間的映射文件以及修改的日誌，只是分佈式文件系統就將數據分佈在各個機器上進行存儲罷了，下面你看看這幾張說明圖應該就能明白了！
Namenode與secondary namenode之間的進行checkpoint的過程。
3、HDFS中的數據流
讀文件
客戶端(client)用FileSystem的open()函數打開文件，DistributedFileSystem用RPC調用元數據節點，得到文件的數據塊信息。對於每一個數據塊，元數據節點返回保存數據塊的數據節點的地址。DistributedFileSystem返回FSDataInputStream給客戶端，用來讀取數據。客戶端調用stream的read()函數開始讀取數據。DFSInputStream連接保存此文件第一個數據塊的最近的數據節點。Data從數據節點讀到客戶端(client)，當此數據塊讀取完畢時，DFSInputStream關閉和此數據節點的連接，然後連接此文件下一個數據塊的最近的數據節點。當客戶端讀取完畢數據的時候，調用FSDataInputStream的close函數。
整個過程就是如圖所示：
寫文件
客戶端調用create()來創建文件，DistributedFileSystem用RPC調用元數據節點，在文件系統的命名空間中創建一個新的文件。元數據節點首先確定文件原來不存在，並且客戶端有創建文件的權限，然後創建新文件。DistributedFileSystem返回DFSOutputStream，客戶端用於寫數據。客戶端開始寫入數據，DFSOutputStream將數據分成塊，寫入data queue。Data queue由Data Streamer讀取，並通知元數據節點分配數據節點，用來存儲數據塊(每塊默認複製3塊)。分配的數據節點放在一個pipeline裏。Data Streamer將數據塊寫入pipeline中的第一個數據節點。第一個數據節點將數據塊發送給第二個數據節點。第二個數據節點將數據發送給第三個數據節點。DFSOutputStream爲發出去的數據塊保存了ack queue，等待pipeline中的數據節點告知數據已經寫入成功。如果數據節點在寫入的過程中失敗：關閉pipeline，將ack queue中的數據塊放入data queue的開始。
整個過程如圖所示：
HDFS構架與設計
Hadoop也是一個能夠分佈式處理大規模海量數據的軟件框架，這一切都是在可靠、高效、可擴展的基礎上。Hadoop的可靠性——因爲Hadoop假設計算元素和存儲會出現故障，因爲它維護多個工作數據副本，在出現故障時可以對失敗的節點重新分佈處理。Hadoop的高效性——在MapReduce的思想下，Hadoop是並行工作的，以加快任務處理速度。Hadoop的可擴展——依賴於部署Hadoop軟件框架計算集羣的規模，Hadoop的運算是可擴展的，具有處理PB級數據的能力。
Hadoop 主要由HDFS（Hadoop Distributed File System）和MapReduce 引擎兩部分組成。最底部是HDFS，它存儲Hadoop 集羣中所有存儲節點上的文件。HDFS 的上一層是MapReduce 引擎，該引擎由JobTrackers 和TaskTrackers組成。
HDFS 可以執行的操作有創建、刪除、移動或重命名文件等，架構類似於傳統的分級文件系統。需要注意的是，HDFS 的架構基於一組特定的節點而構建（參見圖2），這是它自身的特點。HDFS 包括唯一的NameNode，它在HDFS 內部提供元數據服務；DataNode 爲HDFS 提供存儲塊。由於NameNode 是唯一的，這也是HDFS 的一個弱點（單點失敗）。一旦NameNode 故障，後果可想而知。
1、HDFS構架（如圖所示）
2、HDFS的設計
1）錯誤檢測和快速、自動的恢復是HDFS的核心架構目標。
2）比之關注數據訪問的低延遲問題，更關鍵的在於數據訪問的高吞吐量。
3）HDFS應用對文件要求的是write-one-read-many訪問模型。
4）移動計算的代價比之移動數據的代價低。
3、文件系統的namespace
Namenode維護文件系統的namespace，一切對namespace和文件屬性進行修改的都會被namenode記錄下來，連文件副本的數目稱爲replication因子，這個也是由namenode記錄的。
4、數據複製
Namenode全權管理block的複製，它週期性地從集羣中的每個Datanode接收心跳包和一個Blockreport。心跳包的接收表示該Datanode節點正常工作，而Blockreport包括了該Datanode上所有的block組成的列表。HDFS採用一種稱爲rack-aware的策略來改進數據的可靠性、有效性和網絡帶寬的利用。完成對副本的存放。
5、文件系統元數據的持久化
Namenode在內存中保存着整個文件系統namespace和文件Blockmap的映像。這個關鍵的元數據設計得很緊湊，因而一個帶有4G內存的 Namenode足夠支撐海量的文件和目錄。當Namenode啓動時，它從硬盤中讀取Editlog和FsImage，將所有Editlog中的事務作用（apply)在內存中的FsImage ，並將這個新版本的FsImage從內存中flush到硬盤上,然後再truncate這個舊的Editlog，因爲這個舊的Editlog的事務都已經作用在FsImage上了。這個過程稱爲checkpoint。在當前實現中，checkpoint只發生在Namenode啓動時，在不久的將來我們將實現支持週期性的checkpoint。
6、通信協議
所有的HDFS通訊協議都是構建在TCP/IP協議上。客戶端通過一個可配置的端口連接到Namenode，通過ClientProtocol與 Namenode交互。而Datanode是使用DatanodeProtocol與Namenode交互。從ClientProtocol和 Datanodeprotocol抽象出一個遠程調用(RPC），在設計上，Namenode不會主動發起RPC，而是是響應來自客戶端和 Datanode 的RPC請求。
HDFS不是這麼簡單就能說清楚的，在以後的博客中我還會繼續研究hadoop的分佈式文件系統，包括HDFS的源碼分析等，現由於時間有限，暫時只做了以上一些簡單的介紹吧，希望對大家由此對HDFS有一定的瞭解！
<!--EndFragment-->