本文主要從兩個方面對hdfs進行闡述，第一就是hdfs的整個架構以及組成，第二就是hdfs文件的讀寫流程。
一、HDFS概述
標題中提到hdfs（Hadoop Distribute File System）是分布式文件系統
分布式文件系統 distributed file system 是指文件系統管理的物理存儲資源不一定直接鏈接在本地節點上，而是通過計算機網絡與節點相連，可讓多機器上的多用戶分享文件和存儲空間。分布式文件系統的設計基於客戶機/服務器模式
分布式文件系統的特點：
1、分布式文件系統可以有效解決數據的存儲和管理難題
2、將固定於某個地點的某個文件系統，擴展到任意多個地點/多個文件系統
3、眾多的節點組成一個文件系統網絡
4、每個節點可以分布在不同的地點，通過網絡進行節點間的通信和數據傳輸
5、在使用分布式文件系統時，無需關心數據是存儲在哪個節點上、或者是從哪個節點獲取的，只需要像使用本地文件系統一樣管理和存儲文件系統中的數據
Hadoop之（HDFS）是一種分布式文件系統，設計用於在商用硬件上運行。 它與現有的分布式文件系統有許多相似之處。 但是，與其他分布式文件系統的差異很大。
HDFS具有高度容錯能力，旨在部署在低成本硬件上。
HDFS提供對應用程序數據的高吞吐量訪問，適用於具有大型數據集的應用程序。
HDFS放寬了一些POSIX要求，以實現對文件系統數據的流式訪問
HDFS優勢：
1、可構建在廉價機器上，設備成本相對低
2、高容錯性，HDFS將數據自動保存多個副本，副本丟失后，自動恢復，防止數據丟失或損壞
3、適合批處理，HDFS適合一次寫入、多次查詢（讀取）的情況，適合在已有的數據進行多次分析，穩定性好
4、適合存儲大文件，其中的大表示可以存儲單個大文件，因為是分塊存儲，以及表示存儲大量的數據
HDFS劣勢：
1、由於提高吞吐量，降低實時性
2、由於每個文件都會在namenode中記錄元數據，如果存儲了大量的小文件，會對namenode造成很大的壓力
3、不合適小文件處理，在mapreduce的過程中小文件的數量會造成map數量的增大，導致資源被占用，而且速度慢。
4、不適合文件的修改，文件只能追加在文件的末尾，不支持任意位置修改，不支持多個寫入者操作
二、HDFS架構
hdfs架構圖如下圖所示：
HDFS具有主/從架構。HDFS集群由單個NameNode，和多個datanode構成。
NameNode：管理文件系統命名空間的主服務器和管理客戶端對文件的訪問組成，如打開，關閉和重命名文件和目錄。負責管理文件目錄、文件和block的對應關系以及block和datanode的對應關系，維護目錄樹，接管用戶的請求。如下圖所示：
1、將文件的元數據保存在一個文件目錄樹中
2、在磁盤上保存為：fsimage 和 edits
3、保存datanode的數據信息的文件，在系統啟動的時候讀入內存。
DataNode：（數據節點）管理連接到它們運行的節點的存儲，負責處理來自文件系統客戶端的讀寫請求。DataNodes還執行塊創建，刪除
Client：(客戶端)代表用戶通過與nameNode和datanode交互來訪問整個文件系統，HDFS對外開放文件命名空間並允許用戶數據以文件形式存儲。用戶通過客戶端（Client）與HDFS進行通訊交互。
塊和復制：
我們都知道linux操作系統中的磁盤的塊的大小默認是512，而hadoop2.x版本中的塊的大小默認為128M，那為什么hdfs中的存儲塊要設計這么大呢？
其目的是為了減小尋址的開銷。只要塊足夠大，磁盤傳輸數據的時間必定會明顯大於這個塊的尋址時間。
那為什么要以塊的形式存儲文件，而不是整個文件呢？
1、因為一個文件可以特別大，可以大於有個磁盤的容量，所以以塊的形式存儲，可以用來存儲無論大小怎樣的文件。
2、簡化存儲系統的設計。因為塊是固定的大小，計算磁盤的存儲能力就容易多了
3、以塊的形式存儲不需要全部存在一個磁盤上，可以分布在各個文件系統的磁盤上，有利於復制和容錯，數據本地化計算
塊和復本在hdfs架構中分布如下圖所示：
既然namenode管理着文件系統的命名空間，維護着文件系統樹以及整顆樹內的所有文件和目錄，這些信息以文件的形式永遠的保存在本地磁盤上，分別問命名空間鏡像文件fsimage和編輯日志文件Edits。datanode是文件的工作節點，根據需要存儲和檢索數據塊，並且定期的向namenode發送它們所存儲的塊的列表。那么就知道namenode是多么的重要，一旦那么namenode掛了，那整個分布式文件系統就不可以使用了，所以對於namenode的容錯就顯得尤為重要了，hadoop為此提供了兩種容錯機制：
容錯機制一：
就是通過對那些組成文件系統的元數據持久化，分別問命名空間鏡像文件fsimage（文件系統的目錄樹）和編輯日志文件Edits（針對文件系統做的修改操作記錄）。磁盤上的映像FsImage就是一個Checkpoint,一個里程碑式的基准點、同步點,有了一個Checkpoint之后,NameNode在相當長的時間內只是對內存中的目錄映像操作,同時也對磁盤上的Edits操作,直到關機。下次開機的時候,NameNode要從磁盤上裝載目錄映像FSImage,那其實就是老的Checkpoint,也許就是上次開機后所保存的映像,而自從上次開機后直到關機為止對於文件系統的所有改變都記錄在Edits文件中;將記錄在Edits中的操作重演於上一次的映像,就得到這一次的新的映像,將其寫回磁盤就是新的Checkpoint（也就是fsImage）。但是這樣有很大一個缺點，如果Edits很大呢，開機后生成原始映像的過程也會很長，所以對其進行改進：每當 Edits長到一定程度,或者每隔一定的時間,就做一次Checkpoint，但是這樣就會給namenode造成很大的負荷，會影響系統的性能。於是就有了SecondaryNameNode的需要,這相當於NameNode的助理,專替NameNode做Checkpoint。當然,SecondaryNameNode的負載相比之下是偏輕的。所以如果為NameNode配上了熱備份,就可以讓熱備份兼職,而無須再有專職的SecondaryNameNode。所以架構圖如下圖所示：
SecondaryNameNode工作原理圖：
SecondaryNameNode主要負責下載NameNode中的fsImage文件和Edits文件，並合並生成新的fsImage文件，並推送給NameNode，工作原理如下：
1、secondarynamenode請求主namenode停止使用edits文件，暫時將新的寫操作記錄到一個新的文件中；
2、secondarynamenode從主namenode獲取fsimage和edits文件（通過http get）
3、secondarynamenode將fsimage文件載入內存，逐一執行edits文件中的操作，創建新的fsimage文件。
4、secondarynamenode將新的fsimage文件發送回主namenode（使用http post）.
5、namenode用從secondarynamenode接收的fsimage文件替換舊的fsimage文件；用步驟1所產生的edits文件替換舊的edits文件。同時，還更新fstime文件來記錄檢查點執行時間。
6、最終，主namenode擁有最新的fsimage文件和一個更小的edits文件。當namenode處在安全模式時，管理員也可調用hadoop dfsadmin –saveNameSpace命令來創建檢查點。
從上面的過程中我們清晰的看到secondarynamenode和主namenode擁有相近內存需求的原因（因為secondarynamenode也把fsimage文件載入內存）。因此，在大型集群中，secondarynamenode需要運行在一台專用機器上。
創建檢查點的觸發條件受兩個配置參數控制。通常情況下，secondarynamenode每隔一小時（有fs.checkpoint.period屬性設置）創建檢查點；此外，當編輯日志的大小達到64MB（有fs.checkpoint.size屬性設置）時，也會創建檢查點。系統每隔五分鍾檢查一次編輯日志的大小。
容錯機制二：
高可用方案（詳情見：hadoop高可用安裝和原理詳解）
三、HDFS讀數據流程
HDFS讀數據流程如下圖所示：
1、客戶端通過FileSystem對象（DistributedFileSystem）的open()方法來打開希望讀取的文件。
2、DistributedFileSystem通過遠程調用（RPC）來調用namenode，獲取到每個文件的起止位置。對於每一個塊，namenode返回該塊副本的datanode。這些datanode會根據它們與客戶端的距離（集群的網絡拓撲結構）排序，如果客戶端本身就是其中的一個datanode，那么就會在該datanode上讀取數據。DistributedFileSystem遠程調用后返回一個FSDataInputStream（支持文件定位的輸入流）對象給客戶端以便於讀取數據，然后FSDataInputStream封裝一個DFSInputStream對象。該對象管理datanode和namenode的IO。
3、客戶端對這個輸入流調用read()方法，存儲着文件起始幾個塊的datanode地址的DFSInputStream隨即連接距離最近的文件中第一個塊所在的datanode，通過數據流反復調用read()方法，可以將數據從datanode傳送到客戶端。當讀完這個塊時，DFSInputStream關閉與該datanode的連接，然后尋址下一個位置最佳的datanode。
客戶端從流中讀取數據時，塊是按照打開DFSInputStream與datanode新建連接的順序讀取的。它也需要詢問namenode來檢索下一批所需塊的datanode的位置。一旦客戶端完成讀取，就對FSDataInputStream調用close()方法。
注意：在讀取數據的時候，如果DFSInputStream在與datanode通訊時遇到錯誤，它便會嘗試從這個塊的另外一個臨近datanode讀取數據。他也會記住那個故障datanode，以保證以后不會反復讀取該節點上后續的塊。DFSInputStream也會通過校驗和確認從datanode發送來的數據是否完整。如果發現一個損壞的塊， DFSInputStream就會在試圖從其他datanode讀取一個塊的復本之前通知namenode。
總結：在這個設計中，namenode會告知客戶端每個塊中最佳的datanode，並讓客戶端直接聯系該datanode且檢索數據。由於數據流分散在該集群中的所有datanode，所以這種設計會使HDFS可擴展到大量的並發客戶端。同時，namenode僅需要響應位置的請求（這些信息存儲在內存中，非常高效），而無需響應數據請求，否則隨着客戶端數量的增長，namenode很快會成為一個瓶頸。
四、HDFS寫數據流程
HDFS寫數據流程圖如下圖所示：
1、首先客戶端通過DistributedFileSystem上的create()方法指明一個預創建的文件的文件名
2、DistributedFileSystem再通過RPC調用向NameNode申請創建一個新文件（這時該文件還沒有分配相應的block）。namenode檢查是否有同名文件存在以及用戶是否有相應的創建權限，如果檢查通過，namenode會為該文件創建一個新的記錄，否則的話文件創建失敗，客戶端得到一個IOException異常。DistributedFileSystem返回一個FSDataOutputStream以供客戶端寫入數據，與FSDataInputStream類似，FSDataOutputStream封裝了一個DFSOutputStream用於處理namenode與datanode之間的通信。
3、當客戶端開始寫數據時（，DFSOutputStream把寫入的數據分成包（packet）, 放入一個中間隊列——數據隊列（data queue）中去。DataStreamer從數據隊列中取數據，同時向namenode申請一個新的block來存放它已經取得的數據。namenode選擇一系列合適的datanode（個數由文件的replica數決定）構成一個管道線（pipeline），這里我們假設replica為3，所以管道線中就有三個datanode。
4、DataSteamer把數據流式的寫入到管道線中的第一個datanode中，第一個datanode再把接收到的數據轉到第二個datanode中，以此類推。
5、DFSOutputStream同時也維護着另一個中間隊列——確認隊列（ack queue），確認隊列中的包只有在得到管道線中所有的datanode的確認以后才會被移出確認隊列
如果某個datanode在寫數據的時候當掉了，下面這些對用戶透明的步驟會被執行：
管道線關閉，所有確認隊列上的數據會被挪到數據隊列的首部重新發送，這樣可以確保管道線中當掉的datanode下流的datanode不會因為當掉的datanode而丟失數據包。
在還在正常運行的datanode上的當前block上做一個標志，這樣當當掉的datanode重新啟動以后namenode就會知道該datanode上哪個block是剛才當機時殘留下的局部損壞block，從而可以把它刪掉。
已經當掉的datanode從管道線中被移除，未寫完的block的其他數據繼續被寫入到其他兩個還在正常運行的datanode中去，namenode知道這個block還處在under-replicated狀態（也即備份數不足的狀態）下，然后他會安排一個新的replica從而達到要求的備份數，后續的block寫入方法同前面正常時候一樣。有可能管道線中的多個datanode當掉（雖然不太經常發生），但只要dfs.replication.min（默認為1）個replica被創建，我們就認為該創建成功了。剩余的replica會在以后異步創建以達到指定的replica數。
6、當客戶端完成寫數據后，它會調用close()方法。這個操作會沖洗（flush）所有剩下的package到pipeline中。
7、等待這些package確認成功，然后通知namenode寫入文件成功。這時候namenode就知道該文件由哪些block組成（因為DataStreamer向namenode請求分配新block，namenode當然會知道它分配過哪些blcok給給定文件），它會等待最少的replica數被創建，然后成功返回。
注意：hdfs在寫入的過程中，有一點與hdfs讀取的時候非常相似，就是：DataStreamer在寫入數據的時候，每寫完一個datanode的數據塊,都會重新向nameNode申請合適的datanode列表。這是為了保證系統中datanode數據存儲的均衡性。
hdfs寫入過程中，datanode管線的確認應答包並不是每寫完一個datanode，就返回一個確認應答，而是一直寫入，直到最后一個datanode寫入完畢后，統一返回應答包。如果中間的一個datanode出現故障，那么返回的應答就是前面完好的datanode確認應答，和故障datanode的故障異常。這樣我們也就可以理解，在寫入數據的過程中，為什么數據包的校驗是在最后一個datanode完成。
更多hadoop生態文章見： hadoop生態系列
參考：
《Hadoop權威指南 大數據的存儲與分析 第四版》
https://hadoop.apache.org/docs/r2.7.7/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html