1.HDFS簡(jiǎn)介

正如其名碍脏，HDFS（Hadoop Distribution File System）是一個(gè)分布式文件系統(tǒng)梭依，它在商用服務(wù)器集群中存儲(chǔ)文件，用來存儲(chǔ)和快速訪問大文件與大數(shù)據(jù)集典尾。這是一個(gè)可擴(kuò)展役拴、可容錯(cuò)的系統(tǒng)。

HDFS的優(yōu)點(diǎn)：

• 兼容廉價(jià)的硬件設(shè)備
• 流數(shù)據(jù)讀寫
• 大數(shù)據(jù)集
• 簡(jiǎn)單的文件模型
• 強(qiáng)大的跨平臺(tái)模型

HDFS的局限性：

• 不適合低延遲數(shù)據(jù)訪問
• 無法高效存儲(chǔ)大量小文件
• 不支持多用戶寫入及任意修改文件

2.HDFS相關(guān)概念

2.1 塊結(jié)構(gòu)

HDFS是一個(gè)塊結(jié)構(gòu)的文件系統(tǒng)。正像Linux文件系統(tǒng)那樣，HDFS把文件分成固定大小的塊通常叫做分塊或者分片，每個(gè)快作為獨(dú)立的單元進(jìn)行存儲(chǔ)。默認(rèn)的塊大小為64MB送朱，但是可以配置。我們所熟悉的普通文件系統(tǒng)的塊一般只有幾千字節(jié)，從這個(gè)塊的大小清楚的看到，HDFS不是用來存儲(chǔ)小文件的，這樣做的好處就是最小化尋址開銷汞贸。HDFS采用抽象的塊概念可以帶來以下幾個(gè)明顯的好處：

• 支持大規(guī)模文件存儲(chǔ)：文件以塊為單位進(jìn)行存儲(chǔ)绳军，一個(gè)大規(guī)模文件可以被分拆成若干個(gè)文件塊，不同的文件塊可以被分發(fā)到不同的節(jié)點(diǎn)上矢腻，因此门驾，一個(gè)文件的大小不會(huì)受到單個(gè)節(jié)點(diǎn)的存儲(chǔ)容量的限制，可以遠(yuǎn)遠(yuǎn)大于網(wǎng)絡(luò)中任意節(jié)點(diǎn)的存儲(chǔ)容量多柑。
• 簡(jiǎn)化系統(tǒng)設(shè)計(jì)：首先奶是，大大簡(jiǎn)化了存儲(chǔ)管理，因?yàn)槲募K大小是固定的竣灌，這樣就可以很容易計(jì)算出一個(gè)節(jié)點(diǎn)可以存儲(chǔ)多少文件塊聂沙；其次，方便了元數(shù)據(jù)的管理初嘹，元數(shù)據(jù)不需要和文件塊一起存儲(chǔ)及汉，可以由其他系統(tǒng)負(fù)責(zé)管理元數(shù)據(jù)。
• 適合數(shù)據(jù)備份：每個(gè)文件塊都可以冗余存儲(chǔ)到多個(gè)節(jié)點(diǎn)上屯烦，大大提高了系統(tǒng)的容錯(cuò)性和可用性坷随。

2.2 HDFS主要組件的功能

一個(gè)HDFS集群包含兩種類型的節(jié)點(diǎn)：NameNode和DataNode。

NameNode周期性接收來自HDFS集群中DataNode的兩種類型的消息，分別叫做心跳消息和塊報(bào)告消息翁狐。DataNode發(fā)送一個(gè)心跳消息來告知NameNode工作正常类溢。塊報(bào)告消息包含一個(gè)DataNode上所有數(shù)據(jù)塊的列表。

2.3名稱節(jié)點(diǎn) NameNode

?在HDFS中露懒，名稱節(jié)點(diǎn)（NameNode）負(fù)責(zé)管理分布式文件系統(tǒng)的命名空間（Namespace）豌骏，保存了兩個(gè)核心的數(shù)據(jù)結(jié)構(gòu)龟梦，即FsImage和EditLog。

• ?FsImage用于維護(hù)文件系統(tǒng)樹以及文件樹中所有的文件和文件夾的元數(shù)據(jù)窃躲。
• ?操作日志文件EditLog中記錄了所有針對(duì)文件的創(chuàng)建计贰、刪除、重命名等操作蒂窒。

NameNode記錄了每個(gè)文件中各個(gè)塊所在數(shù)據(jù)節(jié)點(diǎn)的位置信息躁倒。

image.png

FSImage文件

FsImage文件包含文件系統(tǒng)中所有目錄和文件inode的序列化形式。每個(gè)inode是一個(gè)文件或目錄的元數(shù)據(jù)的內(nèi)部表示洒琢，并包含此類信息：文件的復(fù)制等級(jí)秧秉、修改和訪問時(shí)間、訪問權(quán)限衰抑、塊大小以及組成文件的塊象迎。對(duì)于目錄，則存儲(chǔ)修改時(shí)間呛踊、權(quán)限和配額元數(shù)據(jù)砾淌。

FsImage文件沒有記錄文件包含哪些塊以及每個(gè)塊存儲(chǔ)在哪個(gè)數(shù)據(jù)節(jié)點(diǎn)。而是由名稱節(jié)點(diǎn)把這些映射信息保留在內(nèi)存中谭网，當(dāng)數(shù)據(jù)節(jié)點(diǎn)加入HDFS集群時(shí)汪厨，數(shù)據(jù)節(jié)點(diǎn)會(huì)把自己所包含的塊列表告知給名稱節(jié)點(diǎn)，此后會(huì)定期執(zhí)行這種告知操作愉择，以確保名稱節(jié)點(diǎn)的塊映射是最新的劫乱。

NameNode的啟動(dòng)

在名稱節(jié)點(diǎn)啟動(dòng)的時(shí)候，它會(huì)將FsImage文件中的內(nèi)容加載到內(nèi)存中锥涕，之后再執(zhí)行EditLog文件中的各項(xiàng)操作衷戈，使得內(nèi)存中的元數(shù)據(jù)和實(shí)際的同步，存在內(nèi)存中的元數(shù)據(jù)支持客戶端的讀操作层坠。

一旦在內(nèi)存中成功建立文件系統(tǒng)元數(shù)據(jù)的映射脱惰，則創(chuàng)建一個(gè)新的FsImage文件和一個(gè)空的EditLog文件。

名稱節(jié)點(diǎn)起來之后窿春，HDFS中的更新操作會(huì)重新寫到EditLog文件中拉一，因?yàn)?code>FsImage文件一般都很大（GB級(jí)別的很常見），如果所有的更新操作都往FsImage文件中添加旧乞，這樣會(huì)導(dǎo)致系統(tǒng)運(yùn)行的十分緩慢蔚润，但是，如果往EditLog文件里面寫就不會(huì)這樣尺栖，因?yàn)?code>EditLog要小很多嫡纠。每次執(zhí)行寫操作之后，且在向客戶端發(fā)送成功代碼之前，edits文件都需要同步更新除盏。

2.4 數(shù)據(jù)節(jié)點(diǎn)DataNode

數(shù)據(jù)節(jié)點(diǎn)（DataNode）是分布式文件系統(tǒng)HDFS的工作節(jié)點(diǎn)叉橱，負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取，會(huì)根據(jù)客戶端或者名稱節(jié)點(diǎn)的調(diào)度來進(jìn)行數(shù)據(jù)的存儲(chǔ)和檢索者蠕，并且向名稱節(jié)點(diǎn)定期發(fā)送自己所存儲(chǔ)的塊列表窃祝。每個(gè)數(shù)據(jù)節(jié)點(diǎn)中的數(shù)據(jù)會(huì)保存在各自節(jié)點(diǎn)的本地Linux文件系統(tǒng)中。下面圖是數(shù)據(jù)節(jié)點(diǎn)的存儲(chǔ)目錄：

image.png

• current目錄：保存著HDFS文件系統(tǒng)中的數(shù)據(jù)塊踱侣，這些數(shù)據(jù)塊是成功提交到HDFS的數(shù)據(jù)塊粪小。
• in_use.lock：表明目錄已經(jīng)被使用，停止數(shù)據(jù)節(jié)點(diǎn)抡句，該文件會(huì)消失探膊，通過in_use.lock文件，數(shù)據(jù)節(jié)點(diǎn)可以保證獨(dú)自占用該目錄待榔，防止兩個(gè)數(shù)據(jù)節(jié)點(diǎn)示例共享一個(gè)目錄逞壁，造成混亂。

2.5 第二名稱節(jié)點(diǎn)SecondaryNameNode

NameNode運(yùn)行期間EditLog不斷變大的問題锐锣？

在NameNode運(yùn)行期間腌闯，HDFS的所有更新操作都是直接寫到EditLog中，久而久之刺下，EditLog文件將變得很大。雖然這對(duì)名稱節(jié)點(diǎn)運(yùn)行時(shí)候是沒有什么明顯影響的稽荧，但是橘茉，當(dāng)名稱節(jié)點(diǎn)重啟的時(shí)候，名稱節(jié)點(diǎn)需要先將FsImage里面的所有內(nèi)容映像到內(nèi)存中姨丈，然后再一條一條地執(zhí)行EditLog中的記錄畅卓，當(dāng)EditLog文件非常大的時(shí)候，會(huì)導(dǎo)致名稱節(jié)點(diǎn)啟動(dòng)操作非常慢蟋恬，而在這段時(shí)間內(nèi)HDFS系統(tǒng)處于安全模式翁潘，一直無法對(duì)外提供寫操作，影響了用戶的使用歼争。

為了有效解決EditLog逐漸變大帶來的問題拜马，HDFS提供的解決方案是SecondaryNameNode第二名稱節(jié)點(diǎn)，并且具有兩個(gè)功能：

• 1沐绒、可以完成Editlog與FsImage的合并操作俩莽，減少Editlog文件大小，縮短名稱節(jié)點(diǎn)重啟時(shí)間乔遮；
• 2扮超、可以作為名稱節(jié)點(diǎn)的“檢查點(diǎn)”，保存名稱節(jié)點(diǎn)中的元數(shù)據(jù)信息。

SecondaryNameNode一般是單獨(dú)運(yùn)行在一臺(tái)機(jī)器上(Master)出刷。

SecondaryNameNode的工作情況：

• 1璧疗、SecondaryNameNode會(huì)定期和NameNode通信，請(qǐng)求其停止使用EditLog文件馁龟，暫時(shí)將新的寫操作寫到一個(gè)新的文件edit.new上來崩侠，這個(gè)操作是瞬間完成，上層寫日志的函數(shù)完全感覺不到差別屁柏；
• 2啦膜、SecondaryNameNode通過HTTP GET方式從NameNode上獲取到FsImage和EditLog文件，并下載到本地的相應(yīng)目錄下淌喻；
• 3僧家、SecondaryNameNode將下載下來的FsImage載入到內(nèi)存，然后一條一條地執(zhí)行EditLog文件中的各項(xiàng)更新操作裸删，使得內(nèi)存中的FsImage保持最新八拱；這個(gè)過程就是EditLog和FsImage文件合并；
• 4涯塔、SecondaryNameNode執(zhí)行完（3）操作之后肌稻，會(huì)通過post方式將新的FsImage文件發(fā)送到NameNode節(jié)點(diǎn)上；
• 5匕荸、NameNode將從SecondaryNameNode接收到的新的FsImage替換舊的FsImage文件爹谭，同時(shí)將edit.new替換EditLog文件，通過這個(gè)過程EditLog就變小了榛搔。

FBFC5B5AE32A287428C9CF63F8BC9A8E.jpg

3.HDFS體系結(jié)構(gòu)

HDFS采用了主從（Master/Slave）結(jié)構(gòu)模型诺凡，一個(gè)HDFS集群包括一個(gè)名稱節(jié)點(diǎn)和若干個(gè)數(shù)據(jù)節(jié)點(diǎn)。名稱節(jié)點(diǎn)作為中心服務(wù)器践惑，負(fù)責(zé)管理文件系統(tǒng)的命名空間及客戶端對(duì)文件的訪問腹泌。集群中的數(shù)據(jù)節(jié)點(diǎn)一般是一個(gè)節(jié)點(diǎn)運(yùn)行一個(gè)數(shù)據(jù)節(jié)點(diǎn)進(jìn)程，負(fù)責(zé)處理文件系統(tǒng)客戶端的讀取請(qǐng)求尔觉，在名稱節(jié)點(diǎn)的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建凉袱、刪除和復(fù)制等操作。每個(gè)數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)實(shí)際上保存在本地Linux文件系統(tǒng)中的侦铜。每個(gè)數(shù)據(jù)節(jié)點(diǎn)會(huì)周期性向名稱節(jié)點(diǎn)發(fā)送“心跳”信息专甩，報(bào)告自己的狀態(tài)，沒有按時(shí)發(fā)送心跳信息的數(shù)據(jù)節(jié)點(diǎn)會(huì)被標(biāo)記為“宕機(jī)”钉稍，不會(huì)再給它分配任何IO請(qǐng)求配深。

image.png

HDFS是一個(gè)部署在集群上的分布式文件系統(tǒng)，因此嫁盲，很多數(shù)據(jù)需要通過網(wǎng)絡(luò)進(jìn)行傳輸篓叶。所有的HDFS通信協(xié)議都是構(gòu)建在TCP/IP協(xié)議基礎(chǔ)之上的烈掠。

• 客戶端通過一個(gè)可配置的端口向名稱節(jié)點(diǎn)主動(dòng)發(fā)起TCP連接，并使用客戶端協(xié)議與名稱節(jié)點(diǎn)進(jìn)行交互缸托。
• 名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)之間則使用數(shù)據(jù)節(jié)點(diǎn)協(xié)議進(jìn)行交互左敌。
• 客戶端與數(shù)據(jù)節(jié)點(diǎn)的交互是通過RPC（Remote Procedure Call）來實(shí)現(xiàn)的。在設(shè)計(jì)上俐镐，名稱節(jié)點(diǎn)不會(huì)主動(dòng)發(fā)起RPC矫限，而是響應(yīng)來自客戶端和數(shù)據(jù)節(jié)點(diǎn)的RPC請(qǐng)求。

4. HDFS存儲(chǔ)原理

4.1 冗余數(shù)據(jù)保存

作為一個(gè)分布式文件系統(tǒng)佩抹，為了保證系統(tǒng)的容錯(cuò)性和可用性叼风，HDFS采用了多副本方式對(duì)數(shù)據(jù)進(jìn)行冗余存儲(chǔ)，通常一個(gè)數(shù)據(jù)塊的多個(gè)副本會(huì)被分布到不同的數(shù)據(jù)節(jié)點(diǎn)上棍苹。這種多副本方式具有以下幾個(gè)優(yōu)點(diǎn)：

• 1无宿、加快數(shù)據(jù)傳輸速度
• 2、容易檢查數(shù)據(jù)錯(cuò)誤
• 3枢里、保證數(shù)據(jù)可靠性

例如孽鸡，數(shù)據(jù)塊1被分別存放到數(shù)據(jù)節(jié)點(diǎn)A和C，數(shù)據(jù)塊2被存放在數(shù)據(jù)節(jié)點(diǎn)A和B上栏豺。

4B9FF6C0B0332097AFB9FD341D7134E4.jpg

4.2 數(shù)據(jù)存取策略

4.2.1 數(shù)據(jù)存放

為了提高數(shù)據(jù)的可靠性與系統(tǒng)的可用性彬碱，以及充分利用網(wǎng)絡(luò)帶寬，HDFS采用了以機(jī)架（RACK）為基礎(chǔ)的數(shù)據(jù)存放策略奥洼。HDFS默認(rèn)每個(gè)數(shù)據(jù)節(jié)點(diǎn)都是在不用的機(jī)架上巷疼，這種方法會(huì)存在一個(gè)缺點(diǎn)：

• 在寫入數(shù)據(jù)的時(shí)候不能充分利用同一個(gè)機(jī)架內(nèi)部機(jī)器之間的帶寬。（同一個(gè)機(jī)架中的不同機(jī)器之間的通信要比不同機(jī)架之間機(jī)器的通信帶寬大）

但是和這種缺點(diǎn)相比灵奖，也有很多顯著的優(yōu)點(diǎn)：

• 1嚼沿、可以獲得很高的數(shù)據(jù)可靠性，即使一個(gè)機(jī)架發(fā)生故障桑寨，位于其他機(jī)架上的數(shù)據(jù)副本仍然是可以用的伏尼；
• 2忿檩、在讀取數(shù)據(jù)的時(shí)候尉尾，可以在多個(gè)機(jī)架上并行讀取數(shù)據(jù)，大大提高了數(shù)據(jù)讀取速度燥透；
• 3沙咏、可以更容易地實(shí)現(xiàn)系統(tǒng)內(nèi)部負(fù)載均衡和錯(cuò)誤處理。

問題：什么叫做機(jī)架（RACK）班套？

image.png

HDFS默認(rèn)的冗余復(fù)制因子是3肢藐，每個(gè)文件塊會(huì)被同時(shí)保存到3個(gè)地方，其中有兩份副本放在同一個(gè)機(jī)架的不同機(jī)器上面吱韭，第三個(gè)副本放在不同機(jī)架的機(jī)器上面吆豹，這樣既可以保證機(jī)架發(fā)生異常時(shí)的數(shù)據(jù)恢復(fù)鱼的，也可以提高讀寫性能。一般而言痘煤，HDFS副本的放置策略如下圖：

A76C45E3F15C56B2E9419535279DB65B.jpg

4.2.2 數(shù)據(jù)讀取

HDFS提供了一個(gè)API可以確定一個(gè)數(shù)據(jù)節(jié)點(diǎn)所屬的機(jī)架ID凑阶，客戶端也可以調(diào)用API獲取自己所屬的機(jī)架ID。當(dāng)客戶端讀取數(shù)據(jù)時(shí)衷快，從名稱節(jié)點(diǎn)獲得數(shù)據(jù)塊不同副本的存放位置列表宙橱，列表中包含了副本所在的數(shù)據(jù)節(jié)點(diǎn)，可以調(diào)用API來確定客戶端和這些數(shù)據(jù)節(jié)點(diǎn)所屬的機(jī)架ID蘸拔，當(dāng)發(fā)現(xiàn)某個(gè)數(shù)據(jù)塊副本對(duì)應(yīng)的機(jī)架ID和客戶端對(duì)應(yīng)的機(jī)架ID相同時(shí)师郑，就優(yōu)先選擇該副本讀取數(shù)據(jù)，如果沒有發(fā)現(xiàn)调窍，就隨機(jī)選擇一個(gè)副本讀取數(shù)據(jù)宝冕。

4.2.3 數(shù)據(jù)復(fù)制

HDFS的數(shù)據(jù)復(fù)制采用流水線復(fù)制的策略，大大提高了數(shù)據(jù)復(fù)制過程的效率陨晶。

• 1猬仁、當(dāng)客戶端要往HDFS中寫入一個(gè)文件時(shí)，這個(gè)文件會(huì)首先被寫入本地先誉，并被切分若干個(gè)塊湿刽，每個(gè)塊的大小是由HDFS的設(shè)定值來決定的。
• 2褐耳、每個(gè)塊都向HDFS集群中的名稱節(jié)點(diǎn)發(fā)起寫請(qǐng)求诈闺，名稱節(jié)點(diǎn)會(huì)根據(jù)系統(tǒng)中各個(gè)數(shù)據(jù)節(jié)點(diǎn)的使用情況，選擇一個(gè)數(shù)據(jù)節(jié)點(diǎn)列表返回給客戶端铃芦。
• 3雅镊、然后客戶端就把數(shù)據(jù)首先寫入列表中的第一個(gè)數(shù)據(jù)節(jié)點(diǎn)，同時(shí)把列表傳給第一個(gè)數(shù)據(jù)節(jié)點(diǎn)刃滓。當(dāng)?shù)谝粋€(gè)數(shù)據(jù)節(jié)點(diǎn)接收到4KB的數(shù)據(jù)的時(shí)候仁烹，寫入本地，并且向列表中的第二個(gè)數(shù)據(jù)節(jié)點(diǎn)發(fā)起連接請(qǐng)求咧虎；
• 4卓缰、當(dāng)?shù)诙€(gè)數(shù)據(jù)節(jié)點(diǎn)接收到4KB數(shù)據(jù)的時(shí)候，寫入本地砰诵，并且向列表中的第三個(gè)數(shù)據(jù)節(jié)點(diǎn)發(fā)起連接請(qǐng)求征唬；
• 5、依次類推茁彭，列表中的多個(gè)數(shù)據(jù)節(jié)點(diǎn)形成一條數(shù)據(jù)復(fù)制的流水線总寒。最后，當(dāng)文件寫完的時(shí)候理肺，數(shù)據(jù)復(fù)制也同時(shí)完成摄闸。

4.3 數(shù)據(jù)錯(cuò)誤與恢復(fù)

4.3.1 名稱節(jié)點(diǎn)出錯(cuò)

名稱節(jié)點(diǎn)保存了所有的元數(shù)據(jù)信息善镰，其中，最核心的兩個(gè)數(shù)據(jù)結(jié)構(gòu)是FSImage和Editlog年枕，如果這兩個(gè)文件發(fā)生損壞媳禁，那么整個(gè)HDFS實(shí)例將失效。因此画切，HDFS設(shè)置了備份機(jī)制竣稽，把這些核心文件同步復(fù)制到備份服務(wù)器SecondaryNameNode上。當(dāng)名稱節(jié)點(diǎn)出錯(cuò)時(shí)霍弹，就可以根據(jù)備份服務(wù)器SecondaryNameNode中FSImage和Editlog數(shù)據(jù)進(jìn)行恢復(fù)毫别。

4.3.2 數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)

每個(gè)數(shù)據(jù)節(jié)點(diǎn)定期會(huì)向名稱節(jié)點(diǎn)發(fā)送“心跳”信息，向名稱節(jié)點(diǎn)報(bào)告自己的狀態(tài)典格。當(dāng)數(shù)據(jù)節(jié)點(diǎn)發(fā)生故障岛宦，或者網(wǎng)絡(luò)發(fā)生斷網(wǎng)時(shí)，名稱節(jié)點(diǎn)就無法收到來自一些數(shù)據(jù)節(jié)點(diǎn)的心跳信息耍缴，這時(shí)砾肺，這些數(shù)據(jù)節(jié)點(diǎn)就會(huì)被標(biāo)記為“宕機(jī)”，節(jié)點(diǎn)上面的所有書都會(huì)被標(biāo)記為“不可讀”防嗡，名稱節(jié)點(diǎn)不會(huì)給它們發(fā)送任何IO請(qǐng)求变汪。

4.3.3 數(shù)據(jù)出錯(cuò)

網(wǎng)絡(luò)傳輸和磁盤錯(cuò)誤等因素會(huì)造成數(shù)據(jù)錯(cuò)誤∫铣茫客戶端在讀取數(shù)據(jù)后裙盾，會(huì)采用MD5和SHA1對(duì)數(shù)據(jù)塊進(jìn)行校驗(yàn)，以確定讀取到正確的數(shù)據(jù)他嫡。

• 1番官、在文件被創(chuàng)建時(shí)，客戶端就會(huì)對(duì)每個(gè)文件塊進(jìn)行信息摘錄钢属，并把這些信息寫入同一個(gè)路徑的隱藏文件里面徘熔；
• 2、當(dāng)客戶端讀取文件的時(shí)候淆党，會(huì)先讀取該信息文件酷师，然后利用該信息文件對(duì)每個(gè)讀取的數(shù)據(jù)塊進(jìn)行校驗(yàn)；
• 3宁否、如果校驗(yàn)出錯(cuò)窒升，客戶端就會(huì)請(qǐng)求到另外一個(gè)數(shù)據(jù)節(jié)點(diǎn)讀取該文件塊缀遍，并且向名稱節(jié)點(diǎn)報(bào)告這個(gè)文件塊有錯(cuò)誤慕匠，名稱節(jié)點(diǎn)會(huì)定期檢查并且重新復(fù)制這個(gè)塊。

5. HDFS數(shù)據(jù)讀寫過程

5.1 讀取

當(dāng)一個(gè)客戶端應(yīng)用想要讀取一個(gè)文件時(shí)域醇，它首先訪問NameNode台谊。NameNode以組成文件的所有文件塊的位置來響應(yīng)蓉媳。塊的位置標(biāo)識(shí)了持有對(duì)應(yīng)文件塊數(shù)據(jù)的DataNode。客戶端緊接著直接向DataNode發(fā)送讀請(qǐng)求锅铅，以獲取每個(gè)文件塊酪呻。NameNode不參與從DataNode到客戶端的實(shí)際數(shù)據(jù)傳輸過程。

78A11F34B486747FEDD3D64F5B4A4B5C.jpg

5.2 寫入

當(dāng)客戶端應(yīng)用想要寫數(shù)據(jù)到HDFS文件時(shí)盐须，它首先訪問NameNode并要求它在HDFS命名空間中創(chuàng)建一個(gè)新的條目玩荠。NameNode會(huì)檢查同名文件是否已存在以及客戶端是否有權(quán)限來創(chuàng)建新文件。

• 接下來贼邓，客戶端應(yīng)用請(qǐng)求NameNode為文件的第一個(gè)塊選擇DataNode阶冈。它會(huì)在所持有塊的復(fù)制節(jié)點(diǎn)之間創(chuàng)建一個(gè)管道，并把數(shù)據(jù)塊發(fā)送到管道中第一個(gè)DataNode塑径。
• 第一個(gè)DataNode在本地存儲(chǔ)數(shù)據(jù)塊女坑，然后把它轉(zhuǎn)發(fā)給第二個(gè)DataNode。第二個(gè)DataNode也在本地存儲(chǔ)相應(yīng)數(shù)據(jù)塊统舀，并把它裝發(fā)給第三個(gè)DataNode匆骗。
• 在所有委派的DataNode上都存儲(chǔ)第一個(gè)文件塊之后，客戶端請(qǐng)求NameNode為第二個(gè)塊分配DataNode誉简。這個(gè)過程持續(xù)進(jìn)行碉就，直到所有文件塊都已經(jīng)在DataNode上存儲(chǔ)。最后闷串，客戶端告知NameNode文件寫操作已完成铝噩。

8DCE235FD0174635257CC244595D3AAA.jpg

參考資料

http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html

http://dblab.xmu.edu.cn/post/bigdataroadmap/