最近一週都是講HDFS，昨天的這篇《 》，只是以另一個角度，今天來講講HDFS的架構，先來複習一下Hadoop。耐心看完，我的文章從來不會讓你失望。

一、前奏

Hadoop是目前大數據領域最主流的一套技術體系，包含了多種技術。

包括HDFS（分佈式文件系統），YARN（分佈式資源調度系統），MapReduce（分佈式計算系統），等等。

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

假如你現在公司裡的數據都是放在MySQL裡的，那麼就全部放在一臺數據庫服務器上，我們就假設這臺服務器的磁盤空間有2T吧，大家先看下面這張圖。

現在問題來了，你不停的往這臺服務器的MySQL裡放數據，結果數據量越來越大了，超過了2T的大小了，現在咋辦？

你說，我可以搞多臺MySQL數據庫服務器，分庫分表啊！每臺服務器放一部分數據不就得了。如上圖所示！

好，沒問題，那咱們搞3臺數據庫服務器，3個MySQL實例，然後每臺服務器都可以2T的數據。

現在我問你一個問題，所謂的大數據是在幹什麼？

我們來說一下大數據最初級的一個使用場景。假設你有一個電商網站，現在要把這個電商網站裡所有的用戶在頁面和APP上的點擊、購買、瀏覽的行為日誌都存放起來分析。

你現在把這些數據全都放在了3臺MySQL服務器，數據量很大，但還是勉強可以放的下。

某天早上，你的boss來了。要看一張報表，比如要看每天網站的X指標、Y指標、Z指標，等等，二三十個數據指標。

好了，兄弟，現在你嘗試去從那些點擊、購買、瀏覽的日誌裡，通過寫一個SQL來分析出那二三十個指標試試看？

我跟你打賭，你絕對會寫出來一個幾百行起步，甚至上千行的超級複雜大SQL。這個SQL，你覺得他能運行在分庫分表後的3臺MySQL服務器上麼？

如果你覺得可以的話，那你一定是不太瞭解MySQL分庫分表後有多坑，幾百行的大SQL跨庫join，各種複雜的計算，根本不現實。

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

本質上，Hadoop、Spark等大數據技術，其實就是一系列的分佈式系統。

比如hadoop中的HDFS，就是大數據技術體系中的核心基石，負責分佈式存儲數據，這是啥意思？別急，繼續往下看。

HDFS全稱是Hadoop Distributed File System，是Hadoop的分佈式文件系統。

它由很多機器組成，每臺機器上運行一個DataNode進程，負責管理一部分數據。

然後有一臺機器上運行了NameNode進程，NameNode大致可以認為是負責管理整個HDFS集群的這麼一個進程，他裡面存儲了HDFS集群的所有元數據。

然後有很多臺機器，每臺機器存儲一部分數據！好，HDFS現在可以很好的存儲和管理大量的數據了。

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

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

如果你硬要基於MySQL分庫分表這個事兒，會痛苦很多倍，因為MySQL並不是設計為分佈式系統架構的，他在分佈式數據存儲這塊缺乏很多數據保障的機制。

好，你現在用HDFS分佈式存儲了數據，接著不就是要分佈式來計算這些數據了嗎？

對於分佈式計算：

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

總之就是寫一個大SQL，人家會拆分為很多的計算任務，放到各個機器上去，每個計算任務就負責計算一小部分數據，這就是所謂的分佈式計算。

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

對於上述所說，老規矩，同樣給大家來一張圖，大夥兒跟著圖來仔細捋一下整個過程。

二、HDFS的NameNode架構原理

好了，前奏鋪墊完之後，進入正題。本文其實主要就是討論一下HDFS集群中的NameNode的核心架構原理。

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

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

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

然後NameNode就會在自己內存的文件目錄樹裡，在指定的目錄下搞一個新的文件對象，名字就是“access_20180101.log”。

這個文件目錄樹不就是HDFS非常核心的一塊元數據，維護了HDFS這個分佈式文件系統中，有哪些目錄，有哪些文件，對不對？

但是有個問題，這個文件目錄樹是在NameNode的內存裡的啊！

這可坑爹了，你把重要的元數據都放在內存裡，萬一NameNode不小心宕機了可咋整？元數據不就全部丟失了？

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

沒關係，我們來看看HDFS優雅的解決方案。

每次內存裡改完了，寫一條edits log，元數據修改的操作日誌到磁盤文件裡，不修改磁盤文件內容，就是順序追加，這個性能就高多了。

每次NameNode重啟的時候，把edits log裡的操作日誌讀到內存裡回放一下，不就可以恢復元數據了？

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

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

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

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

然後Standby NameNode就可以從JournalNodes集群拉取edits log，應用到自己內存的文件目錄樹裡，跟Active NameNode保持一致。

然後每隔一段時間，Standby NameNode都把自己內存裡的文件目錄樹寫一份到磁盤上的fsimage，這可不是日誌，這是完整的一份元數據。這個操作就是所謂的checkpoint檢查點操作。

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

然後Active NameNode繼續接收修改元數據的請求，再寫入edits log，寫了一小會兒，這裡可能就幾十行修改日誌而已！

如果說此時，Active NameNode重啟了，bingo！沒關係，只要把Standby NameNode傳過來的fsimage直接讀到內存裡，

這個fsimage直接就是元數據，不需要做任何額外操作，純讀取，效率很高！

然後把新的edits log裡少量的幾十行的修改日誌回放到內存裡就ok了！

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

此外，大家看看上面這張圖

，現在咱們有倆NameNode。

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

大家有沒有發現！他們倆內存裡的元數據幾乎是一模一樣的啊！

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

這不就是所謂的NameNode主備高可用故障轉移機制麼！

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

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

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

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

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

也就是說上傳上去的1TB的大文件，會丟失一小部分數據啊。沒關係！HDFS都考慮好了！

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

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

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

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