公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。創(chuàng)新互聯(lián)公司推出澄城免費(fèi)做網(wǎng)站回饋大家。

學(xué)習(xí)Hadoop，兩個(gè)東西肯定是繞不過(guò)，MapReduce和HDFS，上一篇博客介紹了MapReduce的處理流程，這一篇博客就來(lái)學(xué)習(xí)一下HDFS。

　HDFS是一個(gè)分布式的文件系統(tǒng)，就是將多臺(tái)機(jī)器的存儲(chǔ)當(dāng)做一個(gè)文件系統(tǒng)來(lái)使用，因?yàn)樵诖髷?shù)據(jù)的情景下，單機(jī)的存儲(chǔ)量已經(jīng)完全不夠用了，所以采取分布式的方法來(lái)擴(kuò)容，解決本地文件系統(tǒng)在文件大小、文件數(shù)量、打開(kāi)文件數(shù)等的限制問(wèn)題。我們首先來(lái)看一下HDFS的架構(gòu)

HDFS架構(gòu)

從上圖可以看到，HDFS的主要組成部分為Namenode、Datanodes、Client，還有幾個(gè)名詞：Block、Metadata、Replication 、Rack，它們分別是什么意思呢？

　對(duì)于分布式的文件系統(tǒng)，數(shù)據(jù)存儲(chǔ)在很多的機(jī)器上，而Datanode代表的就是這些機(jī)器，是數(shù)據(jù)實(shí)際存儲(chǔ)的地方，數(shù)據(jù)存好之后，我們需要知道它們具體存在哪一個(gè)Datanode上，這就是Namenode做的工作，它記錄著元數(shù)據(jù)信息（也就是Metadata，其主要內(nèi)容就是哪個(gè)數(shù)據(jù)塊存在哪個(gè)Datanode上的哪個(gè)目錄下，這也是為什么HDFS不適合存大量小文件的原因，因?yàn)?為了響應(yīng)速度，Namenode 把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，所以文件系統(tǒng)所能容納的文件數(shù)目是由 Namenode 的內(nèi)存大小來(lái)決定。一般來(lái)說(shuō)，每一個(gè)文件、文件夾和 Block 需要占據(jù) 150 字節(jié)左右的空間，如果存100 萬(wàn)個(gè)小文件，至少需要 300MB內(nèi)存，但這么多小文件實(shí)際卻沒(méi)有存太多數(shù)據(jù)，這樣就太浪費(fèi)內(nèi)存了），有了元數(shù)據(jù)信息，我們就能通過(guò)Namenode來(lái)查到數(shù)據(jù)塊的具體位置了，而與Namenode打交道的工具就是Client，Client給我們用戶提供存取數(shù)據(jù)的接口，我們可以通過(guò)Client進(jìn)行數(shù)據(jù)存取的工作。

　而剩下來(lái)的幾個(gè)名詞，Block表示的是數(shù)據(jù)塊，因?yàn)榇嬖贖DFS上的一般都是很大的文件，我們需要將它拆成很多個(gè)數(shù)據(jù)塊進(jìn)行存儲(chǔ)；Replication是副本的意思，這是為了數(shù)據(jù)的可靠性，如果某個(gè)數(shù)據(jù)塊丟失了，還能通過(guò)它的副本找回來(lái)，HDFS默認(rèn)一個(gè)數(shù)據(jù)塊存儲(chǔ)三份；Rack表示的是機(jī)架的意思，可以理解為存放多個(gè)Datanode的地方。

       總結(jié)一下就是，數(shù)據(jù)存在Datanode上，并且有副本，而Namenode知道數(shù)據(jù)及其副本具體存在哪個(gè)Datanode上，我們想要找數(shù)據(jù)或者寫數(shù)據(jù)的時(shí)候就通過(guò)Client來(lái)和Namenode聯(lián)系，由它來(lái)告訴我們應(yīng)該把數(shù)據(jù)存在哪里或者到哪里去取。

HDFS讀寫流程

看完了HDFS的架構(gòu)，我們來(lái)看一下HDFS具體是怎么存取數(shù)據(jù)的。首先是寫流程：

注：以下步驟并不嚴(yán)格對(duì)應(yīng)如中的發(fā)生順序

1）使用HDFS提供的客戶端開(kāi)發(fā)庫(kù)，向遠(yuǎn)程的Namenode發(fā)起請(qǐng)求；

　2）Namenode會(huì)檢查要?jiǎng)?chuàng)建的文件是否已經(jīng)存在，創(chuàng)建者是否有權(quán)限進(jìn)行操作，成功則會(huì)為文件創(chuàng)建一個(gè)記錄，否則會(huì)讓客戶端拋出異常；

　3）當(dāng)客戶端開(kāi)始寫入文件的時(shí)候，會(huì)將文件切分成多個(gè)packets（數(shù)據(jù)包），并在內(nèi)部以“data queue”（數(shù)據(jù)隊(duì)列）的形式管理這些packets，并向Namenode申請(qǐng)新的blocks，獲取用來(lái)存儲(chǔ)replication的合適的datanodes列表，列表的大小根據(jù)在Namenode中對(duì)replication的設(shè)置而定。

　4）開(kāi)始以pipeline（管道）的形式將packet寫入所有的replication中。先將packet以流的方式寫入第一個(gè)datanode，該datanode把該packet存儲(chǔ)之后，再將其傳遞給在此pipeline中的下一個(gè)datanode，直到最后一個(gè)datanode，這種寫數(shù)據(jù)的方式呈流水線的形式。

　5）最后一個(gè)datanode成功存儲(chǔ)之后會(huì)返回一個(gè)ack packet（確認(rèn)包），在pipeline里傳遞至客戶端，在客戶端內(nèi)部維護(hù)著“ack queue”(確認(rèn)隊(duì)列)，成功收到datanode返回的ackpacket后會(huì)從“ack queue”移除相應(yīng)的packet，代表該packet寫入成功。

　6）如果傳輸過(guò)程中，有某個(gè)datanode出現(xiàn)了故障，那么當(dāng)前的pipeline會(huì)被關(guān)閉，出現(xiàn)故障的datanode會(huì)從當(dāng)前的pipeline中移除，剩余的block會(huì)在剩下的datanode中繼續(xù)以pipeline的形式傳輸，同時(shí)Namenode會(huì)分配一個(gè)新的datanode，保持replication設(shè)定的數(shù)量。

　接下來(lái)是讀流程：

注：以下步驟并不嚴(yán)格對(duì)應(yīng)如中的發(fā)生順序

1）使用HDFS提供的客戶端，向遠(yuǎn)程的Namenode發(fā)起請(qǐng)求；

　2）Namenode會(huì)視情況返回文件的部分或者全部block列表，對(duì)于每個(gè)block，Namenode都會(huì)返回有該block拷貝的Datanode地址；

　3）客戶端會(huì)選取離客戶端最接近的Datanode來(lái)讀取block；

　4）讀取完當(dāng)前block的數(shù)據(jù)后，關(guān)閉與當(dāng)前的Datanode連接，并為讀取下一個(gè)block尋找最佳的Datanode；

　5）當(dāng)讀完列表的block后，且文件讀取還沒(méi)有結(jié)束，客戶端會(huì)繼續(xù)向Namenode獲取下一批的block列表。

　6）讀取完一個(gè)block都會(huì)進(jìn)行checksum（校驗(yàn)和）驗(yàn)證，看文件內(nèi)容是否出錯(cuò)；另外，如果讀取Datanode時(shí)出現(xiàn)錯(cuò)誤，客戶端會(huì)通知Namenode，然后再?gòu)南乱粋€(gè)擁有該block拷  貝的Datanode繼續(xù)讀。

以上便是HDFS的讀寫流程，了解這些之后，我們思考幾個(gè)問(wèn)題，對(duì)于分布式的文件系統(tǒng)，我們?cè)趺幢ＷC數(shù)據(jù)的一致性？就是說(shuō)如果有多個(gè)客戶端向同一個(gè)文件寫數(shù)據(jù)，那么我們?cè)撛趺刺幚?？另外，我們看到Namenode在HDFS中非常重要，它保存著關(guān)鍵的元數(shù)據(jù)信息，但是從架構(gòu)圖中看到，Namenode只有一個(gè)，如果它掛掉了，我們?cè)趺幢ＷC系統(tǒng)能夠繼續(xù)工作？

分布式領(lǐng)域CAP理論

CAP理論是分布式中一個(gè)經(jīng)典的理論，具體內(nèi)容如下：

　Consistency(一致性)：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。

　Availability(可用性)：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請(qǐng)求。

　Partition tolerance(分區(qū)容錯(cuò)性)：系統(tǒng)應(yīng)該能持續(xù)提供服務(wù)，即使系統(tǒng)內(nèi)部有消息丟失（分區(qū)）。

　一致性和可用性比較好理解，主要解釋一下分區(qū)容錯(cuò)性，它的意思就是說(shuō)因?yàn)榫W(wǎng)絡(luò)的原因，可能是網(wǎng)絡(luò)斷開(kāi)了，也可能是某些機(jī)器宕機(jī)了，網(wǎng)絡(luò)延時(shí)等導(dǎo)致數(shù)據(jù)交換無(wú)法在期望的時(shí)間內(nèi)完成。因?yàn)榫W(wǎng)絡(luò)問(wèn)題是避免不了的，所以我們總是需要解決這個(gè)問(wèn)題，也就是得保證分區(qū)容錯(cuò)性。為了保證數(shù)據(jù)的可靠性，HDFS采取了副本的策略。

對(duì)于一致性，HDFS提供的是簡(jiǎn)單的一致性模型，為一次寫入，多次讀取一個(gè)文件的訪問(wèn)模式，支持追加(append)操作，但無(wú)法更改已寫入數(shù)據(jù)。HDFS中的文件都是一次性寫入的，并且嚴(yán)格要求在任何時(shí)候只能有一個(gè)寫入者。什么時(shí)候一個(gè)文件算寫入成功呢？對(duì)于HDFS來(lái)說(shuō)，有兩個(gè)參數(shù)：dfs.namenode.replication.min (默認(rèn)為1) 和dfs.replication (默認(rèn)為 3)，一個(gè)文件的副本數(shù)大于等于參數(shù)dfs.namenode.replication.min 時(shí)就被標(biāo)記為寫成功，但是副本數(shù)要是小于參數(shù)dfs.replication，此文件還會(huì)標(biāo)記為“unreplication”，會(huì)繼續(xù)往其它Datanode里寫副本，所以如果我們想要直到所有要保存數(shù)據(jù)的DataNodes確認(rèn)它們都有文件的副本時(shí)，數(shù)據(jù)才被認(rèn)為寫入完成，我們可以將dfs.namenode.replication.min設(shè)置與dfs.replication相等。因此，數(shù)據(jù)一致性是在寫的階段完成的，一個(gè)客戶端無(wú)論選擇從哪個(gè)DataNode讀取，都將得到相同的數(shù)據(jù)。

　對(duì)于可用性，HDFS2.0對(duì)Namenode提供了高可用性（High Availability），這里提一下，Secondary NameNode不是HA，Namenode因?yàn)樾枰烂總€(gè)數(shù)據(jù)塊具體在哪，所以為每個(gè)數(shù)據(jù)塊命名，并保存這個(gè)命名文件（fsp_w_picpath文件），只要有操作文件的行為，就將這些行為記錄在編輯日志中（edits文件），為了響應(yīng)的速度，這兩個(gè)文件都是放在內(nèi)存中的，但是隨著文件操作額進(jìn)行，edits文件會(huì)越來(lái)越大，所以Secondary NameNode會(huì)階段性的合并edits和fsp_w_picpath文件，以縮短集群?jiǎn)?dòng)的時(shí)間。當(dāng)NameNode失效的時(shí)候，Secondary NameNode并無(wú)法立刻提供服務(wù)，Secondary NameNode甚至無(wú)法保證數(shù)據(jù)完整性，如果NameNode數(shù)據(jù)丟失的話，在上一次合并后的文件系統(tǒng)的改動(dòng)會(huì)丟失。Secondary NameNode合并edits和fsp_w_picpath文件的流程具體如下：

目前HDFS2中提供了兩種HA方案，一種是基于NFS（Network File System）共享存儲(chǔ)的方案，一種基于Paxos算法的方案Quorum Journal Manager（QJM），下面是基于NFS共享存儲(chǔ)的方案

通過(guò)上圖可知，Namenode的高可用性是通過(guò)為其設(shè)置一個(gè)Standby Namenode來(lái)實(shí)現(xiàn)的，要是目前的Namenode掛掉了，就啟用備用的Namenode。而兩個(gè)Namenode之間通過(guò)共享的存儲(chǔ)來(lái)同步信息，以下是一些要點(diǎn)：

  利用共享存儲(chǔ)來(lái)在兩個(gè)NameNode間同步edits信息。

　 DataNode同時(shí)向兩個(gè)NameNode匯報(bào)塊信息。這是讓Standby NameNode保持集群最新?tīng)顟B(tài)的必需步驟。

　 用于監(jiān)視和控制NameNode進(jìn)程的FailoverController進(jìn)程（一旦工作的Namenode掛了，就啟用切換程序）。

　 隔離(Fencing)，防止腦裂，就是保證在任何時(shí)候只有一個(gè)主NameNode，包括三個(gè)方面：

      　　 共享存儲(chǔ)fencing，確保只有一個(gè)NameNode可以寫入edits。

       　　 客戶端fencing，確保只有一個(gè)NameNode可以響應(yīng)客戶端的請(qǐng)求。

              DataNode fencing，確保只有一個(gè)NameNode可以向DataNode下發(fā)命令，譬如刪除塊，復(fù)制塊，等等。

　另一種是QJM方案：

簡(jiǎn)單來(lái)說(shuō)，就是為了讓Standby Node與Active Node保持同步，這兩個(gè)Node都與一組稱為JNS(Journal Nodes)的互相獨(dú)立的進(jìn)程保持通信。它的基本原理就是用2N+1臺(tái)JournalNode存儲(chǔ)edits文件，每次寫數(shù)據(jù)操作有大多數(shù)（大于等于N+1）返回成功時(shí)即認(rèn)為該次寫成功。因?yàn)镼JM方案是基于Paxos算法的，而Paxos算法不是兩三句就能說(shuō)清楚的，有興趣的可以看這個(gè)知乎專欄：Paxos算法或者參考官方文檔。