概述

開始之前先看看其基本屬性，HDFS（Hadoop Distributed File System）是GFS的開源實(shí)現(xiàn)。

特點(diǎn)如下：

• 能夠運(yùn)行在廉價(jià)機(jī)器上，硬件出錯(cuò)常態(tài)，需要具備高容錯(cuò)性
• 流式數(shù)據(jù)訪問，而不是隨機(jī)讀寫
• 面向大規(guī)模數(shù)據(jù)集，能夠進(jìn)行批處理、能夠橫向擴(kuò)展
• 簡(jiǎn)單一致性模型，假定文件是一次寫入、多次讀取

缺點(diǎn)：

• 不支持低延遲數(shù)據(jù)訪問
• 不適合大量小文件存儲(chǔ)（因?yàn)槊織l元數(shù)據(jù)占用空間是一定的）
• 不支持并發(fā)寫入，一個(gè)文件只能有一個(gè)寫入者
• 不支持文件隨機(jī)修改，僅支持追加寫入

HDFS中的block、packet、chunk

很多博文介紹HDFS讀寫流程上來就直接從文件分塊開始，其實(shí)，要把讀寫過程細(xì)節(jié)搞明白前，你必須知道block、packet與chunk。下面分別講述。

1. block
   這個(gè)大家應(yīng)該知道，文件上傳前需要分塊，這個(gè)塊就是block，一般為128MB，當(dāng)然你可以去改，不顧不推薦。因?yàn)?strong>塊太?。簩ぶ窌r(shí)間占比過高。塊太大：Map任務(wù)數(shù)太少，作業(yè)執(zhí)行速度變慢。它是最大的一個(gè)單位。

2. packet
   packet是第二大的單位，它是client端向DataNode，或DataNode的PipLine之間傳數(shù)據(jù)的基本單位，默認(rèn)64KB。

3. chunk
   chunk是最小的單位，它是client向DataNode，或DataNode的PipLine之間進(jìn)行數(shù)據(jù)校驗(yàn)的基本單位，默認(rèn)512Byte，因?yàn)橛米餍ｒ?yàn)，故每個(gè)chunk需要帶有4Byte的校驗(yàn)位。所以實(shí)際每個(gè)chunk寫入packet的大小為516Byte。由此可見真實(shí)數(shù)據(jù)與校驗(yàn)值數(shù)據(jù)的比值約為128 : 1。（即64*1024 / 512）

例如，在client端向DataNode傳數(shù)據(jù)的時(shí)候，HDFSOutputStream會(huì)有一個(gè)chunk buff，寫滿一個(gè)chunk后，會(huì)計(jì)算校驗(yàn)和并寫入當(dāng)前的chunk。之后再把帶有校驗(yàn)和的chunk寫入packet，當(dāng)一個(gè)packet寫滿后，packet會(huì)進(jìn)入dataQueue隊(duì)列，其他的DataNode就是從這個(gè)dataQueue獲取client端上傳的數(shù)據(jù)并存儲(chǔ)的。同時(shí)一個(gè)DataNode成功存儲(chǔ)一個(gè)packet后之后會(huì)返回一個(gè)ack packet，放入ack Queue中。

HDFS寫流程

HDFS讀流程

1. 客戶端向NameNode發(fā)出寫文件請(qǐng)求。
2. 檢查是否已存在文件、檢查權(quán)限。若通過檢查，直接先將操作寫入EditLog，并返回輸出流對(duì)象。
   （注：WAL，write ahead log，先寫Log，再寫內(nèi)存，因?yàn)镋ditLog記錄的是最新的HDFS客戶端執(zhí)行所有的寫操作。如果后續(xù)真實(shí)寫操作失敗了，由于在真實(shí)寫操作之前，操作就被寫入EditLog中了，故EditLog中仍會(huì)有記錄，我們不用擔(dān)心后續(xù)client讀不到相應(yīng)的數(shù)據(jù)塊，因?yàn)樵诘?步中DataNode收到塊后會(huì)有一返回確認(rèn)信息，若沒寫成功，發(fā)送端沒收到確認(rèn)信息，會(huì)一直重試，直到成功）
3. client端按128MB的塊切分文件。
4. client將NameNode返回的分配的可寫的DataNode列表和Data數(shù)據(jù)一同發(fā)送給最近的第一個(gè)DataNode節(jié)點(diǎn)，此后client端和NameNode分配的多個(gè)DataNode構(gòu)成pipeline管道，client端向輸出流對(duì)象中寫數(shù)據(jù)。client每向第一個(gè)DataNode寫入一個(gè)packet，這個(gè)packet便會(huì)直接在pipeline里傳給第二個(gè)、第三個(gè)…DataNode。
   （注：并不是寫好一個(gè)塊或一整個(gè)文件后才向后分發(fā)）
5. 每個(gè)DataNode寫完一個(gè)塊后，會(huì)返回確認(rèn)信息。
   （注：并不是每寫完一個(gè)packet后就返回確認(rèn)信息，個(gè)人覺得因?yàn)閜acket中的每個(gè)chunk都攜帶校驗(yàn)信息，沒必要每寫一個(gè)就匯報(bào)一下，這樣效率太慢。正確的做法是寫完一個(gè)block塊后，對(duì)校驗(yàn)信息進(jìn)行匯總分析，就能得出是否有塊寫錯(cuò)的情況發(fā)生）
6. 寫完數(shù)據(jù)，關(guān)閉輸輸出流。
7. 發(fā)送完成信號(hào)給NameNode。
   （注：發(fā)送完成信號(hào)的時(shí)機(jī)取決于集群是強(qiáng)一致性還是最終一致性，強(qiáng)一致性則需要所有DataNode寫完后才向NameNode匯報(bào)。最終一致性則其中任意一個(gè)DataNode寫完后就能單獨(dú)向NameNode匯報(bào)，HDFS一般情況下都是強(qiáng)調(diào)強(qiáng)一致性）

HDFS讀流程

HDFS讀流程

1. client訪問NameNode，查詢?cè)獢?shù)據(jù)信息，獲得這個(gè)文件的數(shù)據(jù)塊位置列表，返回輸入流對(duì)象。
2. 就近挑選一臺(tái)datanode服務(wù)器，請(qǐng)求建立輸入流 。
3. DataNode向輸入流中中寫數(shù)據(jù)，以packet為單位來校驗(yàn)。
4. 關(guān)閉輸入流

讀寫過程，數(shù)據(jù)完整性如何保持？

通過校驗(yàn)和。因?yàn)槊總€(gè)chunk中都有一個(gè)校驗(yàn)位，一個(gè)個(gè)chunk構(gòu)成packet，一個(gè)個(gè)packet最終形成block，故可在block上求校驗(yàn)和。

HDFS 的client端即實(shí)現(xiàn)了對(duì) HDFS 文件內(nèi)容的校驗(yàn)和 (checksum) 檢查。當(dāng)客戶端創(chuàng)建一個(gè)新的HDFS文件時(shí)候，分塊后會(huì)計(jì)算這個(gè)文件每個(gè)數(shù)據(jù)塊的校驗(yàn)和，此校驗(yàn)和會(huì)以一個(gè)隱藏文件形式保存在同一個(gè) HDFS 命名空間下。當(dāng)client端從HDFS中讀取文件內(nèi)容后，它會(huì)檢查分塊時(shí)候計(jì)算出的校驗(yàn)和（隱藏文件里）和讀取到的文件塊中校驗(yàn)和是否匹配，如果不匹配，客戶端可以選擇從其他 Datanode 獲取該數(shù)據(jù)塊的副本。

HDFS中文件塊目錄結(jié)構(gòu)具體格式如下：

${dfs.datanode.data.dir}/
├── current
│ ├── BP-526805057-127.0.0.1-1411980876842
│ │ └── current
│ │ ├── VERSION
│ │ ├── finalized
│ │ │ ├── blk_1073741825
│ │ │ ├── blk_1073741825_1001.meta
│ │ │ ├── blk_1073741826
│ │ │ └── blk_1073741826_1002.meta
│ │ └── rbw
│ └── VERSION
└── in_use.lock

in_use.lock表示DataNode正在對(duì)文件夾進(jìn)行操作
rbw是“replica being written”的意思，該目錄用于存儲(chǔ)用戶當(dāng)前正在寫入的數(shù)據(jù)。
Block元數(shù)據(jù)文件（*.meta）由一個(gè)包含版本、類型信息的頭文件和一系列校驗(yàn)值組成。校驗(yàn)和也正是存在其中。