HDFS知識點總結

時間 2019-11-17

標籤 hdfs 知識總結欄目 Hadoop 简体版

原文原文鏈接

NameNodenode

Namenode 上保存着 HDFS 的名字空間。對於任何對文件系統元數據產生修改的操做， Namenode 都會使用一種稱爲 EditLog 的事務日誌記錄下來。例如，在 HDFS 中建立一個文件， Namenode 就會在 Editlog 中插入一條記錄來表示；一樣地，修改文件的副本系數也將往 Editlog 插入一條記錄。 Namenode 在本地操做系統的文件系統中存儲這個 Editlog 。整個文件系統的名字空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱爲 FsImage 的文件中，這個文件也是放在 Namenode 所在的本地文件系統上。linux

Namenode 在內存中保存着整個文件系統的名字空間和文件數據塊映射 (Blockmap) 的映像。這個關鍵的元數據結構設計得很緊湊，於是一個有 4G 內存的 Namenode 足夠支撐大量的文件和目錄。當 Namenode 啓動時，它從硬盤中讀取 Editlog 和 FsImage ，將全部 Editlog 中的事務做用在內存中的 FsImage 上，並將這個新版本的 FsImage 從內存中保存到本地磁盤上，而後刪除舊的 Editlog ，由於這個舊的 Editlog 的事務都已經做用在 FsImage 上了。這個過程稱爲一個檢查點 (checkpoint) 。在當前實現中，檢查點只發生在 Namenode 啓動時，在不久的未來將實現支持週期性的檢查點。算法

HDFS NameSpace緩存

HDFS 支持傳統的層次型文件組織結構。用戶或者應用程序能夠建立目錄，而後將文件保存在這些目錄裏。文件系統名字空間的層次結構和大多數現有的文件系統相似：用戶能夠建立、刪除、移動或重命名文件。當前， HDFS 不支持用戶磁盤配額和訪問權限控制，也不支持硬連接和軟連接。可是 HDFS 架構並不妨礙實現這些特性。安全

Namenode 負責維護文件系統命名空間，任何對文件系統名字空間或屬性的修改都將被 Namenode 記錄下來。應用程序能夠設置 HDFS 保存的文件的副本數目。文件副本的數目稱爲文件的副本系數，這個信息也是由 Namenode 保存的。服務器

DataNode網絡

Datanode 將 HDFS 數據以文件的形式存儲在本地的文件系統中，它並不知道有關 HDFS 文件的信息。它把每一個 HDFS 數據塊存儲在本地文件系統的一個單獨的文件中。 Datanode 並不在同一個目錄建立全部的文件，實際上，它用試探的方法來肯定每一個目錄的最佳文件數目，而且在適當的時候建立子目錄。在同一個目錄中建立全部的本地文件並非最優的選擇，這是由於本地文件系統可能沒法高效地在單個目錄中支持大量的文件。數據結構

當一個 Datanode 啓動時，它會掃描本地文件系統，產生一個這些本地文件對應的全部 HDFS 數據塊的列表，而後做爲報告發送到 Namenode ，這個報告就是塊狀態報告。架構

Secondary NameNode 負載均衡

Secondary NameNode 按期合併 fsimage 和 edits 日誌，將 edits 日誌文件大小控制在一個限度下。

安全模式

在啓動的時候，NameNode進入一個叫作安全模式的特殊狀態。安全模式中不容許發生文件塊的複製。名字節點接受來自數據節點的心跳和塊報告。一個塊報告包含數據節點所擁有的數據塊的列表。

每個塊有一個特定的最小複製數。當名字節點檢查這個塊已經大於最小的複製數就被認爲是安全地複製了，當達到配置的塊安全複製比例時（加上額外的30秒），名字節點就退出安全模式。它將檢測數據塊的列表，將小於特定複製數的塊複製到其餘的數據節點。

通訊協議

全部的通訊協議都是在TCP/IP協議之上構建的。一個客戶端和指定TCP配置端口的名字節點創建鏈接以後，它和名字節點之間通訊的協議是Client Protocal（客戶端協議）。數據節點和名字節點之間經過Datanode Protocol（datanode協議）通訊。

RPC（遠程控制調用）抽象地封裝了Client Protocol和DataNode Protocol協議。按照設計，namenode不會主動發起一個RPC，它只是被動地對DataNode和Client發起的RPC做出反饋。

1、安裝hadoop須要配置的hadoop中的配置文件有哪些?

hadoop-env.sh
yarn-env.sh
core-site.xml
hdfs-site.xml
mapred-site.xml
yarn-site.xml
slaves

2、Hadoop的核心模塊和相應的進程

HDFS:namenode,datanode,secondarynamenode,namenodemanager,datanodemanager

MapReduce:ResourceManager,NodeManager,Application master

3、SecondaryNameNode的做用

若是運行namenode服務的機器損壞，那麼文件系統上全部的文件都將丟失，所以，namenode的容錯很是重要，hadoop爲此提供了兩種機制，secondaryNameNode是其中之一：

在namenode運行的時候，同時運行一個secondaryNameNode，可是它不會被用做namenode，它的做用是按期的經過編輯日誌文件（edits）合併命名空間鏡像（images），以防編輯日誌過大，secondaryNameNode通常運行在另外一臺單獨的計算機上，由於它須要佔用大量的CPU時間與namenode相同容量的內存來執行合併操做。它保存合併後的鏡像副本，並在namenode發生故障後啓用。可是，secondaryNameNode保存的狀態老是滯後於namenode的，所以主節點所有失效時，確定會丟失一部分數據

4、 Edits文件和fsimages文件的做用

fsimages文件包含整個HDFS系統中的全部目錄和文件的inode信息，對於文件來講包含了數據塊描述信息，修改時間，訪問時間；對於目錄來講，包括修改時間，訪問權限控制信息等；

Edits文件主要是在namenode已經啓動的狀況下對HDFS進行的各類更新操做進行記錄

5、 結合圖描述hdfs寫原理

1. Client調用DistributedFileSystem對象的create方法，建立一個文件輸出流（FSDataOutputStream）對象

2. 經過DistributedFileSystem對象與Hadoop集羣的NameNode進行一次RPC遠程調用，在HDFS的Namespace中建立一個文件條目（Entry），該條目沒有任何的Block

3. 經過FSDataOutputStream對象，向DataNode寫入數據，數據首先被寫入FSDataOutputStream對象內部的Buffer中，而後數據被分割成一個個Packet數據包

4. 以Packet最小單位，基於Socket鏈接發送到按特定算法選擇的HDFS集羣中一組DataNode（正常是3個，可能大於等於1）中的一個節點上，在這組DataNode組成的Pipeline上依次傳輸Packet

5. 這組DataNode組成的Pipeline反方向上，發送ack，最終由Pipeline中第一個DataNode節點將Pipeline ack發送給Client

6. 完成向文件寫入數據，Client在文件輸出流（FSDataOutputStream）對象上調用close方法，關閉流

7. 調用DistributedFileSystem對象的complete方法，通知NameNode文件寫入成功

6、結合圖描述hdfs的讀取原理

（1）客戶端調用FileSyste對象的open()方法在分佈式文件系統中打開要讀取的文件。

（2）分佈式文件系統經過使用RPC（遠程過程調用）來調用namenode，肯定文件起始塊的位置。

（3）分佈式文件系統的DistributedFileSystem類返回一個支持文件定位的輸入流FSDataInputStream對象，FSDataInputStream對象接着封裝DFSInputStream對象（存儲着文件起始幾個塊的datanode地址），客戶端對這個輸入流調用read()方法。

（4）DFSInputStream鏈接距離最近的datanode，經過反覆調用read方法，將數據從datanode傳輸到客戶端。

（5）到達塊的末端時，DFSInputStream關閉與該datanode的鏈接，尋找下一個塊的最佳datanode。

（6）客戶端完成讀取，對FSDataInputStream調用close()方法關閉鏈接

7、hdfs的構架原理

HDFS被設計成在一個大集羣中能夠跨機器地可靠地存儲海量的文件。它將每一個文件存儲成block序列，除了最後一個block，全部的block都是一樣的大小。文件的全部block爲了容錯都會被複制。每一個文件的block大小和replication(複製)因子都是可配置的。Replication(複製)因子能夠在文件建立的時候配置，之後也能夠改變。HDFS中的文件是write-one，而且嚴格要求在任什麼時候候只有一個writer。Namenode全權管理block的複製，它週期性地從集羣中的每一個Datanode接收心跳包和一個Blockreport（塊狀態報告）。心跳包的接收表示該Datanode節點正常工做，而Blockreport（塊狀態報告）包括了該Datanode上全部的block組成的列表。

（1）副本的存放

副本的存放是HDFS可靠性和性能的關鍵。HDFS採用一種稱爲rack-aware（機架感知）的策略來改進數據的可靠性、有效性和網絡帶寬的利用。這個策略實現的短時間目標是驗證在生產環境下的表現，觀察它的行爲，構建測試和研究的基礎，以便實現更先進的策略。龐大的HDFS實例通常運行在多個機架的計算機造成的集羣上，不一樣機架間的兩臺機器的通信須要經過交換機，顯然一般狀況下，同一個機架內的兩個節點間的帶寬會比不一樣機架間的兩臺機器的帶寬大。

經過一個稱爲Rack Awareness（機架意識）的過程，Namenode決定了每一個Datanode所屬的rack id。一個簡單但沒有優化的策略就是將副本存放在單獨的機架上。這樣能夠防止整個機架（非副本存放）失效的狀況，而且容許讀數據的時候能夠從多個機架讀取。這個簡單策略設置能夠將副本分佈在集羣中，有利於組件失敗狀況下的負載均衡。可是，這個簡單策略加大了寫的代價，由於一個寫操做須要傳輸block到多個機架。

在大多數狀況下，replication（複製）因子是3，HDFS的存放策略是將一個副本存放在本地機架上的節點，一個副本放在同一機架上的另外一個節點，最後一個副本放在不一樣機架上的一個節點。機架的錯誤遠遠比節點的錯誤少，這個策略不會影響到數據的可靠性和有效性。三分之一的副本在一個節點上，三分之二在一個機架上，其餘保存在剩下的機架中，這一策略改進了寫的性能。

（2）副本的選擇

爲了下降總體的帶寬消耗和讀延時，HDFS會盡可能讓reader讀最近的副本。若是在reader的同一個機架上有一個副本，那麼就讀該副本。若是一個HDFS集羣跨越多個數據中心，那麼reader也將首先嚐試讀本地數據中心的副本

8、簡述hdfs的優缺點

1）處理超大文件
這裏的超大文件一般是指百MB、設置數百TB大小的文件。目前在實際應用中，HDFS已經能用來存儲管理PB級的數據了。
2）流式的訪問數據
HDFS的設計創建在更多地響應"一次寫入、屢次讀寫"任務的基礎上。這意味着一個數據集一旦由數據源生成，就會被複制分發到不一樣的存儲節點中，而後響應各類各樣的數據分析任務請求。在多數狀況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來講，請求讀取整個數據集要比讀取一條記錄更加高效。
3）運行於廉價的商用機器集羣上
Hadoop設計對硬件需求比較低，只須運行在低廉的商用硬件集羣上，而無需昂貴的高可用性機器上。廉價的商用機也就意味着大型集羣中出現節點故障狀況的機率很是高。這就要求設計HDFS時要充分考慮數據的可靠性，安全性及高可用性。
4）不適合低延遲數據訪問
若是要處理一些用戶要求時間比較短的低延遲應用請求，則HDFS不適合。HDFS是爲了處理大型數據集分析任務的，主要是爲達到高的數據吞吐量而設計的，這就可能要求以高延遲做爲代價。
改進策略：對於那些有低延時要求的應用程序，HBase是一個更好的選擇。經過上層數據管理項目來儘量地彌補這個不足。在性能上有了很大的提高，它的口號就是goes real time。使用緩存或多master設計能夠下降client的數據請求壓力，以減小延時。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延時了。
5）沒法高效存儲大量小文件
由於Namenode把文件系統的元數據放置在內存中，因此文件系統所能容納的文件數目是由Namenode的內存大小來決定。通常來講，每個文件、文件夾和Block須要佔據150字節左右的空間，因此，若是你有100萬個文件，每個佔據一個Block，你就至少須要300MB內存。當前來說，數百萬的文件仍是可行的，當擴展到數十億時，對於當前的硬件水平來講就無法實現了。還有一個問題就是，由於Map task的數量是由splits來決定的，因此用MR處理大量的小文件時，就會產生過多的Maptask，線程管理開銷將會增長做業時間。舉個例子，處理 10000M的文件，若每一個split爲1M，那就會有10000個Maptasks，會有很大的線程開銷；若每一個split爲100M，則只有100個 Maptasks，每一個Maptask將會有更多的事情作，而線程的管理開銷也將減少不少。
改進策略：要想讓HDFS能處理好小文件，有很多方法。
利用SequenceFile、MapFile、Har等方式歸檔小文件，這個方法的原理就是把小文件歸檔起來管理，HBase就是基於此的。對於這種方法，若是想找回原來的小文件內容，那就必須得知道與歸檔文件的映射關係。
橫向擴展，一個Hadoop集羣能管理的小文件有限，那就把幾個Hadoop集羣拖在一個虛擬服務器後面，造成一個大的Hadoop集羣。google也是這麼幹過的。
多Master設計，這個做用顯而易見了。正在研發中的GFSII也要改成分佈式多Master設計，還支持Master的Failover，並且Block大小改成1M，有意要調優處理小文件啊。
附帶個Alibaba DFS的設計，也是多Master設計，它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節點和一個查詢Master節點組成。
6）不支持多用戶寫入及任意修改文件
在HDFS的一個文件中只有一個寫入者，並且寫操做只能在文件末尾完成，即只能執行追加操做。目前HDFS還不支持多個用戶對同一文件的寫操做，以及在文件任意位置進行修改。