兄弟，用大白話告訴你小白都能看懂的Hadoop架構原理

歡迎關注微信公衆號：石杉的架構筆記（id：shishan100）

個人新課**《C2C 電商系統微服務架構120天實戰訓練營》在公衆號儒猿技術窩**上線了，感興趣的同窗，能夠點擊下方連接瞭解詳情：

《C2C 電商系統微服務架構120天實戰訓練營》

目錄

1、前奏

2、HDFS的NameNode架構原理

1、前奏

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要靠譜的多。

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

2、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的基本架構原理

接下來會給你們聊聊HDFS，這個做爲世界上最優秀的分佈式存儲系統，承載高併發請求、高性能文件上傳的一些核心機制以及原理。

**《大規模集羣下Hadoop如何承載每秒上千次的高併發訪問》，**敬請期待

《【冰山下的祕密】Hadoop如何將TB級大文件的上傳性能提高上百倍？》，敬請期待

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上,

歡迎掃描下方二維碼，持續關注：


石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授