簡單理解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的基本架構原理

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！