hadoop之hdfs及其工作原理

（一）hdfs產生的背景

　　隨著數據量的不斷增大和增長速度的不斷加快，一臺機器上已經容納不下，因此就需要放到更多的機器中，但這樣做不方便維護和管理，因此需要一種文件系統進行統一管理；另一方面，數據量之大，勢必會對處理器性能提出了更大的要求，單個處理器性能的提升成本極高且已到達技術瓶頸（目前來看），因此縱向擴展的這條道路已經閉塞，只能考慮橫向擴展，添加更多的機器。就在這種背景下，HDFS應運而生，它是一種分布式文件系統，它由多臺主機的進程系統完成某個應用，當然每臺主機各司其職（這個會在下文中進行介紹）。

（二）hdfs的優缺點

　　優點：

　　　　（1）適合大數據的處理

　　　　　　數據規模：能夠處理能夠處理GB、TB甚至PB級別的數據

　　　　　　文件規模：能夠處理百萬規模以上的文件數量

　　　　（2）低成本

　　　　　　hdfs可搭建在普通廉價機器中，成本較低，追隨世界潮流，實現去IOE（IBM的小型機、Oracle的數據庫服務器、EMC的共享存儲設備 ）。

　　　　（3）高容錯性

　　　　　　廉價機器所帶來的負面情況便是就是機器的故障率較高，hdfs通過增加副本的形式來提高容錯性，某一副本丟失可根據其他副本自動恢復。

　　缺點：

　　　　（1）不適合低延時的數據訪問，比如毫秒級的數據訪問它是做不到的。

　　　　（2）不適合對大量小文件進行存儲

　　　　　　存儲大量的小文件，namenode中會存儲每個文件的元數據信息（約150k），占用大量空間，畢竟namenode是有限的。

　　　　　　小文件的存儲的尋址時間遠大於它的讀取時間，違背了hdfs的設計原則。

　　　　（3）不支持並發寫入和隨機修改

　　　　　　一個文件不支持多個線程同時寫，僅支持文件的追加（append），不支文件的隨機修改。

（三）hdfs的架構

　　hdfs的架構主要由四部分組成：

　　（1）hdfs Client

　　　　客戶端可通過一些命令來訪問hdfs，可訪問namenode獲得文件的元數據信息，與datanode交互對文件進行讀取。

　　　　客戶端負責文件的切分，在文件上傳時，它將文件切分成block進行存儲

　　（2）namenode

　　　　namenode就是master，它用於存儲文件的元數據信息，包括文件的類型、大小、路徑、權限等。它是一個管理者，管理數據塊的映射信息。

　　　　namenode用於處理客戶端的讀寫請求。

　　（3）datanode

　　　　datanode就是slaves，namenode處理請求，下達命令，datanode執行實際的操作。

　　　　datanode中以block為單位存儲了真實的數據。

　　（4）seconderaynamenode

　　　　secondarynamenode並未在上述架構中展示出來，它是namonode的輔助節點。在namenode掛掉的情況下，它並不能立即代替namenode提供服務，僅能夠輔助namenode的恢復

　　　　定期合成Fsimage和Edits文件並推送給namenode（這兩個文件將在後續進行介紹）。

（四）hdfs文件塊（block）的大小

　　hdfs是以block為單位進行數據的存儲，hadoop2.X中block的默認大小為128M，默認副本數為3，當然這兩個值可通過配置文件進行設置（dfs.replicationdfs.blocksize）。

　 hdfs的block的大小要比磁盤要大，這是為了最小化尋址時間。如果block設置的足夠大，定位這個塊的時間要遠小於數據的傳輸時間。這樣以來，文件的傳輸時間就取決於磁盤的傳輸速率。

　　目前情況下，磁盤的選址時間在10ms左右，為了使磁盤的尋址時間為傳輸時間的1%，需要把傳輸時間限制在1s左右，而目前市場的磁盤的傳輸效率平均為100M/s，因此塊的大小設置為100M左右，之所以設置為128M，筆者認為處於兩方面考慮，其一，磁盤的傳輸效率會隨著技術的提升而增加，其二，符合計算機領域的美感。

（五）NameNode和SeconderayNamenode的工作機制

　　NameNode對元數據進行管理，它管理三種元數據：

　　1）內存元數據（完整的metadata）

　　2）準完整的元數據鏡像文件fsimage

　　3）用於銜接內存元數據和持久化元數據鏡像的編輯日誌edits文件

　　首先我們來看一下實際存在的fsimage文件和edits文件中存儲的什麽內容？

　　由於fsimage文件和edits文件時經過序列化的文件，因此無法直接查看，可通過下列命令將文件轉換為xml格式進行查看：

　　　　hdfs oie/ove -i fsimage/edits -out -p xml

　　fsimage文件中存儲的是文件和文件夾元數據的目錄樹結構；edits存儲的是寫操作的步驟（具體結構不在這裏展示）。

　　了解了元數據的存儲位置後，下面我們來介紹一下Namenode是如何管理元數據的：

　　1）Namenode在啟動時，首相將最近的fsimage鏡像文件加載入內存，然後將edtis_progress文件實例化為新的edtis文件，並將該edits文件加載入內存，這樣內存中就擁有了完整的元數據，可供客戶端進行相關操作。

　　2）客戶端向Namenode提出更新元數據的請求，Namenode首先更新edtis文件，記錄日誌，然後對內存中的元數據進行增刪改。

　　我們了解到namenode在每次啟動時都滾動了edits文件，那麽fsimage文件是如何產生，或者說是什麽時候產生的？這就要看一下另外一個節點SecondorayNamenode是如何工作的。

　　SeconderayNamenode：通過配置文件設置到一定時間或者一定情況就會出發一個叫做檢查點(checkpoint)的東西，此時就會對namenode的fsimage和edits進行滾動和合成。默認出發檢查點的條件有兩個：時間：3600s=1h；文件大小：edits中的數據存滿（操作次數1000000）。具體SeconderayNamenode的滾動流程如下：

　　1）SeconderayNamenode通知Namenode將edits文件進行滾動

　　2）SeconderayNamenode將namenode中的edits文件和fsimage文件通過http GET發送到自己的文件夾下

　　3）SeconderayNamenode將edits文件和fsimage文件在內存中進行融合生成新的fsimage.ckp文件

　　4）SeconderayNamenode將融合後的檢查點文件傳給namenode (http post)

　　5）Namenode重命名融合後的檢查點文件。

　　下圖可供參考（某機構所盜）：

（六）DataNode的工作機制

　　1）一個數據塊在 datanode 上以文件形式存儲在磁盤上，包括兩個文件，一個是數據本身，一個是元數據包括數據塊的長度，塊數據的校驗和，以及時間戳。
　　2）DataNode 啟動後向 namenode 註冊，通過後，周期性（1 小時）的向 namenode 上報所有的塊信息。
　　3）心跳是每 3 秒一次，心跳返回結果帶有 namenode 給該 datanode 的命令如復制塊數據到另一臺機器，或刪除某個數據塊。如果超過 10 分鐘沒有收到某個 datanode 的心跳，則認為該節點不可用。
　　4）集群運行中可以安全加入和退出一些機器

hadoop之hdfs及其工作原理