分佈式文件系統--GFS

分佈式文件系統

 

     分佈式文件系統：當數據集的大小超過一臺獨立物理計算機的存儲能力時，就有必要對它進行分區（partition）並存儲到若干臺單獨的計算機上。管理網絡中誇多臺計算機存儲的文件系統。這種系統構架於網絡之上，確定會引入網絡編程的複雜性，所以它比普通的磁盤文件系統更爲複雜。

     咱們首先來簡單的說明一下這個分佈式，咱們都知道如今要存儲的數據量愈來愈大，可是一臺電腦的存儲能力是有限的，儘管咱們能夠經過提升某臺電腦的存儲能力來解決這個問題，可是這是沒法根本解決這個問題，因此咱們經過不少不少臺廉價的電腦來分佈式存儲這些數據。簡單說就是把要存的文件分割成一份一份存到許多臺電腦上。

     Google File System：是由google開發並設計的一個面向大規模數據處理的一個分佈式文件系統。

 

     爲了知足Google迅速增加的數據處理需求，Google設計並實現了Google文件系統。它是有幾百甚至幾千臺普通的廉價設備組裝的存儲機器。如下是一些設計思路。

     1）咱們知道有這麼多機器，那麼這些設備中的某些機器出現故障是很常見的事情，因此在GFS要集成持續的監控、錯誤偵測、災難冗 餘以及自動恢復的機制。

     2）咱們要存的數據大小是很大，因此要是按照以往的存儲文件塊大小，那麼就要管理數億個KB大小的小文件，這是很不合理的，因此在這個系統裏面他們定義一個文件塊的大小是64M。

     3）絕大部分的大數據都是採用在文件尾部追加數據的，而不是覆蓋數據的。對大文件的隨機寫入基本上是不存在的。

     4）應用程序和文件系統API協同設計，簡化對GFS的要求。

      GFS架構設計：

       GFS採用主/從模式，一個GFS包括一個master服務器r和多個chunk服務器。固然這裏的一個master是指邏輯上的一個，物理上能夠有多個（就是可能有兩臺，一臺用於以防萬一，一臺用於正常的數據管理）。而且咱們能夠把客戶端以及chunk服務器放在同一臺機器上。

                                                         

       

                        GFS Master（即NameNode）：單獨節點，管理GFS全部元數據（如名字空間、訪問控制權限等）

                        GFS ChunkServer（即DataNode）：數據存儲節點，文件被分割爲固定大小的（block）Chunk，每一個Chunk被惟一標識，默認狀況下，（block）Chunk存儲爲3個副本。

                        GFS Client：實現GFS的API接口函數（不是POSIX標準，由於API只需在用戶空間調用）

      咱們先來講明一下數據是如何存儲的。咱們上面說過大數據會被切分，而且單位是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塊較大尺寸優勢：（是一個關鍵的設計參數，默認爲64MB。每一個block都以普通Linux文件存儲在ChunkServer上）

           （1）減小Clinet與Master的通訊

           （2）減小Master的元數據的存儲

           （3）Client能夠對文件塊進行屢次操做，減小I/O壓力

      三、元數據

         主要包括：命名空間、文件和Block的映射關係（文件包括哪些Block）、每一個Block副本的存放文章信息。

         存儲：元數據存儲在Matser服務器的內存中，這樣能夠快速查找，性能好，可是因爲Master內存有限制。

         * 命名空間及文件和Chunk的映射關係，均以記錄變動日誌的方式落地爲系統日誌文件，並複製到遠程Master備機上。

         *Block副本的位置信息爲Master週期性向各個ChunkServer輪詢得到 => 沒有落地，避免了ChunkServer變動時的Master和ChunkServer的數據同步問題

         * 操做日誌記錄了關鍵元數據變動歷史，對Master的容災很是重要，故只有在元數據變動持久化到日誌後，纔會對Client可見。爲了不操做日誌過長，GFS按期會對當前操做日誌作一次Checkpoint，以壓縮                B+樹形式存儲爲一個CheckPoint文件。

         * 故Master的恢復只需最新的CheckPoint文件和後續的操做日誌。

      四、存儲訪問流程：首先，客戶端把文件名和程序指定的字節偏移，根據固定的block大小，轉換成文件的block索 引。而後，它把文件名和block索引起送給Master節點。Master節點將相應的block標識和副本的位置信息發還給客戶端。客戶端用文件名和 block索引做爲key緩存這些信息。以後客戶端發送請求到其中的一個副本處，通常會選擇最近的。請求信息包含了block的標識和字節範圍。在對這個block的後續讀取操做中， 客戶端沒必要再和Master節點通信了，除非緩存的元數據信息過時或者文件被從新打開。實際上，客戶端一般會在一次請求中查詢多個block信息。 

      下面簡單解釋下在單點Master下一次簡單的讀取過程：

    （1）客戶端向Master發送請求，請求信息爲（文件名，塊索引）

    （2）Master使用心跳信息監控塊服務器的狀態，並向其發送指令。

    （3）塊服務器須要週期性的返回本身的狀態給Master，以確保可以接收Master的請求。

    （4）Master將（塊句柄，塊位置）這一信息返回給客戶端

    （5）客戶端使用文件名和塊索引做爲Key進行緩存信息。而後，客戶端發送請求到其中的一個副本中（一般爲最近的），該請求包括（塊句柄，字節範圍）。對這個塊的後續操做，客戶端無需再和Master進行通訊，除非緩存信息過時或者文件被從新打開。

    （6）塊服務器將所需的塊數據發送給客戶端。

                                 

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

        

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

               http://www.open-open.com/lib/view/open1386577681689.html