溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹Hadoop中HDFS架構是怎么樣的，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
HDFS 是 Hadoop 中存儲數據的基石，存儲著所有的數據，具有高可靠性，高容錯性，高可擴展性，高吞吐量等特征，能夠部署在大規模廉價的集群上，極大地降低了部署成本。有意思的是，其良好的架構特征使其能夠存儲海量的數據。
HDFS采用 Master/Slave 架構存儲數據，且支持 NameNode 的 HA。HDFS架構主要包含客戶端，NameNode，SecondaryNameNode 和 DataNode 四個重要組成部分，如圖所示：
（1）客戶端向NameNode發起請求，獲取元數據信息，這些元數據信息包括命名空間、塊映射信息及 DataNode 的位置信息等。
（2）NameNode 將元數據信息返回給客戶端。
（3）客戶端獲取到元數據信息后，到相應的 DataNode 上讀/寫數據
（4）相關聯的 DataNode 之間會相互復制數據，以達到 DataNode 副本數的要求
（5）DataNode 會定期向 NameNode 發送心跳信息，將自身節點的狀態信息報告給 NameNode。
（6）SecondaryNameNode 并不是 NameNode 的備份。SecondaryNameNode 會定期獲取 NameNode 上的 fsimage和 edits log 日志，并將二者進行合并，產生 fsimage.ckpt 推送給 NameNode。
NameNode 是整個 Hadooop 集群中至關重要的組件，它維護著整個 HDFS 樹，以及文件系統樹中所有的文件和文件路徑的元數據信息。這些元數據信息包括文件名，命令空間，文件屬性（文件生成的時間、文件的副本數、文件的權限）、文件數據塊、文件數據塊與所在 DataNode 之間的映射關系等。
一旦 NameNode 宕機或 NameNode 上的元數據信息損壞或丟失，基本上就會丟失 Hadoop 集群中存儲的所有數據，整個 Hadoop 集群也會隨之癱瘓。
在 Hadoop 運行的過程中， NameNode 的主要功能如下圖所示：
SecondaryNameNode 并不是 NameNode 的備份，在NameNode 發生故障時也不能立刻接管 NameNode 的工作。SecondaryNameNode 在 Hadoop 運行的過程中具有兩個作用：一個是備份數據鏡像，另一個是定期合并日志與鏡像，因此可以稱其為 Hadoop 的檢查點（checkpoint）。SecondaryNameNode 定期合并 NameNode 中的 fsimage 和 edits log，能夠防止 NameNode 重啟時把整個 fsimage 鏡像文件加載到內存，耗費過長的啟動時間。
SecondaryNameNode 的工作流程如圖所示：
SecondaryNameNode的工作流程如下：
（1）SecondaryNameNode 會通知 NameNode 生成新的 edits log 日志文件。
（2）NameNode 生成新的 edits log 日志文件，然后將新的日志信息寫到新生成的 edits log 日志文件中。
（3）SecondaryNameNode 復制 NameNode 上的 fsimage 鏡像和 edits log 日志文件，此時使用的是 http get 方式。
（4）SecondaryNameNode 將fsimage將鏡像文件加載到內存中，然后執行 edits log 日志文件中的操作，生成新的鏡像文件 fsimage.ckpt。
（5）SecondaryNameNode 將 fsimage.ckpt 文件發送給 NameNode，此時使用的是 http post 方式。
（6）NameNode 將 edits log 日志文件替換成新生成的 edits.log 日志文件，同樣將 fsimage文件替換成 SecondaryNameNode 發送過來的新的 fsimage 文件。
（7）NameNode 更新 fsimage 文件，將此次執行 checkpoint 的時間寫入 fstime 文件中。
經過 SecondaryNameNode 對 fsimage 鏡像文件和 edits log 日志文件的復制和合并操作之后，NameNode 中的 fsimage 鏡像文件就保存了最新的 checkpoint 的元數據信息， edits log 日志文件也會重新寫入數據，兩個文件中的數據不會變得很大。因此，當重啟 NameNode 時，不會耗費太長的啟動時間。
SecondaryNameNode 周期性地進行 checkpoint 操作需要滿足一定的前提條件，這些條件如下：
（1）edits log 日志文件的大小達到了一定的閾值，此時會對其進行合并操作。
（2）每隔一段時間進行 checkpoint 操作。
這些條件可以在core-site.xml文件中進行配置和調整，代碼如下所示：
<property> <name>fs.checkpoint.period</name> <value>3600</value></property><property> <name>fs.checkpoint.size</name> <value>67108864</value></property>
上述代碼配置了 checkpoint 發生的時間周期和 edits log日志文件的大小閾值，說明如下。
（1）fs.checkpoint.period：表示觸發 checkpoint發生的時間周期，這里配置的時間周期為 1 h。
（2）fs.checkpoint.size：表示 edits log 日志文件大小達到了多大的閾值時會發生 checkpoint操作，這里配置的 edits log大小閾值為 64 MB。
上述代碼中配置的 checkpoint操作發生的情況如下：
（1）如果 edits log 日志文件經過 1 h 未能達到 64 MB，但是滿足了 checkpoint發生的周期為 1 h 的條件，也會發生 checkpoint 操作。
（2）如果 edits log日志文件大小在 1 h 之內達到了 64MB，滿足了 checkpoint 發生的 edits log日志文件大小閾值的條件，則會發生 checkpoint操作。
注意：如果 NameNode 發生故障或 NameNode 上的元數據信息丟失或損壞導致 NameNode 無法啟動，此時就需要人工干預，將 NameNode 中的元數據狀態恢復到 SecondaryNameNode 中的元數據狀態。此時，如果 SecondaryNameNode 上的元數據信息與 NameNode 宕機時的元數據信息不同步，則或多或少地會導致 Hadoop 集群中丟失一部分數據。出于此原因，應盡量避免將 NameNode 和 SecondaryNameNode 部署在同一臺服務器上。
DataNode 是真正存儲數據的節點，這些數據以數據塊的形式存儲在 DataNode 上。一個數據塊包含兩個文件：一個是存儲數據本身的文件，另一個是存儲元數據的文件（這些元數據主要包括數據塊的長度、數據塊的檢驗和、時間戳）。
DataNode 運行時的工作機制如圖所示：
如圖所示，DataNode 運行時的工作機制如下：
（1）DataNode啟動之后，向 NameNode 注冊。
（2）NameNode 返回注冊成功的消息給 DataNode。
（3）DataNode 收到 NameNode 返回的注冊成功的信息之后，會周期性地向 NameNode 上報當前 DataNode 的所有塊信息，默認發送所有數據塊的時間周期是 1h。
（4）DataNode 周期性地向NameNode 發送心跳信息；NameNode 收到 DataNode 發來的心跳信息后，會將DataNode 需要執行的命令放入到 心跳信息的 返回數據中，返回給 DataNode。DataNode 向 NameNode 發送心跳信息的默認時間周期是 3s。
（5）NameNode 超過一定的時間沒有收到 DataNode 發來的心跳信息，則 NameNode 會認為對應的 DataNode 不可用。默認的超時時間是 10 min。
（6）在存儲上相互關聯的 DataNode 會同步數據塊，以達到數據副本數的要求。
當 DataNode 發生故障導致 DataNode 無法與 NameNode 通信時，NameNode 不會立即認為 DataNode 已經 “死亡”。要經過一段短暫的超時時長后才會認為 DataNode 已經 “死亡”。HDFS 中默認的超時時長為 10 min + 30 s，可以用如下公式來表示這個超時時長：
timeout = 2 * dfs.namenode.heartbeat.recheck-interval +10 * dfs.heartbeat.interval
其中，各參數的含義如下：
（1）timeout：超時時長。
（2）dfs.namenode.heartbeat.recheck-interval：檢查過期 DataNode 的時間間隔，與 dfs.heartbeat.interval 結合使用，默認的單位是 ms，默認時間是 5 min。
（3）dfs.heartbeat.interval：檢測數據節點的時間間隔，默認的單位為 s，默認的時間是 3 s。
所以，可以得出 DataNode 的默認超時時長為 630s，如下所示：
timeout = 2 * 5 * 60 + 10 * 3 = 630s
DataNode 的超時時長也可以在 hdfs-site.xml文件中進行配置，代碼如下所示：
<property> <name>dfs.namenode.heartbeat.recheck-interval</name> <value>3000</value></property><property> <name>dfs.heartbeat.interval</name> <value>2</value></property>
根據上面的公式可以得出，在配置文件中配置的超時時長為：
timeout = 2 * 3000 / 1000 + 10 * 2 = 26s
當 DataNode 被 NameNode 判定為 “死亡”時，HDFS 就會馬上自動進行數據塊的容錯復制。此時，當被 NameNode 判定為 “死亡” 的 DataNode 重新加入集群中時，如果其存儲的數據塊并沒有損壞，就會造成 HDFS 上某些數據塊的備份數超過系統配置的備份數目。
HDFS上刪除多余的數據塊需要的時間長短和數據塊報告的時間間隔有關。該參數可以在 hdfs-site.xml文件中進行配置，代碼如下所示：
<property> <name>dfs.blockreport.intervalMsec</name> <value>21600000</value> <description>Determines block reporting interval in milliseconds.</description></property>
數據塊報告的時間間隔默認為 21600000ms，即 6h，可以通過調整此參數的大小來調整數據塊報告的時間間隔。
以上是“Hadoop中HDFS架構是怎么樣的”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
