分佈式文件系統-HDFS

HDFS

   Hadoop的核心就是HDFS與MapReduce。那麼HDFS又是基於GFS的設計理念搞出來的。

   HDFS全稱是Hadoop Distributed System。HDFS是爲以流的方式存取大文件而設計的。適用於幾百MB，GB以及TB，並寫一次讀屢次的場合。而對於低延時數據訪問、大量小文件、同時寫和任意的文件修改，則並非十分適合。

 優勢：

      1）適合存儲很是大的文件

      2）適合流式數據讀取，即適合「只寫一次，讀屢次」的數據處理模式

      3）適合部署在廉價的機器上

缺點：

     1）不適合存儲大量的小文件，由於受Namenode內存大小限制

     2）不適合實時數據讀取，高吞吐量和實時性是相悖的，HDFS選擇前者

     3）不適合須要常常修改數據的場景

   數據塊：

     每一個磁盤都有默認的數據塊大小，通常就是521字節。這是磁盤進行數據讀寫的最小單位。HDFS一樣也有塊（block）的概念，可是大得多，有64MB。與單一磁盤上的文件系統同樣，HDFS上的文件也被劃分爲塊大小的多個分塊。可是仍是有所不一樣，好比HDFS中小於一個塊大小的文件不會佔據整個塊的空間。

    對分佈式文件系統中的快進行抽象的好處：

    1）一個文件的大小可能會大於網絡中任意一個磁盤的容量，文件的全部塊並不須要存儲在同一個磁盤上，所以能夠利用集羣上的任意一個磁盤進行存儲，可是對於HDFS來講，它是存儲了一個文件。

        （這不就正是咱們要的效果嗎） 

    2）以抽象塊爲存儲單元，簡化了設計。還方便塊的備份。

 

 

   

 

         HDFS的架構如上圖所示，整體上採用了Master/Slave的架構，主要有如下4個部分組成：

       一、Client

            客戶端，就是咱們經過調用接口實現的代碼。

       二、NameNode

           整個HDFS集羣只有一個NameNode，它存儲整個集羣文件分別的元數據信息。這些信息以fsimage和editlog兩個文件存儲在本地磁盤，Client經過這些元數據信息能夠找到相應的文件。此外，NameNode還      負責監控DataNode的健康狀況，一旦發現DataNode異常，就將其踢出，並拷貝其上數據至其它DataNode。

      三、Secondary NameNode

          Secondary NameNode負責按期合併NameNode的fsimage和editlog。這裏特別注意，它不是NameNode的熱備，因此NameNode依然是Single Point of Failure。它存在的主要目的是爲了分擔一部分             NameNode的工做（特別是消耗內存的工做，由於內存資源對NameNode來講很是珍貴）。

      四、DataNode

           DataNode負責數據的實際存儲。當一個文件上傳至HDFS集羣時，它以Block爲基本單位分佈在各個DataNode中，同時，爲了保證數據的可靠性，每一個Block會同時寫入多個DataNode中（默認爲3）   

 

      那麼文件如何存儲的呢？

     要存儲的文件會分紅不少塊，存到Datanode裏。分塊的原則：除了最後一個數據塊，其它數據塊的大小相同，通常爲64MB or 128MB。 每一個數據塊有副本（通常爲3）：副本多了浪費空間。 

    副本存儲：在大多數狀況下，副本系數是3，HDFS的存放策略是將一個副本存放在本地機架的節點上，一個副本放在同一機架的另外一個節點上，。

    HDFS通訊協議 

     全部的 HDFS 通信協議都是構建在 TCP/IP 協議上。客戶端經過一個可 配置的端口鏈接到 Namenode ， 經過 ClientProtocol 與 Namenode 交互。而 Datanode 是使用 DatanodeProtocol 與 Namenode 交互。再設計上， DataNode 經過週期性的向 NameNode 發送心跳和數據塊來保持和 NameNode 的通訊，數據塊報告的信息包括數據塊的屬性，即數據塊屬於哪 個文件，數據塊 ID ，修改時間等， NameNode 的 DataNode 和數據塊的映射 關係就是經過系統啓動時 DataNode 的數據塊報告創建的。從 ClientProtocol 和 Datanodeprotocol 抽象出一個遠程調用 ( RPC ）， 在設計上， Namenode 不會主動發起 RPC ， 而是是響應來自客戶端和 Datanode 的 RPC 請求。 
    （這個在咱們進行hadoop文件配置的時候就能夠感覺到，都是經過一個Ip地址加上一個端口號來訪問對方的）

      文件讀取的過程以下：

1. 使用HDFS提供的客戶端開發庫Client，向遠程的Namenode發起RPC請求；
2. Namenode會視狀況返回文件的部分或者所有block列表，對於每一個block，Namenode都會返回有該block拷貝的DataNode地址；
3. 客戶端開發庫Client會選取離客戶端最接近的DataNode來讀取block；若是客戶端自己就是DataNode,那麼將從本地直接獲取數據.
4. 讀取完當前block的數據後，關閉與當前的DataNode鏈接，併爲讀取下一個block尋找最佳的DataNode；
5. 當讀完列表的block後，且文件讀取尚未結束，客戶端開發庫會繼續向Namenode獲取下一批的block列表。
6. 讀取完一個block都會進行checksum驗證，若是讀取datanode時出現錯誤，客戶端會通知Namenode，而後再從下一個擁有該block拷貝的datanode繼續讀。

     寫入文件的過程以下：

1. 使用HDFS提供的客戶端開發庫Client，向遠程的Namenode發起RPC請求；
2. Namenode會檢查要建立的文件是否已經存在，建立者是否有權限進行操做，成功則會爲文件建立一個記錄，不然會讓客戶端拋出異常；
3. 當 客戶端開始寫入文件的時候，開發庫會將文件切分紅多個packets，並在內部以數據隊列"data queue"的形式管理這些packets，並向Namenode申請新的blocks，獲取用來存儲replicas的合適的datanodes列表， 列表的大小根據在Namenode中對replication的設置而定。
4. 開始以pipeline（管道）的形式將packet寫入所 有的replicas中。開發庫把packet以流的方式寫入第一個datanode，該datanode把該packet存儲以後，再將其傳遞給在此 pipeline中的下一個datanode，直到最後一個datanode，這種寫數據的方式呈流水線的形式。
5. 最後一個datanode成功存儲以後會返回一個ack packet，在pipeline裏傳遞至客戶端，在客戶端的開發庫內部維護着"ack queue"，成功收到datanode返回的ack packet後會從"ack queue"移除相應的packet。
6. 如 果傳輸過程當中，有某個datanode出現了故障，那麼當前的pipeline會被關閉，出現故障的datanode會從當前的pipeline中移除， 剩餘的block會繼續剩下的datanode中繼續以pipeline的形式傳輸，同時Namenode會分配一個新的datanode，保持 replicas設定的數量。