一、前奏

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

包括HDFS(分布式文件系統)，YARN(分布式資源調度系統)，MapReduce(分布式計算系統)，等等。

[[281404]]

有些朋友可能聽說過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的基本架構原理。