分布式存儲基本原理

在了解分布式存儲架構之前，我們不妨先考慮自己設計一款分布式存儲系統，以此來嘗試了解Hadoop官方分布式存儲系統的設計理念。

首先，當我們想要對超過單個磁盤容量的檔案進行存儲的時候，我們唯二的辦法不外乎是擴大單個磁盤容量和增加磁盤總數量。理論上來說，檔案的大小是可以不斷增加的，而單個磁盤的大小擁有上限，是以唯一的辦法便成了增加磁盤總數量。具體來說，想要存儲超過磁盤容量的大檔案，我們可以将檔案進行等大小的拆分，然後存儲到不同的磁盤之上，在擷取檔案的時候，再将檔案進行合并即可。

然而以此産生的問題也不可避免，磁盤的故障率是客觀存在的，當大檔案非常多時，也同樣需要大量的磁盤進行存儲，是以磁盤故障這樣的小機率事件自然成為了必然事件，而一個磁盤的損壞意味着這個磁盤上所有的檔案都産生了丢失，在大檔案拆分存儲的場景下，每一個小檔案丢失的背後都代表着一個大檔案的全部損毀，是以這樣的設計有着緻命的缺陷。

對于解決這樣的缺陷，官方想到的辦法是采用多副本的機制，即：每個拆分出的檔案預設有着3份的副本，存儲在不同的磁盤之上，是以任意一個磁盤的損壞都不會引起大檔案的丢失，因為在所有磁盤組成的叢集當中，還有着另外兩份副本存在。

這樣将大檔案拆分成小檔案，分布的存儲在不同的磁盤隻上，并且每個小檔案儲存着三份副本的形式，就是分布式檔案存儲系統HDFS的雛形。

HDFS源于Google在2003年10月份發表的DFS——Google File System論文。傳統的檔案系統對海量資料的處理方式是将資料檔案直接存儲在一台計算機，也就是一整個檔案對應一台計算機。在早期的場景下，這樣做并不會存在什麼問題，但是随着資料量的不斷攀升，這樣單節點的存儲方式無疑會帶來一些問題，如：當儲存的檔案越來越多，計算機面臨存儲瓶頸時，就需要擴容；當面臨大檔案的上傳下載下傳，單節點的存儲會變得非常耗時。

為了解決傳統檔案系統遇到的存儲瓶頸問題，首先考慮的就是擴容,擴容有兩種形式,一種是縱向擴容，即增加磁盤和記憶體；另一種是橫向擴容,即通過增加伺服器數量，通過擴大規模達到分布式存儲的效果，這種存儲形式就是分布式檔案存儲的雛形，也就是HDFS所采用的存儲模式。

解決了分布式檔案系統的存儲瓶頸問題之後,還需要解決檔案上傳與下載下傳的效率問題，正常的解決辦法是将一個大的檔案切分成多個資料塊,将資料塊存儲在不同的計算機節點之上，使用并行上傳下載下傳的方式化整為零。具體來說，以300MB的檔案為例，先将檔案進行橫向的切分，切分成3塊，每塊大小100MB，然後将每個塊檔案存儲在不同計算機節點之上。

如此一來，原本一台伺服器要存儲300MB的檔案,此時每台伺服器隻需要存儲100MB的資料塊就完成了工作﹐當上傳下載下傳時，3個幾點并行工作，進而解決了上傳下載下傳的效率問題。但是檔案通過資料塊分别存儲在伺服器叢集中,那麼如何擷取一個完整的檔案呢?針對這個問題,就需要再考慮增加一台伺服器,專門用來記錄檔案被切割後的資料塊資訊以及資料塊的存儲位置資訊。

具體來說，可以在檔案存儲系統中增加一台伺服器作為名稱空間伺服器，也稱作為NameSpace伺服器，用于管理其他伺服器。NameSpace伺服器記錄着檔案被切分成多少個資料塊,這些資料塊分别存儲在哪台伺服器中,當用戶端通路NameSpace伺服器請求下載下傳資料檔案時,就能夠通過類似查找目錄的方式查找資料了。而這個伺服器官方命名它為NameNode。

通過前面的操作,看似解決了所有問題,但其實還有一個非常關鍵的問題需要處理,那就是當存儲資料塊的伺服器中突然有一台機器當機,就無法正常的擷取檔案了,這個問題被稱為單點故障。針對這個問題,可以采用備份的機制解決。也就是說，每個資料塊除了在自己的節點存在以外，還會在自己節點以外的另外兩個節點各儲存一個備份檔案，以三副本的方式存在于整個叢集之中。如此一來，任何一台儲存資料的節點當機，節點上的每一份資料塊在叢集中都還可以找到至少兩份資料進行恢複。如上所述，這樣儲存實際每個塊檔案的節點，官方命名它為DataNode。

這樣的分布式存儲、分布式上傳下載下傳和多副本機制就共同組成了最簡單的HDFS系統。

HDFS是一個易于擴充的分布式檔案系統,運作在成百上千台低成本的機器上。它與現有的分布式檔案系統有許多相似之處,都是用來存儲資料的系統工具,而差別在于 HDFS具有高度容錯能力,旨在部署在低成本機器上。HDFS提供對應用程式資料的高吞吐量通路,主要用于對海量檔案資訊進行存儲和管理,也就是解決大資料檔案如TB乃至PB級資料的存儲問題。