目錄
HDFS(Hadoop Distributed File System)是Hadoop核心組成之一，是分佈式計算中數據存儲管理的基礎，被設計成適合運行在通用硬件上的分佈式文件系統。HDFS架構中有兩類節點，一類是NameNode，又叫“元數據節點”，另一類是DataNode，又叫“數據節點”，分別執行Master和Worker的具體任務。HDFS是一個(Master/Slave)體系結構，“一次寫入，多次讀取”。HDFS的設計思想：分而治之—將大文件、大批量文件分佈式存放在大量獨立的機器上。
一、HDFS的優缺點
（1）優點
- 高容錯性。數據保存多個副本，通過增加副本的形式提高容錯性，某個副本丟失後，它可以通過其它副本自動恢復。
- 適合大批量數據處理。處理達到GB、TB，甚至PB級別的數據，處理百萬規模以上的文件數量，處理10K節點的規模。
- 流式文件訪問。一次寫入多次讀取，文件一旦寫入不能修改，只能追加，保證數據一致性。
- 可構建在廉價機器上。通過多副本機制提高可靠性，提供容錯和恢復機制。
（2）缺點
不適用HDFS的場景：
- 低延時數據訪問。做不到毫秒級存儲數據，但是適合高吞吐率(某一時間內寫入大量的數據)的場景。
- 小文件存儲。存儲大量小文件會佔用NameNode大量的內存來存儲文件、目錄和塊信息。
- 併發寫入、隨機讀寫。一個文件不允許多個線程同時寫，僅支持數據追加，不支持文件的隨機修改。
二、HDFS架構原理
HDFS架構
- NameNode
- DataNode
- Sencondary NameNode
數據存儲細節
（1）NameNode詳解
NameNode：就是 master，它是一個主管、管理者。
- 管理 HDFS 的名稱空間
- 管理數據塊（Block）映射信息
- 配置副本策略
- 處理客戶端讀寫請求。
Namenode 的目錄結構： ${ dfs.name.dir}/current /VERSION
- /edits （操作日誌文件）
- /fsimage （元數據鏡像文件）
- /fstime （保存最近一次恢復的時間）
Namenode 上保存着 HDFS 的名字空間。對於任何對文件系統元數據產生修改的操作， Namenode 都會使用一種稱爲 EditLog 的事務日誌記錄下來。例如，在 HDFS 中創建一個文件， Namenode 就會在 Editlog 中插入一條記錄來表示；同樣地，修改文件的副本系數也將往 Editlog 插入一條記錄。 Namenode 在本地操作系統的文件系統中存儲這個 Editlog 。整個文件系統的名 字空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱爲 FsImage 的文件中，這 個文件也是放在 Namenode 所在的本地文件系統上。
Namenode 在內存中保存着整個文件系統的名字空間和文件數據塊映射(Blockmap) 的映像 。這個關鍵的元數據結構設計得很緊湊，因而一個有 4G 內存的Namenode 足夠支撐大量的文件 和目錄。當 Namenode 啓動時，它從硬盤中讀取Editlog 和 FsImage ，將所有 Editlog 中的事務作 用在內存中的 FsImage 上，並將這個新版本的 FsImage 從內存中保存到本地磁盤上，然後刪除 舊的 Editlog ，因爲這個舊的 Editlog 的事務都已經作用在 FsImage 上了。這個過程稱爲一個檢查 點(checkpoint) 。在當前實現中，檢查點只發生在 Namenode 啓動時，在不久的將來將實現支持 週期性的檢查點。
（2）Secondary NameNode詳解
Secondary NameNode：並非 NameNode 的熱備。當NameNode 掛掉的時候，它並不能馬上替換 NameNode 並提供服務。
- 輔助 NameNode，分擔其工作量。
- 定期合併 fsimage和fsedits，並推送給NameNode。
- 在緊急情況下，可輔助恢復NameNode。
- SecondaryNameNode會定期和NameNode通信，請求其停止使用EditLog文件，暫時將新的寫操作寫到一個新的文件edit.new上來，這個操作是瞬間完成，上層寫日誌的函數完全感覺不到差別；
- SecondaryNameNode通過HTTP GET方式從NameNode上獲取到FsImage和EditLog文件，並下載到本地的相應目錄下；
- SecondaryNameNode將下載下來的FsImage載入到內存，然後一條一條地執行EditLog文件中的各項更新操作，使得內存中的FsImage保持最新；這個過程就是EditLog和FsImage文件合併；
- SecondaryNameNode執行完（3）操作之後，會通過post方式將新的FsImage文件發送到NameNode節點上
- NameNode將從SecondaryNameNode接收到的新的FsImage替換舊的FsImage文件，同時將edit.new替換EditLog文件，通過這個過程EditLog就變小了
（3）HDFS NameSpace詳解
HDFS 支持傳統的層次型文件組織結構。用戶或者應用程序可以創建目錄，然後將文件保存在這些目錄裏。文件系統名字空間的層次結構和大多數 現有的文件系統類似：用戶可以創建、刪除、移動或重命名文件。當前， HDFS 不支持用戶磁盤配額和訪問權限控制，也不支持硬鏈接和軟鏈接。但 是 HDFS 架構並不妨礙實現這些特性。
Namenode 負責維護文件系統命名空間，任何對文件系統名字空間或屬 性的修改都將被 Namenode 記錄下來。應用程序可以設置 HDFS 保存的文件 的副本數目。文件副本的數目稱爲文件的副本系數，這個信息也是由 Namenode 保存的。
（4）DataNode詳解
DataNode：就是Slave。NameNode 下達命令，DataNode 執行實際的操作。
- 存儲實際的數據塊。
- 執行數據塊的讀/寫操作。
Datanode 將 HDFS 數據以文件的形式存儲在本地的文件系統中，它並不知道有 關 HDFS 文件的信息。它把每個 HDFS 數據塊存儲在本地文件系統的一個單獨的文件 中。 Datanode 並不在同一個目錄創建所有的文件，實際上，它用試探的方法來確定 每個目錄的最佳文件數目，並且在適當的時候創建子目錄。在同一個目錄中創建所 有的本地文件並不是最優的選擇，這是因爲本地文件系統可能無法高效地在單個目 錄中支持大量的文件。
當一個 Datanode 啓動時，它會掃描本地文件系統，產生一個這些本地文件對應 的所有 HDFS 數據塊的列表，然後作爲報告發送到 Namenode ，這個報告就是塊狀態 報告。
（5）Client詳解
Client：就是客戶端。
- 文件切分。文件上傳 HDFS 的時候，Client 將文件切分成 一個一個的Block，然後進行存儲。
- 與 NameNode交互，獲取文件的位置信息。
- 與 DataNode 交互，讀取或者寫入數據。
- Client 提供一些命令來管理HDFS，比如啓動或者關閉HDFS。
- Client 可以通過一些命令來訪問 HDFS。
（6）HDFS通信協議
所有的 HDFS 通訊協議都是構建在 TCP/IP 協議上。客戶端通過一個可 配置的端口連接到 Namenode ， 通過 ClientProtocol 與 Namenode 交互。而Datanode 是使用 DatanodeProtocol 與 Namenode 交互。再設計上，DataNode 通過週期性的向 NameNode 發送心跳和數據塊來保持和 NameNode 的通信，數據塊報告的信息包括數據塊的屬性，即數據塊屬於哪 個文件，數據塊 ID ，修改時間等， NameNode 的 DataNode 和數據塊的映射 關係就是通過系統啓動時DataNode 的數據塊報告建立的。從 ClientProtocol 和 Datanodeprotocol 抽象出一個遠程調用 ( RPC ）， 在設計上， Namenode 不會主動發起 RPC ， 而是是響應來自客戶端和 Datanode 的 RPC 請求。
（7）HDFS的安全模式
Namenode 啓動後會進入一個稱爲安全模式的特殊狀態。處於安全模式 的Namenode 是不會進行數據塊的複製的。 Namenode 從所有的 Datanode 接收心跳信號和塊狀態報告。塊狀態報告包括了某個 Datanode 所有的數據 塊列表。每個數據塊都有一個指定的最小副本數。當 Namenode 檢測確認某 個數據塊的副本數目達到這個最小值，那麼該數據塊就會被認爲是副本安全 (safely replicated) 的；在一定百分比（這個參數可配置）的數據塊被 Namenode 檢測確認是安全之後（加上一個額外的 30 秒等待時間）， Namenode 將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒 有達到指定數目，並將這些數據塊複製到其他 Datanode上。
三、HDFS文件讀寫的解析
（1）文件讀取流程
HDFS的文件讀取原理，主要包括以下幾個步驟：
- 首先調用FileSystem對象的open方法，其實獲取的是一個DistributedFileSystem的實例。
- DistributedFileSystem通過RPC(遠程過程調用)獲得文件的第一批block的locations，同一block按照重複數會返回多個locations，這些locations按照hadoop拓撲結構排序，距離客戶端近的排在前面。
- 前兩步會返回一個FSDataInputStream對象，該對象會被封裝成DFSInputStream對象，DFSInputStream可以方便的管理datanode和namenode數據流。客戶端調用read方法，DFSInputStream就會找出離客戶端最近的datanode並連接datanode。
- 數據從datanode源源不斷的流向客戶端。
- 如果第一個block塊的數據讀完了，就會關閉指向第一個block塊的datanode連接，接着讀取下一個block塊。這些操作對客戶端來說是透明的，從客戶端的角度來看只是讀一個持續不斷的流。
- 如果第一批block都讀完了，DFSInputStream就會去namenode拿下一批blocks的location，然後繼續讀，如果所有的block塊都讀完，這時就會關閉掉所有的流。
（2）文件寫入流程
HDFS的文件寫入原理，主要包括以下幾個步驟：
- 客戶端通過調用 DistributedFileSystem 的create方法，創建一個新的文件。
- DistributedFileSystem 通過 RPC（遠程過程調用）調用NameNode，去創建一個沒有blocks關聯的新文件。創建前，NameNode會做各種校驗，比如文件是否存在，客戶端有無權限去創建等。如果校驗通過，NameNode 就會記錄下新文件，否則就會拋出IO異常。
- 前兩步結束後會返回 FSDataOutputStream 的對象，和讀文件的時候相似，FSDataOutputStream 被封裝DFSOutputStream，DFSOutputStream 可以協調 NameNode和DataNode。客戶端開始寫數據到DFSOutputStream,DFSOutputStream會把數據切成一個個小packet，然後排成隊列data queue。
- DataStreamer 會去處理接受 data queue，它先問詢 NameNode 這個新的 block最適合存儲的在哪幾個DataNode裏，比如重複數是3，那麼就找到3個最適合的 DataNode，把它們排成一個pipeline。DataStreamer 把 packet 按隊列輸出到管道的第一個 DataNode 中，第一個DataNode又把 packet 輸出到第二個 DataNode 中，以此類推。
- DFSOutputStream 還有一個隊列叫ack queue，也是由 packet組成，等待DataNode的收到響應，當pipeline中的所有DataNode都表示已經收到的時候，這時akcqueue纔會把對應的packet包移除掉。 客戶端完成寫數據後，調用close方法關閉寫入流。
- DataStreamer把剩餘的包都刷到 pipeline 裏，然後等待 ack 信息，收到最後一個 ack 後，通知 DataNode 把文件標示爲已完成。
流水線複製：
當客戶端向 HDFS 文件寫入數據的時候，一開始是寫到本地臨時文件中。假設該文件的副 本系數設置爲 3 ，當本地臨時文件累積到一個數據塊的大小時，客戶端會從 Namenode 獲取一個 Datanode 列表用於存放副本。然後客戶端開始向第一個 Datanode 傳輸數據，第一個 Datanode 一小部分一小部分 (4 KB) 地接收數據，將每一部分寫入本地倉庫，並同時傳輸該部分到列表中 第二個 Datanode節點。第二個 Datanode 也是這樣，一小部分一小部分地接收數據，寫入本地 倉庫，並同時傳給第三個 Datanode 。最後，第三個 Datanode 接收數據並存儲在本地。因此， Datanode 能流水線式地從前一個節點接收數據，並在同時轉發給下一個節點，數據以流水線的 方式從前一個 Datanode 複製到下一個
更細節的原理：
客戶端創建文件的請求其實並沒有立即發送給 Namenode ，事實上，在剛開始階 段 HDFS 客戶端會先將文件數據緩存到本地的一個臨時文件。應用程序的寫操作被透 明地重定向到這個臨時文件。當這個臨時文件累積的數據量超過一個數據塊的大小 ，客戶端纔會聯繫 Namenode 。 Namenode 將文件名插入文件系統的層次結構中，並 且分配一個數據塊給它。然後返回 Datanode 的標識符和目標數據塊給客戶端。接着 客戶端將這塊數據從本地臨時文件上傳到指定的 Datanode 上。當文件關閉時，在臨 時文件中剩餘的沒有上傳的數據也會傳輸到指定的 Datanode 上。然後客戶端告訴 Namenode 文件已經關閉。此時 Namenode 纔將文件創建操作提交到日誌裏進行存儲 。如果 Namenode 在文件關閉前宕機了，則該文件將丟失。
四、副本機制
特點：
- 數據類型單一
- 副本數比較多
- 寫文件時副本的放置方法
- 動態的副本創建策略
- 弱化的副本一致性要求
副本擺放策略：
參考文章：
- https://www.cnblogs.com/codeOfLife/p/5375120.html
- https://blog.csdn.net/weixin_38750084/article/details/82963235
- https://www.iteye.com/blog/aoyouzi-2291871
以上內容僅供參考學習，如有侵權請聯繫我刪除！
如果這篇文章對您有幫助，左下角的大拇指就是對博主最大的鼓勵。
您的鼓勵就是博主最大的動力！