前言
HDFS是Hadoop體系的基礎(chǔ)媒抠，不知道各位怎么對(duì)待HDFS。反正我更多的關(guān)注一些應(yīng)用層的東西咏花，對(duì)于HDFS多有忽視趴生。
但是每次面試的時(shí)候都要重新去背面經(jīng)，我覺(jué)得這樣的情況不太正常昏翰，因此耗時(shí)兩天半整理了HDFS的知識(shí)體系苍匆，力求知其然也要知其所以然。
文章中有不少個(gè)人思考棚菊，希望能讓各位更好的理解HDFS.
一浸踩、HDFS特性
高容錯(cuò)性：HDFS認(rèn)為硬件總是不可靠的锁蠕。
高吞吐量：HDFS為大量數(shù)據(jù)訪問(wèn)的應(yīng)用提供了高吞吐量支持碴倾。
大文件存儲(chǔ)：HDFS支持存儲(chǔ)TB甚至PB級(jí)別的數(shù)據(jù)。
高度關(guān)注這個(gè)容錯(cuò)性金拒，這個(gè)風(fēng)格灌輸HDFS設(shè)計(jì)的始終码邻。至于大文件存儲(chǔ)和高吞吐量折剃，那玩意兒現(xiàn)在是個(gè)框架都支持。我個(gè)人認(rèn)為高容錯(cuò)性是這個(gè)HDFS體系最強(qiáng)烈的風(fēng)格冒滩。
二微驶、HDFS架構(gòu)
HDFS架構(gòu)包含三個(gè)部分：NameNode浪谴，DataNode开睡，Client。他們職責(zé)分別如下：
NameNode：主節(jié)點(diǎn)苟耻，名稱節(jié)點(diǎn)篇恒，NameNode用于存儲(chǔ)、生成文件系統(tǒng)的元數(shù)據(jù)凶杖。運(yùn)行一個(gè)實(shí)例胁艰。
DataNode：從節(jié)點(diǎn)，數(shù)據(jù)節(jié)點(diǎn)，DataNode用于存儲(chǔ)實(shí)際的數(shù)據(jù)腾么，將自己管理的數(shù)據(jù)塊上報(bào)給NameNode 奈梳，運(yùn)行多個(gè)實(shí)例。
Client：支持業(yè)務(wù)訪問(wèn)HDFS解虱，從NameNode ,DataNode獲取數(shù)據(jù)返回給業(yè)務(wù)攘须。多個(gè)實(shí)例，和業(yè)務(wù)一起運(yùn)行殴泰。
在我個(gè)人的理解中：NameNode相當(dāng)于我們的桌面快捷方式于宙。DataNode則是電腦里面的存儲(chǔ)單元。Client則是操作系統(tǒng)悍汛。
三捞魁、基本定義
3.1元數(shù)據(jù)（Metadata）：
保存文件屬性的數(shù)據(jù)，如文件名离咐，文件長(zhǎng)度谱俭，文件所屬用戶組，文件存儲(chǔ)位置等宵蛀。
元數(shù)據(jù)類似于文件索引旺上，相當(dāng)于我們電腦上應(yīng)用的快捷方式。
元數(shù)據(jù)長(zhǎng)什么樣子糖埋？
元數(shù)據(jù)用來(lái)維護(hù)文件與數(shù)據(jù)塊之間映射關(guān)系的數(shù)據(jù)結(jié)構(gòu)宣吱，簡(jiǎn)單來(lái)說(shuō)它應(yīng)該是類似以下一個(gè)key-value形式的數(shù)據(jù)。
這個(gè)只是我理解的元數(shù)據(jù)的樣子瞳别，key為文件名.value為塊Blk征候，一個(gè)快有在多個(gè)數(shù)據(jù)節(jié)點(diǎn)DN有備份。
3.2數(shù)據(jù)塊（Block）：
存儲(chǔ)文件的最小單元祟敛，一般為64M或者128M疤坝。對(duì)存儲(chǔ)介質(zhì)劃分了固定的區(qū)域，使用時(shí)按這些區(qū)域分配使用馆铁。
數(shù)據(jù)塊類似于Bit,或者字節(jié)跑揉，數(shù)據(jù)塊存儲(chǔ)的是實(shí)際的文件數(shù)據(jù)。
好的埠巨，問(wèn)題來(lái)了：
3.2.1為什么一定要用數(shù)據(jù)塊為存儲(chǔ)單位历谍？
在大數(shù)據(jù)的處理場(chǎng)景，TB甚至PB級(jí)別的大文件是經(jīng)常能遇到的辣垒。假如我們要上傳這樣一個(gè)PB級(jí)的文件望侈，沒(méi)有任何一塊磁盤(pán)能夠存儲(chǔ)，這樣這個(gè)文件就沒(méi)法上傳了勋桶。
但如果我們使用塊的概念把文件分割成許多塊脱衙，這樣這個(gè)文件可以使用計(jì)算機(jī)集群中的任意計(jì)算機(jī)節(jié)點(diǎn)進(jìn)行存儲(chǔ)侥猬。
當(dāng)有文件上傳到HDFS上時(shí)，若文件大小大于塊的大小退唠，則該文件會(huì)被切分存儲(chǔ)為多個(gè)塊荤胁，多個(gè)塊可以存放在不同的DataNode上，整個(gè)過(guò)程中 HDFS系統(tǒng)會(huì)保證一個(gè)塊存儲(chǔ)在一個(gè)datanode上 寨蹋。但值得注意的是 如果某文件大小沒(méi)有到達(dá)塊的大小松蒜，該文件并不會(huì)占據(jù)整個(gè)塊空間已旧。即，多個(gè)文件可共用一個(gè)塊运褪。
3.2.2數(shù)據(jù)塊的其他優(yōu)勢(shì)
1. 數(shù)據(jù)存儲(chǔ)要考慮容災(zāi)備份惊楼，以塊為單位比較容易進(jìn)行備份，HDFS默認(rèn)每個(gè)塊備份3份檀咙，這樣如果這個(gè)塊上或這個(gè)節(jié)點(diǎn)壞掉璃诀，可以直接找其他節(jié)點(diǎn)上的備份塊。
非重點(diǎn)棕诵，僅了解：
一般來(lái)說(shuō)這三份分別是本身一份凿将，同機(jī)架下不同節(jié)點(diǎn)放一個(gè)副本，不同機(jī)架下放一個(gè)副本笛匙。這樣的備份策略主要是為了兼顧網(wǎng)絡(luò)傳輸開(kāi)銷和數(shù)據(jù)安全犀变。
1.如果本機(jī)數(shù)據(jù)損壞或者丟失，那么客戶端可以從同機(jī)架的相鄰節(jié)點(diǎn)獲取數(shù)據(jù)涕蜂，速度肯定要比跨機(jī)架獲取數(shù)據(jù)要快映琳。
2.如果本機(jī)所在的機(jī)架出現(xiàn)問(wèn)題萨西，那么之前在存儲(chǔ)的時(shí)候沒(méi)有把所有副本都放在一個(gè)機(jī)架內(nèi)，這就能保證數(shù)據(jù)的安全性葱跋，此種情況出現(xiàn)源梭，就能保證客戶端也能取到數(shù)據(jù)。
2. 數(shù)據(jù)塊備份數(shù)目可變荠卷，增加備份數(shù)量不僅更安全烛愧，而且能夠明顯分散機(jī)群的讀取負(fù)載，因?yàn)榭梢栽诙鄠€(gè)節(jié)點(diǎn)中尋找到目標(biāo)數(shù)據(jù)怜姿，減少單個(gè)節(jié)點(diǎn)讀取沧卢。
這里還要注意一點(diǎn)，這個(gè)塊的大小不是隨機(jī)定義的：
3.2.3為什么塊的大小設(shè)置為64MB或者128MB?
磁盤(pán)是由數(shù)據(jù)塊組成的违寿，一般默認(rèn)大小是512字節(jié)熟空，構(gòu)建磁盤(pán)之上的文件系統(tǒng)一般是磁盤(pán)塊的整數(shù)倍。
HDFS將數(shù)據(jù)塊設(shè)置的這么大最主要的目的是為了最小化尋址時(shí)間掂咒。
“HDFS的塊比磁盤(pán)塊大迈喉，其目的是為了最小化尋址開(kāi)銷。如果塊設(shè)置得足夠大孩革，從磁盤(pán)傳輸數(shù)據(jù)的時(shí)間可以明顯大于定位這個(gè)塊開(kāi)始位置所需的時(shí)間得运。這樣，傳輸一個(gè)由多個(gè)塊組成的文件的時(shí)間就取決于磁盤(pán)傳輸速率饱搏⊥品校”
“我們做一個(gè)估計(jì)計(jì)算，如果尋址時(shí)間為10ms左右肺素，而傳輸速率為100MB/s宇驾，為了使尋址時(shí)間僅占傳輸時(shí)間的1%飞苇，我們需要設(shè)置塊大小為100MB左右。而默認(rèn)的塊大小實(shí)際為64MB雨让，但是很多情況下HDFS使用128MB的塊設(shè)置忿等。以后隨著新一代磁盤(pán)驅(qū)動(dòng)器傳輸速率的提升贸街，塊的大小將被設(shè)置得更大⊙Ψ耍”
“但是逸尖，該參數(shù)也不會(huì)設(shè)置得過(guò)大。MapReduce中的map任務(wù)通常一次處理一個(gè)塊中的數(shù)據(jù)岩齿，因此苞俘，如果任務(wù)數(shù)太少（甚至少于集群中的節(jié)點(diǎn)數(shù)量）吃谣，作業(yè)的map變少做裙，運(yùn)行速度就會(huì)變慢菇用∠菥荆” —-《Hadoop權(quán)威指南》
總結(jié): 塊越大,定位文件的尋址時(shí)間越短悍缠，總體的文件傳輸速率取決于磁盤(pán)傳輸速率耐量。隨著磁盤(pán)傳輸速率不斷提升，塊也從64MB變?yōu)榱?28MB,甚至也出現(xiàn)了256MB的塊的設(shè)置趴拧。
為什么塊不能設(shè)置的過(guò)兄瘛屁倔？
1. 這里一方面是為了最小化尋址時(shí)間
2. 另一方面NameNode的元數(shù)據(jù)維護(hù)文件存儲(chǔ)映射關(guān)系，如果塊小而多的話问麸，NameNode的內(nèi)存就扛不住了严卖。這同樣也是為什么HDFS不適合大量小文件存儲(chǔ)的原因布轿。
為什么塊不能設(shè)置的過(guò)大驮捍？
1.MapReduce中的map任務(wù)通常一次處理一個(gè)塊中的數(shù)據(jù)，因此启具，如果任務(wù)數(shù)太少（甚至少于集群中的節(jié)點(diǎn)數(shù)量）珊泳，作業(yè)的map變少，運(yùn)行速度就會(huì)變慢薯演。
2.數(shù)據(jù)塊過(guò)大跨扮，文件寫(xiě)入的過(guò)程會(huì)增加傳輸管道的運(yùn)行時(shí)間，在此期間如果出現(xiàn)故障中斷任務(wù)會(huì)增加服務(wù)開(kāi)銷帝嗡。（個(gè)人思考璃氢，非官方回答）
四一也、名稱節(jié)點(diǎn)工作原理
名稱節(jié)點(diǎn)負(fù)責(zé)管理分布式文件系統(tǒng)的命名空間抑月，它保存了兩個(gè)核心的數(shù)據(jù)結(jié)構(gòu)——FsImage爪幻、EditLog须误；
命名空間聽(tīng)起來(lái)唬人京痢，其實(shí)簡(jiǎn)單理解就是Linux的root。
4.1HDFS命名空間臭家、FsImage方淤、EditLog的基本功能解析
- HDFS命名空間：目錄携茂、文件、塊带膜。命名空間管理就是指對(duì)HDFS中目錄、文件式廷、塊做類似文件系統(tǒng)的創(chuàng)建滑废、修改览绿、刪除等基本操作穗慕。
- FsImage：維護(hù)文件系統(tǒng)樹(shù)以及文件樹(shù)中的文件和文件夾的元數(shù)據(jù)逛绵。
- EditLog：記錄針對(duì)文件的創(chuàng)建术浪、刪除、重命名等這樣的更新操作硕蛹；
這里有個(gè)問(wèn)題硕并，為什么一定要是這樣的設(shè)計(jì)倔毙，這樣的設(shè)計(jì)有什么深意？
4.2為什么一定要用FsImage卵蛉，EditLog的組合傻丝？
這個(gè)問(wèn)題沒(méi)有找到很好的標(biāo)準(zhǔn)答案诉儒，文件系統(tǒng)鏡像（Fsimage）是Hadoop HDFS的一個(gè)核心組件，它記錄了文件系統(tǒng)的元數(shù)據(jù)信息运准，包括文件和目錄的名稱胁澳、權(quán)限、大小宇智、時(shí)間戳等随橘。但是锦庸，如果在FsImage生成之后，文件系統(tǒng)發(fā)生了新的更改萝嘁，那么這些更改將無(wú)法被記錄在FsImage中牙言。
因此怪得，為了確保最新的更改被記錄徒恋，我們需要定期生成新的Fsimage文件，并將其與此前的FsImage文件進(jìn)行比較基括，以確定哪些更改是新的风皿，需要被記錄匠璧。
他這里的解析簡(jiǎn)直就像放屁夷恍。有一個(gè)很明顯的邏輯缺陷，就是沒(méi)有解釋為什么不直接寫(xiě)入FsImage遏暴？
為什么新的更改將無(wú)法被記錄在FsImage中朋凉？
1.FsImage無(wú)法記錄新變化的一個(gè)可能原因是FsImage是一個(gè)靜態(tài)文件，記錄了某個(gè)時(shí)間點(diǎn)的文件系統(tǒng)元數(shù)據(jù)墓毒。（從他的名字也可看出來(lái)亲怠，鏡像文件嘛）
2.FsImage文件一般都很大（GB級(jí)別的很常見(jiàn)）团秽，如果所有的更新操作都往FsImage文件中添加徙垫，這樣會(huì)導(dǎo)致系統(tǒng)運(yùn)行的十分緩慢
4.3FsImage、EditLog工作原理：
名稱節(jié)點(diǎn)運(yùn)行期間，HDFS內(nèi)的更新操作被寫(xiě)入到EditLog文件中吴旋，隨著更新操作的不斷發(fā)生厢破，EditLog也將不斷變大摩泪。
名稱節(jié)點(diǎn)在每次重啟時(shí)，將FsImage加載到內(nèi)存中嚷掠，再逐條執(zhí)行EditLog中的記錄不皆，使FsImage保持最新?tīng)顟B(tài)熊楼。
但是這樣會(huì)面臨一個(gè)問(wèn)題,EditLog的記錄如果很多的話就會(huì)導(dǎo)致名稱節(jié)點(diǎn)加載他的過(guò)程中啟動(dòng)過(guò)慢，影響正常服務(wù)的效率踩晶。
仔細(xì)思考下枕磁，如何解決它透典？其實(shí)這是很簡(jiǎn)單的一個(gè)問(wèn)題峭咒，定期清理EditLog更新FsImage就可以了。
EditLog過(guò)大怎么辦则果？
定期清理EditLog更新FsImage漩氨。這個(gè)定期其實(shí)可以設(shè)置成固定的周期叫惊，如一天清理一次霍狰，一周清理一次，可根據(jù)具體情況具體調(diào)整康震；也可以設(shè)置一個(gè)閾值腿短，EditLog高于此閾值就開(kāi)始進(jìn)行清理绘梦。
我們知道FsImage是一個(gè)靜態(tài)文件谚咬，因此不能直接在原文件上操作，只能采用副本的策略敲长。由此祈噪，HDFS設(shè)計(jì)了第二名稱節(jié)點(diǎn)(SecondaryNameNode)來(lái)進(jìn)行FsImage的更新。
4.4第二名稱節(jié)點(diǎn) SecondaryNameNode
SecondaryNameNode和NameNode內(nèi)存需求相同盔腔，兩者是運(yùn)行在不同的機(jī)器上的弛随。 SecondaryNameNode 周期性地與 NameNode 通信舀透，進(jìn)行檢查點(diǎn)操作决左，合并FsImage和EditLog佛猛。 具體操作流程如下：
檢查點(diǎn)間隔由兩個(gè)參數(shù)確定：fs.checkpoint.period 和 fs.checkpoint.size继找。 前者指定兩個(gè)連續(xù)檢查點(diǎn)之間的最長(zhǎng)時(shí)間（以秒為單位）码荔，默認(rèn)值為 3600 秒（一小時(shí)）。 后者指定觸發(fā)檢查點(diǎn)的 EditLog 文件的最大大小（以字節(jié)為單位）硼瓣，默認(rèn)值為 64 MB堂鲤。
其實(shí)第二名稱節(jié)點(diǎn)也相當(dāng)于名稱節(jié)點(diǎn)的一個(gè)備份媒峡，只是實(shí)時(shí)性沒(méi)有那么高谅阿，但是當(dāng)名稱節(jié)點(diǎn)出現(xiàn)故障的時(shí)候酬滤，第二名稱節(jié)點(diǎn)也能頂上去盯串，只不過(guò)原名稱節(jié)點(diǎn)的EditLog就會(huì)丟失了体捏。
說(shuō)人話就是糯崎，F(xiàn)sImage在SecondaryNameNode處更新沃呢。
五樟插、數(shù)據(jù)節(jié)點(diǎn)工作原理
數(shù)據(jù)節(jié)點(diǎn)工作原理相關(guān)資料比較少，簡(jiǎn)單理解下就行了搪缨。
數(shù)據(jù)節(jié)點(diǎn)是HDFS的工作節(jié)點(diǎn)副编，負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取痹届，會(huì)根據(jù)客戶端或者是名稱節(jié)點(diǎn)的調(diào)度來(lái)進(jìn)行數(shù)據(jù)的存儲(chǔ)和檢索打月，并且向名稱節(jié)點(diǎn)定期發(fā)送自己所存儲(chǔ)的塊的列表奏篙。
在我的理解中秘通，數(shù)據(jù)節(jié)點(diǎn)主要做的工作是存儲(chǔ)，管理文件第股。
- 存儲(chǔ)：在HDFS中夕吻，文件被拆分為一個(gè)或多個(gè)塊梭冠，數(shù)據(jù)節(jié)點(diǎn)作為存儲(chǔ)數(shù)據(jù)塊的媒介控漠。
- 管理：DataNode 可以執(zhí)行文件系統(tǒng)命名空間的操作，例如打開(kāi)偶翅、關(guān)閉和重命名文件或目錄聚谁。同時(shí)DataNode還維護(hù)著數(shù)據(jù)塊到數(shù)據(jù)節(jié)點(diǎn)的映射滞诺。
在這里我突然產(chǎn)生了一個(gè)小小的疑問(wèn)习霹，他們倆都維護(hù)映射關(guān)系淋叶，這是冗余煞檩？
數(shù)據(jù)節(jié)點(diǎn)和名稱節(jié)點(diǎn)分別維護(hù)的映射關(guān)系有什么區(qū)別斟湃？
這里需要注意一點(diǎn),名稱節(jié)點(diǎn)（NameNode）內(nèi)部的元數(shù)據(jù)維護(hù)著文件到數(shù)據(jù)塊的映射，同時(shí)包含著數(shù)據(jù)塊所在的數(shù)據(jù)節(jié)點(diǎn)（DataNode）癣缅。
數(shù)據(jù)節(jié)點(diǎn)則記錄了此節(jié)點(diǎn)內(nèi)部所有的數(shù)據(jù)塊，維護(hù)著數(shù)據(jù)節(jié)點(diǎn)到數(shù)據(jù)塊的映射關(guān)系哄酝。
一開(kāi)始我是認(rèn)為這是一種冗余存儲(chǔ)，后來(lái)我才想明白名稱節(jié)點(diǎn)是不知道一個(gè)數(shù)據(jù)節(jié)點(diǎn)內(nèi)分別有哪幾個(gè)數(shù)據(jù)塊的,它僅僅記錄這一個(gè)文件對(duì)應(yīng)的幾個(gè)塊在哪幾個(gè)數(shù)據(jù)節(jié)點(diǎn)上祷膳。
事實(shí)上陶衅，通過(guò)DataNode查詢其數(shù)據(jù)塊的場(chǎng)景非常少，為此消耗寶貴的內(nèi)存空間存儲(chǔ)這種映射關(guān)系性價(jià)比太低直晨。
六搀军、HDFS體系架構(gòu)
HDFS采用了主從（Master/Slave）結(jié)構(gòu)模型膨俐，一個(gè)HDFS集群包括一個(gè)名稱節(jié)點(diǎn)（NameNode）和若干個(gè)數(shù)據(jù)節(jié)點(diǎn)（DataNode）罩句。名稱節(jié)點(diǎn)通過(guò)心跳機(jī)制實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)節(jié)點(diǎn)的狀態(tài)
6.1 心跳機(jī)制
數(shù)據(jù)節(jié)點(diǎn)每隔固定時(shí)間向名稱節(jié)點(diǎn)匯報(bào)心跳焚刺，心跳內(nèi)容包括：
報(bào)告自己的存活狀態(tài)，每次匯報(bào)之后都會(huì)更新維護(hù)的計(jì)數(shù)信息
向nameNode匯報(bào)自己的存儲(chǔ)的block列表信息
這個(gè)簡(jiǎn)單了解下吧门烂，我估計(jì)沒(méi)人關(guān)注這玩意兒乳愉。
NameNode通過(guò)心跳判斷DataNode是否宕機(jī)的細(xì)節(jié)
nameNode判斷一個(gè)dataNode是否宕機(jī)的基準(zhǔn)：連續(xù)10次接收不到dataNode的心跳信息，和2次的檢查時(shí)間屯远。
如果namenode連續(xù)十次沒(méi)有收到datanode的匯報(bào)蔓姚，那么namenode就會(huì)認(rèn)為該datanode存在宕機(jī)的可能。
這里要注意datanode啟動(dòng)以后會(huì)專門(mén)啟動(dòng)一個(gè)進(jìn)程負(fù)責(zé)給namenode發(fā)送心跳數(shù)據(jù)包慨丐，所以存在一種可能坡脐，datanode沒(méi)有問(wèn)題，僅僅只是發(fā)送信息數(shù)據(jù)包的進(jìn)程掛了房揭，namenode后續(xù)還會(huì)發(fā)送命令向這個(gè)datanode進(jìn)行確認(rèn)备闲，
namenode會(huì)向datanode確認(rèn)兩遍，查看這個(gè)發(fā)送心跳包的進(jìn)程是否還能正常運(yùn)行捅暴，每隔一段時(shí)間確認(rèn)一次恬砂。如果兩次都沒(méi)有返回結(jié)果，那么namenode就會(huì)認(rèn)為datanode已經(jīng)宕機(jī)了伶唯。
6.2數(shù)據(jù)存取策略
6.2.1數(shù)據(jù)存放
存放我們要兼顧存放速度和數(shù)據(jù)安全觉既。
名稱節(jié)點(diǎn)會(huì)根據(jù)數(shù)據(jù)節(jié)點(diǎn)的心跳判斷其是否健康。衡量的點(diǎn)包括：
是否宕機(jī)
是否有充足存儲(chǔ)空間
IO負(fù)載繁忙程度
同時(shí)在上文中我們也提到了乳幸，為了容錯(cuò)數(shù)據(jù)節(jié)點(diǎn)會(huì)有存儲(chǔ)至少三份瞪讼。
6.2.2數(shù)據(jù)讀取
讀取我們考慮的主要是讀取速度。
我們要讀取的某個(gè)數(shù)據(jù)塊有三個(gè)副本粹断，優(yōu)先考慮同一機(jī)架內(nèi)的數(shù)據(jù)塊符欠。如果沒(méi)有的話，應(yīng)該就是隨機(jī)了瓶埋。
6.3容錯(cuò)恢復(fù)
6.3.1名稱節(jié)點(diǎn)出錯(cuò)
第二名稱節(jié)點(diǎn)
SecondaryNameNode 周期性地與 NameNode 通信希柿，進(jìn)行檢查點(diǎn)操作，合并FsImage和EditLog养筒，獲得最新的FsImage曾撤。
在名稱節(jié)點(diǎn)宕機(jī)后，第二名稱節(jié)點(diǎn)作為備份會(huì)頂上去晕粪，當(dāng)然原EditLog內(nèi)的部分元數(shù)據(jù)會(huì)丟失挤悉。
高可用HA（High Available）
以上的方案存在一定的問(wèn)題，單一的NameNode對(duì)外提供服務(wù)風(fēng)險(xiǎn)太高巫湘，很容易出現(xiàn)單點(diǎn)故障装悲。
HDFS-HA功能通過(guò)配置Active/Standby兩個(gè)nameNodes(2.0支持一主一備昏鹃，3.0最多支持一主五備)實(shí)現(xiàn)在集群中對(duì)NameNode的熱備份來(lái)解決上述問(wèn)題
這個(gè)注意對(duì)NameNode設(shè)置的備份，不能是像SecondaryNameNode間隔同步備份诀诊。HA是為NameNode增加實(shí)時(shí)同步的副本（熱備份）洞渤。
DataNode向兩個(gè)NamenNode匯報(bào)，兩個(gè)NameNode內(nèi)存一致属瓣，數(shù)據(jù)同步载迄，功能相同。
這里要注意：兩個(gè)NameNode不能同時(shí)向外提供服務(wù)奠涌，要保證主官和副官有一個(gè)能指揮的宪巨，但是不能兩個(gè)一起指揮。
6.3.2數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)
根據(jù)6.1的心跳機(jī)制溜畅，數(shù)據(jù)節(jié)點(diǎn)定時(shí)向名稱節(jié)點(diǎn)匯報(bào)自己的狀態(tài)捏卓，如果數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)，名稱節(jié)點(diǎn)將不會(huì)給該數(shù)據(jù)節(jié)點(diǎn)派發(fā)任何IO請(qǐng)求慈格。
至于恢復(fù)怠晴，在設(shè)計(jì)之初我們就認(rèn)為DataNode不太行，所以將數(shù)據(jù)塊存儲(chǔ)在不同的數(shù)據(jù)節(jié)點(diǎn)中浴捆，分散風(fēng)險(xiǎn)蒜田，所有block所在的數(shù)據(jù)節(jié)點(diǎn)同時(shí)宕機(jī)的可能性微乎其微。
雖然數(shù)據(jù)節(jié)點(diǎn)同時(shí)宕機(jī)幾乎不可能出現(xiàn)选泻，但是數(shù)據(jù)節(jié)點(diǎn)前后宕機(jī)也可能會(huì)影響到系統(tǒng)的正常運(yùn)轉(zhuǎn)冲粤。
冗余因子
HDFS為數(shù)據(jù)節(jié)點(diǎn)設(shè)計(jì)一個(gè)參數(shù)，冗余因子页眯。
由于一些數(shù)據(jù)節(jié)點(diǎn)的宕機(jī)梯捕，會(huì)導(dǎo)致一些數(shù)據(jù)塊的副本數(shù)量小于冗余因子。名稱節(jié)點(diǎn)會(huì)定期檢查這種情況（應(yīng)該是通過(guò)元數(shù)據(jù)和心跳對(duì)照檢查）窝撵，一旦發(fā)現(xiàn)某個(gè)數(shù)據(jù)塊的副本數(shù)量小于冗余因子傀顾，就會(huì)啟動(dòng)數(shù)據(jù)冗余復(fù)制，為它生成新的副本碌奉。
HDFS和其它分布式文件系統(tǒng)的最大區(qū)別就是可以調(diào)整冗余數(shù)據(jù)的位置
6.3.3數(shù)據(jù)出錯(cuò)
網(wǎng)絡(luò)傳輸和磁盤(pán)錯(cuò)誤等因素短曾，都會(huì)造成數(shù)據(jù)錯(cuò)誤
客戶端在讀取到數(shù)據(jù)后，會(huì)采用校驗(yàn)和對(duì)數(shù)據(jù)塊進(jìn)行校驗(yàn)（常用的CRC-32）赐劣，以確定讀取到正確的數(shù)據(jù)嫉拐。具體方法為：
在文件被創(chuàng)建時(shí)，客戶端就會(huì)對(duì)每一個(gè)文件塊進(jìn)行信息摘錄魁兼，并把這些信息寫(xiě)入到同一個(gè)路徑的隱藏文件里面椭岩。
當(dāng)客戶端讀取文件的時(shí)候，會(huì)先讀取該信息文件，然后判哥，利用該信息文件對(duì)每個(gè)讀取的數(shù)據(jù)塊進(jìn)行校驗(yàn)，如果校驗(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è)塊
七侯谁、HDFS文件操作
HDFS提供了一個(gè)客戶端提供了接口用來(lái)操作文件锌仅、目錄。
7.1寫(xiě)入文件
面經(jīng)高頻考點(diǎn)墙贱，但是死記硬背不如切實(shí)理解热芹。
Client與NameNode通信校驗(yàn)是否可以上傳文件。（包括是否存在文件惨撇，是否客戶是否有權(quán)限上傳文件伊脓，文件的父目錄是否已存在）NameNode確認(rèn)可上傳才會(huì)繼續(xù)下一步，同時(shí)會(huì)將該操作寫(xiě)進(jìn)EditLog魁衙。
Client對(duì)文件進(jìn)行拆分报腔，向NameNode詢問(wèn)是否第一個(gè)數(shù)據(jù)塊傳輸?shù)侥膸讉€(gè)DataNode上。一般情況下剖淀，NameNode會(huì)返回三臺(tái)DataNode服務(wù)器DataNode 1纯蛾，DataNode 2，DataNode 3
開(kāi)始進(jìn)行文件傳輸纵隔，因?yàn)橛腥_(tái)NamaNode服務(wù)器翻诉，HDFS的傳輸采用了pipline的方式。NameNode傳輸給DataNode1,DataNode1 傳輸給DataNode2,DataNode2傳輸給DataNode3捌刮。
當(dāng)一個(gè)block傳輸完成之后碰煌，Client再次請(qǐng)求NameNode上傳第二個(gè)block的服務(wù)器.
以pipline的寫(xiě)入方式而非并行寫(xiě)入最主要的優(yōu)勢(shì)就是節(jié)省了DataNode的IO開(kāi)銷，傳輸一次和傳輸三次的差別還是挺明顯的糊啡。
這里的應(yīng)答序列需要三個(gè)都成功拄查，NameNode才會(huì)接收到寫(xiě)入成功的信號(hào)，否則會(huì)重復(fù)發(fā)送棚蓄。
7.2讀數(shù)據(jù)
1堕扶、客戶端與NameNode通信查詢?cè)獢?shù)據(jù)，找到文件塊所在的DataNode服務(wù)器
2梭依、挑選一臺(tái)DataNode（網(wǎng)絡(luò)拓?fù)渖系木徒瓌t稍算，如果都一樣，則隨機(jī)挑選一臺(tái)DataNode）服務(wù)器役拴，請(qǐng)求建立socket流
3糊探、DataNode開(kāi)始發(fā)送數(shù)據(jù)(從磁盤(pán)里面讀取數(shù)據(jù)放入流，以packet（一個(gè)packet為64kb）為單位來(lái)做校驗(yàn))
4、客戶端以packet為單位接收科平，先在本地緩存褥紫，然后寫(xiě)入目標(biāo)文件
