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