【內含思維導圖,建議收藏】淺談 HDFS 的設計思想

Shockang 2021-08-15 21:13:46 阅读数:773

本文一共[544]字,预计阅读时长:1分钟~
收藏 hdfs 思想

這是我參與8月更文挑戰的第6天,活動詳情查看:8月更文挑戰

本文不涉及HDFS的具體細節,只是談談HDFS的設計思想與實現思路,幫助更好的理解HDFS的總體架構。

設計思想

誕生背景

​ 伴隨著互聯網的迅速發展,需要計算處理的數據量急速膨脹。在稍微大一點的互聯網企業,需要計算處理的數據量常常以 PB 計。一臺計算機所能調度的網絡帶寬(通常數百 MB)、內存容量(通常幾十 GB )、磁盤大小(通常數 TB)、CPU 運算速度是不可能滿足這種計算要求的。

​ 此時就產生了這樣一個需求背景:

我們需要一個文件系統,可以支持海量數據的存儲與計算,並且對外提供一個統一的讀寫API。
複制代碼

面臨的問題

​ 要想支持海量數據的存儲與計算,我們需要解决幾個核心問題:

1.數據存儲容量的問題。

​ 既然大數據要解决的是數以 PB 計的數據計算問題,而一般的服務器磁盤容量通常 1~2TB,那麼如何存儲這麼大規模的數據呢?

2.數據讀寫速度的問題。

​ 一般磁盤的連續讀寫速度為幾十 MB,以這樣的速度,幾十 PB 的數據恐怕要讀寫到天荒地老。

3.數據可靠性的問題。

​ 磁盤大約是計算機設備中最易損壞的硬件了,通常情况一塊磁盤使用壽命大概是一年,如果磁盤損壞了,數據怎麼辦?

思維的火種

垂直伸縮 VS 水平伸縮

​ 在計算機領域,實現更强的計算能力和更大規模的數據存儲有兩種思路,

  • “垂直伸縮”(scaling up),通過昇級 CPU、內存、磁盤等將一臺計算機變得更强大;

  • “水平伸縮”(scaling out),添加更多的計算機到系統中,從而實現更强大的計算能力。

    顯然垂直伸縮意味著更高的成本,而且垂直伸縮是有極限的,水平伸縮則沒有(或者說極限遠比垂直伸縮更高)。所以,我們要想解决我們的問題,只能從水平伸縮下手。

水平伸縮能不能滿足我們的需求

​ 目前來看,我們只能走水平伸縮的路子,那麼水平伸縮就一定可以滿足需求嗎?

用戶請求方面

​ 網站實時處理通常針對單個用戶的請求操作,雖然大型網站面臨大量的高並發請求,但是每個用戶之間的請求是獨立的,只要網站的分布式系統能將不同用戶的不同業務請求分配到不同的服務器上,我們在每臺服務器上啟動一個進程去處理這些請求,同時只要這些分布式的服務器之間耦合關系足够小,就可以通過添加更多的服務器去處理更多的用戶請求及由此產生的用戶數據,保障了系統的可伸縮性。

移動計算比移動數據更劃算

​ 面對著PB級別的數據,程序本身可能只有KB或者MB級別。既然數據量比程序本身要龐大的多,那麼將數據發送給程序是不劃算的。我們可以換一種思路,將程序通過網絡傳輸發送給數據所在的地方,這一點實際上是和水平伸縮的思路符合的。

RAID

如果說我看得比別人更遠些,那是因為我站在巨人的肩膀上。 ——牛頓

​ 上面這段話基本上每個人都聽過,技術發展亦是如此。每一項流行性新技術的誕生不僅意味著一個亟待解决的技術難題,同時也是對前人技術的不斷總結與創新。

RAID(獨立磁盤冗餘陣列)技術是將多塊普通磁盤組成一個陣列,共同對外提供服務。主要是為了改善磁盤的存儲容量、讀寫速度,增强磁盤的可用性和容錯能力。
複制代碼

​ 這裏不探討RAID的具體實現細節,只描述下RAID碰到我們上面說的3個問題是怎樣去解决的?

畢竟實現細節可能各種各樣,百花齊放,但是設計思維是共通的,是永恒的,這也是我寫這篇文章的目的,從設計思維出發來幫助我們更好的理解HDFS的各種細節。

1.數據存儲容量的問題:RAID 使用了 N 塊磁盤構成一個存儲陣列,如果使用 RAID 5,數據就可以存儲在 N-1 塊磁盤上,這樣將存儲空間擴大了 N-1 倍。

2.數據讀寫速度的問題。RAID 根據可以使用的磁盤數量,將待寫入的數據分成多片,並發同時向多塊磁盤進行寫入,顯然寫入的速度可以得到明顯提高;同理,讀取速度也可以得到明顯提高。

3.數據可靠性的問題。使用 RAID 10、RAID 5 或者 RAID 6 方案的時候,由於數據有冗餘存儲,或者存儲校驗信息,所以當某塊磁盤損壞的時候,可以通過其他磁盤上的數據和校驗數據將丟失磁盤上的數據還原。

​ 上面這段話比較長,其實總結起來就3個關鍵字:

N塊磁盤構成存儲陣列

並發寫入

冗餘備份

完善

​ 經過上面的探討,我們其實已經有了一點較為完善的思路,可以幫助我們去解决剛開始提到的3個問題。

1.數據存儲容量的問題:多臺服務器對外呈現一個統一的文件系統,綜合CPU,磁盤,內存,網絡帶寬等,對外提供統一的讀寫API。

2.數據讀寫速度的問題:我們把數據分成多塊,並發的寫入系統。

3.數據可靠性的問題:我們對每個分塊都進行冗餘備份,一個數據塊對應多個副本。

以上內容我總結成了下面的思維導圖。

在這裏插入圖片描述

實現思路

​ 學習任何一門新技術,我推薦從問題出發,一步步的來解决問題。

​ 還是回到剛開始的三個問題:

一、數據存儲容量的問題(分布式)

1.分布式集群中怎麼知道哪些服務器存儲了哪些數據?

​ 這個不難想出,分布式集群中最常見的主從架構

​ 客戶端先和主服務器通信,獲取具體的存儲比特置,客戶端再和從服務器請求相應的數據。

​ 更進一步,主服務器負責和客戶端進行交互,從服務器來負責存儲具體的數據。

2.主服務器怎麼知道從服務器存儲了哪些數據?

​ 從服務器啟動後,從本地配置文件中獲取主服務器的地址,和主服務器通信,匯報本機存儲信息。 ​ 主服務器存儲著元數據信息,包括文件系統樹、整棵樹所有的文件和目錄、每個文件的塊列錶、塊所在的節點信息等。

​ 為了照顧到使用性和容錯性,數據分別保存在內存和磁盤中。

3.從服務器掛掉怎麼辦?某塊磁盤損壞怎麼辦?主服務器怎麼知道?

​ 這裏也使用一個比較經典的思維——心跳機制,從服務器定時和主服務器通信,一旦超時連接,則認為從服務器掛掉了。 ​ 這裏不得不提到冗餘備份。主服務器一旦確定從服務器掛掉,從本地內存中獲取該從服務器擁有的存儲信息,然後新建一個備份。如果從服務器確定磁盤損壞,則會將該磁盤存儲信息報告給主服務器,主服務器查到了相同的信息存儲在哪些其他的服務器,只需要新建一個備份就行。相應的請求也會轉移到備份的從服務器上面。

​ 這實際上體現了一種常見的保障系統可用性的思維——失效轉移

4.主服務器掛掉怎麼辦?

​ 主從熱備,共享元數據信息,當主的掛掉後,備份服務器立馬轉正,從而保證系統的可用性。

5.如何從故障中快速恢複過來?

​ 1.首先我們應該能想到,可以直接將整個文件系統打成鏡像,系統重啟後直接加載鏡像就好了;

​ 2.但是這樣會有一個問題,打一個鏡像得很長時間,這段時間系統不就不可用了?

這裏也有一個經典的解决方案:

我們可以將每次寫入的操作都記錄到日志文件裏面,這樣另起一個線程專門用來將日志合並到鏡像裏面不就好了。

​ 3.這樣還有一個問題,如果主服務器突然掛了,日志文件的數據寫入沒有合並到鏡像文件裏面,這樣系統重啟後,系統還是很長時間不可用怎麼辦?

​ 遇到這個問題,有個常見的解决方案,就是設置檢查點 ,每隔一定時間將日志文件裏面的寫入操作合並到鏡像文件裏面,為了加强系統的容錯性,檢查點要放到另外一臺服務器上面,這臺服務器專門用來負責處理將日志文件合並到鏡像文件。定時的將新生成的鏡像文件發送給主服務器,並且覆蓋主服務器的老鏡像。

​ 當然,還有一種解决方案也比較常見,就和我們每次裝系統一樣,每隔一段時間,生成一份快照,注意這裏的快照不同於上面的鏡像。

6.單臺主服務器面對海量的數據,內存不够怎麼辦?

​ 一臺的內存不够,那我加一臺;兩臺還不够,我再加!這其實就是上面講到的水平伸縮的思想。

7.元數據磁盤故障了怎麼辦?

​ 又是老問題了,相信你能脫口而出:冗餘備份!沒錯,我一臺服務器上面一個數據准備幾個副本不就行了,當然還有一種更好的方案:在多臺主服務器使用共享存儲或者使用分布式編輯日志。

二、數據讀寫速度的問題(數據分塊)

1.數據怎麼分塊?

​ 數據按照固定大小進行切分,要是大小不足怎麼辦?大小不足也算一個塊,這樣管理起來不就方便啦

2.數據塊大小比較合適呢?

​ 數據塊不能太小——首先數據塊對應的元數據信息都差不多,數據塊太小主服務器內存就不够用了,其次,數據塊太小,對於機械硬盤來講,每個數據塊都是連續的地址,切換數據塊,尋址耗時太長。

​ 數據塊不能太大——太大了怎麼達到並發寫入的要求呢?別忘了數據分塊的目的就是為了並發寫入的啊

3.如果碰到海量小數據怎麼辦?

​ 這個思路也比較常見,合並和壓縮唄。

三、數據可靠性的問題(冗餘備份)

1.數據要放到哪些節點呢?

​ 節點不能太近——一掛可能全部掛

​ 節點也不能太遠——距離越遠傳輸時間越長,這是根據香農定理得出來的。

2.讀取數據的時候具體要選擇哪個副本呢?

​ 這個考慮到香農定理,顯然越近越好,因為根據前面的結論,數據是客戶端在從服務器上面下載的,所以指的是客戶端和從服務器之間的距離。

3.怎麼保證數據的完整性呢?

​ 這裏也有一個經典的思維,既然數據量越大,網絡傳輸越不可靠,我們就想辦法把數據往小了切分 。

​ 我們使用校驗和來保障數據的完整性, 由於校驗和的大小遠小於數據的大小,所以校驗和的可靠性要比數據高得多。

​ 讀數據——客戶端讀完了數據的校驗和 與 主服務器內存裏面的校驗和比較,就知道數據讀取是否成功了。

​ 寫數據——對於數據塊來講,數據往小了切,一段一段的寫入,每一段都包括數據和校驗值,對於每一段數據,我們每個備份節點一臺一臺的寫,每一臺寫完了直接校驗。

具體到HDFS

​ 實際上HDFS就是按照上面的思路來設計的,當然上面的思路只能粗略的幫你理解HDFS的設計思想,更具體的內容以後我再寫篇文章來描述。

​ 上面每一個問題都對應了HDFS中的一個或幾個知識點,具體的請看下面的思維導圖。 實現思路

版权声明:本文为[Shockang]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815211248093D.html