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

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

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

現在問題來了,你不停的往這臺服務器的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要靠譜的多。

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

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

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

現在問題來了,你不停的往這臺服務器的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要靠譜的多。

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

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

二、HDFS的NameNode架構原理

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

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

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

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

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

現在問題來了,你不停的往這臺服務器的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要靠譜的多。

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

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

二、HDFS的NameNode架構原理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

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

現在問題來了,你不停的往這臺服務器的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要靠譜的多。

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

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

二、HDFS的NameNode架構原理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是問題又來了,那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來恢復元數據了!如下圖所示。

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

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

現在問題來了,你不停的往這臺服務器的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要靠譜的多。

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

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

二、HDFS的NameNode架構原理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是問題又來了,那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來恢復元數據了!如下圖所示。

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

此外,大家看看上面這張圖,現在咱們有倆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的大文件,可以高枕無憂了吧!

"

專注於Java領域優質技術,歡迎關注

來自:石杉的架構筆記(id:shishan10)

目錄

一、前奏

二、HDFS的NameNode架構原理

一、前奏

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

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

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

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

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

現在問題來了,你不停的往這臺服務器的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要靠譜的多。

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

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

二、HDFS的NameNode架構原理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是問題又來了,那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來恢復元數據了!如下圖所示。

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

此外,大家看看上面這張圖,現在咱們有倆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的大文件,可以高枕無憂了吧!

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

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


現在人工智能非常火爆,很多朋友都想學,但是一般的教程都是為博碩生準備的,太難看懂了。最近發現了一個非常適合小白入門的教程,不僅通俗易懂而且還很風趣幽默。所以忍不住分享一下給大家。點下面可以跳轉到教程。

https://www.captainbed.net/suga

文章來自:https://juejin.im/entry/5beb6ca7e51d450fa35d42b1

"

相關推薦

推薦中...