<strong>HDFS簡介
HDFS是Hadoop的三大組件之一，用馬士兵老師的話來說他就是一塊分餘展（分佈式，冗餘數據，可擴展）的大硬盤。它以數據節點的方式來存儲數據，從邏輯上來說他分為NameNode和DataNode，這些節點都是用來存放數據的。其中NameNode中存放的是元數據，也就是一些文件與數據塊的映射以及數據塊與DataNode之間的映射（類比於操作系統中的目錄文件），而真實的數據放在DataNode中。其中DataNode可以很方便的進行橫向擴展這樣保證了大量數據的存儲，下面詳細介紹他們。
<strong>NameNode
NameNode主要負責元數據的存儲以及與處理用戶的請求。
<strong>元數據
主要是一些映射信息主要包括：文件與塊的映射，塊與DataNode之間的映射。
<strong>塊
這裡提到了塊，在HDFS中存放一個大的文件是需要分塊存儲的。在2.X的版本中塊的大小默認為128M。如果一個文件大於128M那麼就會被分為多塊。分塊有諸多好處比如說切了塊文件的存放可以很靈活的進行存放這是靈活數據冗餘的基礎，然後切塊之後文件系統只需要管理塊而無需管理具體的文件，最後使得複製較為輕鬆把複製一個超大文件改為複製幾個小文件的組合。
以下為一個元數據的格式：
例如： /test/a.log,3,{b1,b2},[{b1:[h0,h1,h3]},{b2:[h0,h2,h4]}]
我們可以看到一條元數據包括文件名，複本數量（備份數量），文件分塊，以及每個分塊具體在哪個DN（DataNode）上。有了這些我們就可以知道這些文件的具體位置了。
<strong>NameNode中的核心文件
<strong>NameNode中的核心文件包括：
<strong>Fsimage：這是元數據的鏡像文件，它存在硬盤上它並不是元數據的實時同步。只有在滿足條件的時候才進行數據同步。它存在的意義就是為了崩潰恢復。
這裡的條件是指：默認情況下3600秒同步一次，當edits達到64M同步一次，Hadoop重啟的時候同步一次。
<strong>Edits：日誌文件，每當客戶端操作一次hdfs就會先在日誌文件中留下操作日誌然後才在內存中生成相應的元數據。這裡有點蒙內存什麼鬼？
原來在操作hdfs的時候NameNode會將元數據保留在內存中一份這樣的話會大大提高請求的應答效率。而上述的Fsimage和Edits都是硬盤層面的。
<strong>Fstime：記載checkpoint的時間，也就是上一次我的fsimage所更新的時間，這樣的話就能夠計算出什麼時間應該進行下一次更新。
<strong>SecondaryNameNode
上面我們提到了我們的Fsimage文件會在一定的條件下將元數據同步一次，由於NameNode在生產環境中的負載量很大，所以這個工作一般會交給SecondaryNameNode來執行，當然我們希望SecondaryNameNode會有一臺獨立的主機。同步數據的流程如下圖所示：
①由於同步數據會用到edits與fsimage兩個文件，所以先將這兩個文件通過網絡複製到SSN上面。這時SSN將兩個文件load到內存中進行合併。
②考慮到這時可能有客戶端來訪問所以在edits拷貝到SSN的時候也會在NN上面創建一個edits.new的文件用來寫入這一段時間的日誌。
③SNN將文件合併完畢然後將合併後的文件fsimage.ckpt通過網絡賦值到NN上，然後fsimage.ckpt重命名為fsimage同時edits.new重命名為edits。
④同步完成
從上面我們不難發現SNN並不是為了NN的備份而產生的，只是為了同步數據。但是它有一個副作用就是能夠幫助NN在崩潰的時候恢復部分數據。
<strong>DataNode
數據節點專門用來存放實際的數據。所有的文件在DN上都以塊來存儲。 這裡面有一個核心的概念就是心跳機制。他指的是DN會每隔一段時間（默認3秒）就會給NN發送一個數據包（心跳報告）。它裡面包含兩種信息即它的存活狀態以及他裡面的數據信息。NN會根據心跳報告來更新自己元數據的信息。同時NN也會回送一些消息這樣DN就會根據這些消息來增加刪除移動節點上面的數據。如果一個DN在10分鐘之內沒有發送心跳報告的話那麼NN就會認為當前的DN已經lost，並且將當前節點上丟失的數據補充到其它節點上。從中我們也可以看出NN並沒有主動的管理DN而是DN主動去請求NN的。
<strong>Block複本放置策略與機架感知
<strong>Block的放置既要保證能夠崩潰恢復又要保證數據傳輸的效率，針對這兩個不同的要求會有不同的放置策略。
①第一個Block會放在內存佔用不大而且CPU佔用率不高的任意一個DN上面。
②第二個就要放在與第一個不同的機架上面，為了崩潰恢復。
③第三個就放在本機架就ok這樣就滿足了以上兩個要求。
<strong>機架感知策略
Hadoop對於數據放在哪一個機架是不知道的，也就是他不知道slave在哪裡。這就需要管理員人為的配置機架與slave的對應關係。具體的：
要將hadoop機架感知的功能啟用，配置非常簡單，在namenode所在機器的hadoop-site.xml配置文件中配置一個選項：
<strong>客戶端訪問HDFS流程的具體說明
<strong>客戶端讀取HDFS上的文件
①客戶端對NN發起RPC請求，告訴自己想要請求的資源。
②NN會根據客戶端的情況返回給用戶數據包（也就是元數據）包括文件與block的映射以及block與DN的映射關係。需要注意的是如果請求的數據過多的話那麼NN一次性只會給客戶端發送一部分元數據。
③客戶端拿到元數據之後會就近原則的去DN上找數據。有一種特殊情況就是如果當前的客戶端正好是一個DN的話而且請求的數據正好在自己的主機上的時候此時客戶端就會直接讀取本機的數據。
③每讀取完一個塊的時候會有一次checksum操作檢查，讀取到的數據與從NN哪裡拿到的元數據的信息是否一致，如果不一致的話那麼就會先會告訴NN這個塊已經損壞讓NN刪除該塊而自己再去其它的DN上讀取該數據塊。
④如果讀完這一批的數據塊客戶端會再次詢問有沒有其他的數據塊，如果有那麼就再接收一批元數據信息進行新一輪的讀取直到全部的數據塊都讀取完畢。
⑤當所有的數據塊都讀取完畢的時候，客戶端會告知NN全部讀完讓它關閉不在使用的資源。
<strong>客戶端上傳文件到HDFS上
①客戶端首先向NN發起一個RPC請求。
②NN會根據客戶端的請求做兩個判斷，要上傳的文件是否已經存在，上傳者是否擁有上傳的權限。都滿足則會為上傳文件創建一個記錄，否則拋出異常。
③當客戶端開始上傳文件的時候首先會將文件切分成為一個個的package從而構成packages。Packages構成了一個data queue隊列，客戶端會按照找個隊列的順序來依次寫出到HDFS上。
④當package寫入一個節點失敗之後客戶端會通知NN刪除這個殘缺的數據，然後再繼續寫入當前package到其它完好的DN上。
⑤當一個package寫入完成之後會使用pipeline的技術將該數據複製到其它的DN上作為複本。在一個節點完全成功之後DN會給客戶端回覆一個ack packet。此時在客戶端的ack queue中增加當前這條信息，同時在data queue中刪除當前傳輸成功的package轉向下一個package的傳輸。
⑥在⑤的過程中如果出現了DN的損壞那麼這個DN就會在管道中移出。NN會再次分配一個DN保持冗餘節點的一致。
⑦在全部上傳完成之後客戶端會告訴NN全部傳輸完畢然後NN會關閉其它不在使用的資源。
<strong>客戶端刪除HDFS上的文件
①客戶端向NN發起請求然後，NN判斷文件的狀況與權限。
②如果滿足條件NN首先在日誌中刪除這個文件，然後在內存中刪除這個文件。需要注意的是當前的問價依然存在於DN上，並沒有真正的刪除。
③此後DN會向NN發起心跳報告進而與NN中的元數據做比較，這時候會發現NN中的元數據中某文件已經被刪除，所以在等待一段時間之後會刪除這個刪除的文件。
<strong>安全模式
Hadoop剛剛啟動的時候由於會觸發fsimage與edits的整合過程以及將edits中的數據輸入到內存中所以暫時不受理用戶的請求即用戶已經進入了安全模式。這時namenode會收集datanode的報告與元數據進行比對當數據塊達到最小複本以上是會被認為是安全的，再等待一段時間之後安全模式會自動解除。
閱讀更多 擺技 的文章
