今天來講講HDFS的架構(gòu)，先來復(fù)習(xí)一下Hadoop。耐心看完，我的文章從來不會讓你失望。

一、前奏

Hadoop是目前大數(shù)據(jù)領(lǐng)域最主流的一套技術(shù)體系，包含了多種技術(shù)。

包括HDFS（分布式文件系統(tǒng)），YARN（分布式資源調(diào)度系統(tǒng)），MapReduce（分布式計算系統(tǒng)），等等。

有些朋友可能聽說過Hadoop，但是卻不太清楚他到底是個什么東西，這篇文章就用大白話給各位闡述一下。

假如你現(xiàn)在公司里的數(shù)據(jù)都是放在MySQL里的，那么就全部放在一臺數(shù)據(jù)庫服務(wù)器上，我們就假設(shè)這臺服務(wù)器的磁盤空間有2T吧，大家先看下面這張圖。

現(xiàn)在問題來了，你不停的往這臺服務(wù)器的MySQL里放數(shù)據(jù)，結(jié)果數(shù)據(jù)量越來越大了，超過了2T的大小了，現(xiàn)在咋辦？

你說，我可以搞多臺MySQL數(shù)據(jù)庫服務(wù)器，分庫分表啊！每臺服務(wù)器放一部分?jǐn)?shù)據(jù)不就得了。如上圖所示！

好，沒問題，那咱們搞3臺數(shù)據(jù)庫服務(wù)器，3個MySQL實例，然后每臺服務(wù)器都可以2T的數(shù)據(jù)。

現(xiàn)在我問你一個問題，所謂的大數(shù)據(jù)是在干什么？

我們來說一下大數(shù)據(jù)最初級的一個使用場景。假設(shè)你有一個電商網(wǎng)站，現(xiàn)在要把這個電商網(wǎng)站里所有的用戶在頁面和App上的點擊、購買、瀏覽的行為日志都存放起來分析。

你現(xiàn)在把這些數(shù)據(jù)全都放在了3臺MySQL服務(wù)器，數(shù)據(jù)量很大，但還是勉強(qiáng)可以放的下。

某天早上，你的boss來了。要看一張報表，比如要看每天網(wǎng)站的X指標(biāo)、Y指標(biāo)、Z指標(biāo)，等等，二三十個數(shù)據(jù)指標(biāo)。

好了，兄弟，現(xiàn)在你嘗試去從那些點擊、購買、瀏覽的日志里，通過寫一個SQL來分析出那二三十個指標(biāo)試試看？

我跟你打賭，你絕對會寫出來一個幾百行起步，甚至上千行的超級復(fù)雜大SQL。這個SQL，你覺得他能運(yùn)行在分庫分表后的3臺MySQL服務(wù)器上么？

如果你覺得可以的話，那你一定是不太了解MySQL分庫分表后有多坑，幾百行的大SQL跨庫join，各種復(fù)雜的計算，根本不現(xiàn)實。

所以說，大數(shù)據(jù)的存儲和計算壓根兒不是靠MySQL來搞的，因此，Hadoop、Spark等大數(shù)據(jù)技術(shù)體系才應(yīng)運(yùn)而生。

本質(zhì)上，Hadoop、Spark等大數(shù)據(jù)技術(shù)，其實就是一系列的分布式系統(tǒng)。

比如hadoop中的HDFS，就是大數(shù)據(jù)技術(shù)體系中的核心基石，負(fù)責(zé)分布式存儲數(shù)據(jù)，這是啥意思？別急，繼續(xù)往下看。

HDFS全稱是Hadoop Distributed File System，是Hadoop的分布式文件系統(tǒng)。

它由很多機(jī)器組成，每臺機(jī)器上運(yùn)行一個DataNode進(jìn)程，負(fù)責(zé)管理一部分?jǐn)?shù)據(jù)。

然后有一臺機(jī)器上運(yùn)行了NameNode進(jìn)程，NameNode大致可以認(rèn)為是負(fù)責(zé)管理整個HDFS集群的這么一個進(jìn)程，他里面存儲了HDFS集群的所有元數(shù)據(jù)。

然后有很多臺機(jī)器，每臺機(jī)器存儲一部分?jǐn)?shù)據(jù)！好，HDFS現(xiàn)在可以很好的存儲和管理大量的數(shù)據(jù)了。

這時候你肯定會有疑問：MySQL服務(wù)器也不是這樣的嗎？你要是這樣想，那就大錯特錯了。

這個事情不是你想的那么簡單的，HDFS天然就是分布式的技術(shù)，所以你上傳大量數(shù)據(jù)，存儲數(shù)據(jù)，管理數(shù)據(jù)，天然就可以用HDFS來做。

如果你硬要基于MySQL分庫分表這個事兒，會痛苦很多倍，因為MySQL并不是設(shè)計為分布式系統(tǒng)架構(gòu)的，他在分布式數(shù)據(jù)存儲這塊缺乏很多數(shù)據(jù)保障的機(jī)制。

好，你現(xiàn)在用HDFS分布式存儲了數(shù)據(jù)，接著不就是要分布式來計算這些數(shù)據(jù)了嗎？

對于分布式計算：

• 很多公司用Hive寫幾百行的大SQL（底層基于MapReduce）
• 也有很多公司開始慢慢的用Spark寫幾百行的大SQL（底層是Spark Core引擎）。

總之就是寫一個大SQL，人家會拆分為很多的計算任務(wù)，放到各個機(jī)器上去，每個計算任務(wù)就負(fù)責(zé)計算一小部分?jǐn)?shù)據(jù)，這就是所謂的分布式計算。

這個，絕對比你針對分庫分表的MySQL來跑幾百行大SQL要靠譜的多。

對于上述所說，老規(guī)矩，同樣給大家來一張圖，大伙兒跟著圖來仔細(xì)捋一下整個過程。

二、HDFS的NameNode架構(gòu)原理

好了，前奏鋪墊完之后，進(jìn)入正題。本文其實主要就是討論一下HDFS集群中的NameNode的核心架構(gòu)原理。

NameNode有一個很核心的功能：管理整個HDFS集群的元數(shù)據(jù)，比如說文件目錄樹、權(quán)限的設(shè)置、副本數(shù)的設(shè)置，等等。

下面就用最典型的文件目錄樹的維護(hù)，來給大家舉例說明，我們看看下面的圖。現(xiàn)在有一個客戶端系統(tǒng)要上傳一個1TB的大文件到HDFS集群里。

此時他會先跟NameNode通信，說：大哥，我想創(chuàng)建一個新的文件，他的名字叫“/usr/hive/warehouse/access_20180101.log”，大小是1TB，你看行不？

然后NameNode就會在自己內(nèi)存的文件目錄樹里，在指定的目錄下搞一個新的文件對象，名字就是“access_20180101.log”。

這個文件目錄樹不就是HDFS非常核心的一塊元數(shù)據(jù)，維護(hù)了HDFS這個分布式文件系統(tǒng)中，有哪些目錄，有哪些文件，對不對？

但是有個問題，這個文件目錄樹是在NameNode的內(nèi)存里的啊！

這可坑爹了，你把重要的元數(shù)據(jù)都放在內(nèi)存里，萬一NameNode不小心宕機(jī)了可咋整？元數(shù)據(jù)不就全部丟失了？

可你要是每次都頻繁的修改磁盤文件里的元數(shù)據(jù)，性能肯定是極低的啊！畢竟這是大量的磁盤隨機(jī)讀寫！

沒關(guān)系，我們來看看HDFS優(yōu)雅的解決方案。

每次內(nèi)存里改完了，寫一條edits log，元數(shù)據(jù)修改的操作日志到磁盤文件里，不修改磁盤文件內(nèi)容，就是順序追加，這個性能就高多了。

每次NameNode重啟的時候，把edits log里的操作日志讀到內(nèi)存里回放一下，不就可以恢復(fù)元數(shù)據(jù)了？

大家順著上面的文字，把整個過程，用下面這張圖跟著走一遍。

但是問題又來了，那edits log如果越來越大的話，豈不是每次重啟都會很慢？因為要讀取大量的edits log回放恢復(fù)元數(shù)據(jù)！

所以HDFS說，我可以這樣子啊，我引入一個新的磁盤文件叫做fsimage，然后呢，再引入一個JournalNodes集群，以及一個Standby NameNode（備節(jié)點）。

每次Active NameNode（主節(jié)點）修改一次元數(shù)據(jù)都會生成一條edits log，除了寫入本地磁盤文件，還會寫入JournalNodes集群。

然后Standby NameNode就可以從JournalNodes集群拉取edits log，應(yīng)用到自己內(nèi)存的文件目錄樹里，跟Active NameNode保持一致。

然后每隔一段時間，Standby NameNode都把自己內(nèi)存里的文件目錄樹寫一份到磁盤上的fsimage，這可不是日志，這是完整的一份元數(shù)據(jù)。這個操作就是所謂的checkpoint檢查點操作。

然后把這個fsimage上傳到到Active NameNode，接著清空掉Active NameNode的舊的edits log文件，這里可能都有100萬行修改日志了！

然后Active NameNode繼續(xù)接收修改元數(shù)據(jù)的請求，再寫入edits log，寫了一小會兒，這里可能就幾十行修改日志而已！

如果說此時，Active NameNode重啟了，bingo！沒關(guān)系，只要把Standby NameNode傳過來的fsimage直接讀到內(nèi)存里，這個fsimage直接就是元數(shù)據(jù)，不需要做任何額外操作，純讀取，效率很高！

然后把新的edits log里少量的幾十行的修改日志回放到內(nèi)存里就ok了！

這個過程的啟動速度就快的多了！因為不需要回放大量上百萬行的edits log來恢復(fù)元數(shù)據(jù)了！如下圖所示。

此外，大家看看上面這張圖，現(xiàn)在咱們有倆NameNode。

• 一個是主節(jié)點對外提供服務(wù)接收請求
• 另外一個純就是接收和同步主節(jié)點的edits log以及執(zhí)行定期checkpoint的備節(jié)點。

大家有沒有發(fā)現(xiàn)！他們倆內(nèi)存里的元數(shù)據(jù)幾乎是一模一樣的啊！

所以呢，如果Active NameNode掛了，是不是可以立馬切換成Standby NameNode對外提供服務(wù)？

這不就是所謂的NameNode主備高可用故障轉(zhuǎn)移機(jī)制么！

接下來大家再想想，HDFS客戶端在NameNode內(nèi)存里的文件目錄樹，新加了一個文件。

但是這個時候，人家要把數(shù)據(jù)上傳到多臺DataNode機(jī)器上去啊，這可是一個1TB的大文件！咋傳呢？

很簡單，把1TB的大文件拆成N個block，每個block是128MB。1TB = 1024GB = 1048576MB，一個block是128MB，那么就是對應(yīng)著8192個block。

這些block會分布在不同的機(jī)器上管理著，比如說一共有100臺機(jī)器組成的集群，那么每臺機(jī)器上放80個左右的block就ok了。

但是問題又來了，那如果這個時候1臺機(jī)器宕機(jī)了，不就導(dǎo)致80個block丟失了？

也就是說上傳上去的1TB的大文件，會丟失一小部分?jǐn)?shù)據(jù)啊。沒關(guān)系！HDFS都考慮好了！

它會默認(rèn)給每個block搞3個副本，一模一樣的副本，分放在不同的機(jī)器上，如果一臺機(jī)器宕機(jī)了，同一個block還有另外兩個副本在其他機(jī)器上呢！

大伙兒看看下面這張圖。每個block都在不同的機(jī)器上有3個副本，任何一臺機(jī)器宕機(jī)都沒事！還可以從其他的機(jī)器上拿到那個block。

這下子，你往HDFS上傳一個1TB的大文件，可以高枕無憂了吧！

OK，上面就是大白話加上一系列手繪圖，給大家先聊聊小白都能聽懂的Hadoop的基本架構(gòu)原理。