Distributed File System--GFS

標籤：style   blog   http   使用   strong   檔案   資料   ar   

Distributed File System

     Google File System：是由google開發並設計的一個面向大規模資料處理的一個Distributed File System。

     我們首先來簡單的說明一下這個分布式，我們都知道現在要儲存的資料量越來越大，但是一台電腦的儲存能力是有限的，儘管我們可以通過提高某台電腦的儲存能力來解決這個問題，但是這是無法根本解決這個問題，所以我們通過很多很多台廉價的電腦來分布式儲存這些資料。簡單說就是把要存的檔案分割成一份一份存到許多台電腦上。

     為了滿足Google迅速增長的資料處理需求，Google設計並實現了Google檔案系統。它是有幾百甚至幾千台普通的廉價裝置群組裝的儲存機器。以下是一些介紹說明。

     1）我們知道有這麼多機器，那麼這些裝置中的某些機器出現故障是很常見的事情，所以在GFS整合了持續的監控、錯誤偵測、災難冗 餘以及自動回復的機制。

     2）我們要存的資料大小是很大，所以要是按照以往的隱藏檔塊大小，那麼就要管理數億個KB大小的小檔案，這是很不合理的，所以在這個系統裡面他們定義一個檔案塊的大小是64M。

     3）絕大部分的大資料都是採用在檔案尾部追加資料的，而不是覆蓋資料的。對大檔案的隨機寫入基本上是不存在的。

     架構設計：GFS採用主/從模式，一個GFS包括一個master伺服器r和多個chunk伺服器。當然這裡的一個master是指邏輯上的一個，物理上可以有多個（就是可能有兩台，一台用於以防萬一，一台用於正常的資料管理）。並且我們可以把用戶端以及chunk伺服器放在同一台機器上。

                                                         

        我們先來說明一下資料是如何儲存的。我們上面說過大資料會被切分，並且單位是64M。所以在GFS中，儲存的檔案會被切分成固定大小的block，每當一個block被建立的時候都會由master為它分配一個全球固定的標識。chunk伺服器把block以linux檔案儲存體的形式儲存在本地系統。為了可靠性，每塊block可能會複製成多份存放在不同的機器節點上。並且master伺服器儲存著檔案和block之間的位置映射已經其他一些中繼資料資訊。

       master（就是在hadoop裡面的namenode）：

       master管理者所有檔案的中繼資料，比如說名字空間，block的映射位置等等。Master節點使用心跳資訊周期地和每個Chunk伺服器通訊，發送指令到各個Chunk伺服器並接收Chunk伺服器的狀態資訊。我們知道master是單一節點的（邏輯上）。這個是可以大大簡化系統的設計。單一的master可以通過全域資訊精確的定位每個block在哪個chunk伺服器上以及進行複製決策。由於只有一台master，所以我們要減少對master的讀寫操作，避免master成為系統的瓶頸。而且master的中繼資料都是儲存在記憶體當中的，這樣速度處理快，但是也導致了儲存的資料是有限制的。

       要注意的是，用戶端對資料的讀寫不是在master上，而是通過master擷取block在chunk的位置資訊，直接和chunk伺服器進行資料互動讀寫的。我們說master是邏輯上只有一個節點，物理可能有兩個。就行hadoop裡面的hdfs一樣，有一個namenode和secondarynamenode。另外一個正常情況下不去用，當master伺服器宕機了，它就體現價值了。有點映像的感覺，當然它還有其他好多功能。

       Chunk（就是hadoop裡面datanode）：這個才是用於儲存資料的機器，檔案大小為64MB，這個尺寸遠遠大於一般檔案系統的Block size。每個block的副本都以普通Linux檔案的形式儲存在Chunk伺服器上。Master伺服器並不儲存持久化儲存哪個Chunk伺服器存有指定block的副本的資訊。Master伺服器只是在啟動的時候輪詢Chunk伺服器以擷取這些資訊。Master伺服器能夠保證它持有的資訊始終是最新的，因為它控制了所有的block位置的分配，而且通過周期性的心跳資訊監控 Chunk伺服器的狀態。

       流程：首先，用戶端把檔案名稱和程式指定的位元組位移，根據固定的block大小，轉換成檔案的block索 引。然後，它把檔案名稱和block索引發送給Master節點。Master節點將相應的block標識和副本的位置資訊發還給用戶端。用戶端用檔案名稱和 block索引作為key緩衝這些資訊。之後用戶端發送請求到其中的一個副本處，一般會選擇最近的。請求資訊包含了block的標識和位元組範圍。在對這個block的後續讀取操作中， 用戶端不必再和Master節點通訊了，除非緩衝的中繼資料資訊到期或者檔案被重新開啟。實際上，用戶端通常會在一次請求中查詢多個block資訊。

       hadoop是的hdfs是基於GFS設計實現的。因此它們的原理是一樣。現在hadoop到處都是，所以對於GFS就總結這些，具體的介紹留著在hadoop的HDFS中說明。

        

       參考：http://www.open-open.com/lib/view/open1328763454608.html