1、HDFS的寫流程

客戶端通過Distributed FileSystem模塊向NameNode請求上傳文件，NameNode檢查目標文件是否已存在，父目錄是否存在。

NameNode返回是否可以上傳。

客戶端請求第一個 Block上傳到哪幾個DataNode服務器上。

NameNode返回3個DataNode節點，分別為dn1、dn2、dn3。

客戶端通過FSDataOutputStream模塊請求dn1上傳數據，dn1收到請求會繼續調用dn2，然后dn2調用dn3，將這個通信管道建立完成。

dn1、dn2、dn3逐級應答客戶端。

客戶端開始往dn1上傳第一個Block（先從磁盤讀取數據放到一個本地內存緩存），以Packet為單位，dn1收到一個Packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應答隊列等待應答。

當一個Block傳輸完成之后，客戶端再次請求NameNode上傳第二個Block的服務器。（重復執行3-7步）。

2、HDFS讀數據流程

客戶端通過Distributed FileSystem向NameNode請求下載文件，NameNode通過查詢元數據，找到文件塊所在的DataNode地址。

挑選一臺DataNode（就近原則，然后隨機）服務器，請求讀取數據。

DataNode開始傳輸數據給客戶端（從磁盤里面讀取數據輸入流，以Packet為單位來做校驗）。

客戶端以Packet為單位接收，先在本地緩存，然后寫入目標文件。

3、datenode什么情況下不會備份

設置備份數為1時, 就不會備份了.

延申—Hadoop中在哪里設置備份數, 是哪個字段：在hdfs-site.xml中的dfs.replication變量.

4.HDFS中大量小文件帶來的問題以及解決的方案

問題：

hadoop中目錄、文件和塊都會以對象的形式保存在namenode的內存中, 大概每個對象會占用150bytes. 小文件數量多會大量占用namenode的內存; 使namenode讀取元數據速度變慢, 啟動時間延長; 還因為占用內存過大, 導致gc時間增加等.

解決辦法:

兩個角度, 一是從根源解決小文件的產生, 二是解決不了就選擇合并.

從數據來源入手, 如每小時抽取一次改為每天抽取一次等方法來積累數據量.

如果小文件無可避免, 一般就采用合并的方式解決. 可以寫一個MR任務讀取某個目錄下的所有小文件, 并重寫為一個大文件.

5.HDFS三個核心組件時什么，分別有什么作用

NameNode.：集群的核心, 是整個文件系統的管理節點. 維護著文件系統的文件目錄結構和元數據信息、文件與數據塊列表的對應關系

DataNode：存放具體數據塊的節點, 主要負責數據的讀寫, 定期向NameNode發送心跳

SecondaryNameNode：輔助節點, 同步NameNode中的元數據信息, 輔助NameNode對fsimage和editsLog進行合并.

6. fsimage和editlogs是做什么用的?

fsimage文件存儲的是Hadoop的元數據文件, 如果namenode發生故障, 最近的fsimage文件會被載入到內存中, 用來重構元數據的最近狀態, 再從相關點開始向前執行edit logs文件中記錄的每個事務.

文件系統客戶端執行寫操作時, 這些事務會首先記錄到日志文件中.

在namenode運行期間, 客戶端對hdfs的寫操作都保存到edit文件中, 久而久之就會造成edit文件變得很大, 這對namenode的運行沒有影響, 但是如果namenode重啟, 它會將fsimage中的內容映射到內存中, 然后再一條一條執行edit文件中的操作, 所以日志文件太大會導致重啟速度很慢. 所以在namenode運行的時候就要將edit logs和fsimage定期合并.

7. Linux中的塊大小為4KB, 為什么HDFS中塊大小為64MB或128MB?

塊是存儲在文件系統中的數據的最小單元. 如果采用4kb的塊大小來存放存儲在Hadoop中的數據, 就會需要大量的塊, 大大增加了尋找塊的時間, 降低了讀寫效率.
并且, 一個map或者一個reduce都是以一個塊為單位處理, 如果塊很小, mapreduce任務數就會很多, 任務之間的切換開銷變大, 效率降低

8. 并發寫入HDFS文件可行嗎?

不行, 因為客戶端通過namenode接收到在數據塊上寫入的許可后, 那個塊會鎖定直到寫入操作完成, 所以不能在同一個塊上寫入.

9.HDFS放置副本的策略

?

10. NameNode與SecondaryNameNode 的區別與聯系？

區別：

NameNode負責管理整個文件系統的元數據，以及每一個路徑（文件）所對應的數據塊信息。

SecondaryNameNode主要用于定期合并命名空間鏡像和命名空間鏡像的編輯日志。

聯系：

SecondaryNameNode中保存了一份和namenode一致的鏡像文件（fsimage）和編輯日志（edits）。

在主namenode發生故障時（假設沒有及時備份數據），可以從SecondaryNameNode恢復數據。

11.namenode的工作機制

第一階段：NameNode啟動

第一次啟動NameNode格式化后，創建Fsimage和Edits文件。如果不是第一次啟動，直接加載編輯日志和鏡像文件到內存。

客戶端對元數據進行增刪改的請求。

NameNode記錄操作日志，更新滾動日志。

NameNode在內存中對元數據進行增刪改。

第二階段：Secondary NameNode工作

Secondary NameNode詢問NameNode是否需要CheckPoint。直接帶回NameNode是否檢查結果。

Secondary NameNode請求執行CheckPoint。

NameNode滾動正在寫的Edits日志。

將滾動前的編輯日志和鏡像文件拷貝到Secondary NameNode。

Secondary NameNode加載編輯日志和鏡像文件到內存，并合并。

生成新的鏡像文件fsimage.chkpoint。

拷貝fsimage.chkpoint到NameNode。

NameNode將fsimage.chkpoint重新命名成fsimage。

12.datenode工作機制

一個數據塊在DataNode上以文件形式存儲在磁盤上，包括兩個文件，一個是數據本身，一個是元數據包括數據塊的長度，塊數據的校驗和，以及時間戳。

DataNode啟動后向NameNode注冊，通過后，周期性（1小時）的向NameNode上報所有的塊信息。

心跳是每3秒一次，心跳返回結果帶有NameNode給該DataNode的命令如復制塊數據到另一臺機器，或刪除某個數據塊。如果超過10分鐘沒有收到某個DataNode的心跳，則認為該節點不可用。

集群運行中可以安全加入和退出一些機器。

13. 你認為 hadoop 有哪些設計不合理的地方

不支持文件的并發寫入和對文件內容的隨機修改。

不支持低延遲、高吞吐的數據訪問。

存取大量小文件，會占用namenode大量內存，小文件的尋址時間超過讀取時間。

hadoop環境搭建比較復雜。

數據無法實時處理。

總結

以上是生活随笔為你收集整理的HDFS—常见面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。