分布式文件系統

HDFS簡介

HDFS的運用非常廣泛，基本上很多大數據平台大部分都會選用HDFS（或者類似HDFS）這樣的分布式文件系統、來作為海量數據存儲的一個解決方案。

優缺點

• 優勢

1.　高容錯性，HDFS提供了非常好的“副本冗余機制”，簡單來說就是一份數據在HDFS當中存放，包含它自身在內至少會有（默認）三個副本類似隨機的存放在集群不同的服務器上，並且當其中一台服務器宕機、當前這台服務器上數據丟失，但HDFS會自動再將缺失的副本再通過copy的方式、保證數據的副本不會低於三個。

2.　可構建在廉價的商業服務器上，基於第一條高容錯性的優勢，HDFS可以搭建在低成本的廉價服務器上，而沒有必要選擇非常昂貴的服務器上，因為即使廉價服務器穩定性相對較差，但是集群規模成百上千台宕機一台、兩台對於整個HDFS集群來說，基本上沒有任何的影響。

3.　適合海量數據存儲，分布式架構設計、HDFS可支持幾萬台服務器的集群規模，乘以每台服務器磁盤容量、整個HDFS文件系統容量非常之大，並且他所支持存放的單個數據文件GB、TB、PB級別都沒有任何問題。

4.　適合批處理，它是通過“移動計算而非移動數據”來進行設計，會把數據存放位置暴露給計算框架，從而在海量數據計算過程中，數據在何處便在何處計算，避免了數據跨網絡、結點移動拷貝的工作，很大限度的提升計算速度。

5.　流式數據訪問，一次寫入、多次讀取。文件一旦寫入完成、不能修改，僅僅只支持追加。保證了數據的一致性。

• 適用場景：

1.　適合大文件存儲、海量數據存儲

2.　適合批量數據訪問

• 不擅長的一些場景：

1.　低延時數據訪問，這里的“低延時”指的是例如毫秒級別要將數據寫入HDFS、或毫秒級別讀取HDFS內數據，這個它是做不到的。它的優勢是在“高吞吐率”的場景，也就是在某一時間內大量寫入、讀取數據，但是毫秒級這種低延時它是支持不了的。

2.　並發寫入、隨機修改，HDFS當中文件只能有一個寫、不支持多個線程同時寫入一個文件。寫好的文件只支持追加功能，並不支持文件的隨機寫入。

3.　小文件存儲，小文件問題是大家在大數據領域需要格外注意的問題。首先撇開HDFS來說，假如10GB數據容量，10個1GB的數據集、1w個1M的數據集，占用存儲空間相同，讓你在這兩種數據集中找到其中一個數據文件，明顯第二種場景非常耗時，也就是說小文件存儲之后，在尋址的時間開銷會非常之高、以至於會高於讀取時間。此外，回到HDFS當中來考慮，HDFS當中每一個數據文件都會對應有一份元數據信息需要存放，大家可以把元數據信息先簡單理解為就是文件的一些基本信息（如文件名稱、大小、權限等），一個文件對應一條元數據信息，當你存儲的都是一些小文件、文件個數會急速增長，對應元數據也就需要更多的空間來存儲，並且元數據是在內存介質中存儲，這樣一來會非常浪費內存資源、顯然是不適用的。所以，在使用HDFS過程當中一定要注意“小文件”的這個問題。

HDFS原理

系統架構圖

其中NameNode是主節點，DataNode是從節點，HDFS Client是客戶端、HDFS提供了比較豐富的客戶端像cli、api、gui等等支持，SecondaryNameNode相當於輔助NameNode工作的一個節點、但並不是NameNode的備份結點（這個一定要注意區分）。

NameNode，他作為主從架構當中的主節點，其實主要負責接受客戶端提交過來的讀寫請求、以及一些類似管理的工作，比如說，數據存到HDFS當中每個文件都會對應一份元數據信息，這些元數據信息都是存放在NameNode的內存區域內、由NameNode來進行維護。

DataNode，他作為一個從節點出現，主要負責數據的存放。數據文件寫入到HDFS當中會切分為小的數據塊block（也就是圖中DataNode方框中紫色、橙色、紅色等小的方塊），這些數據塊會存放在DataNode節點上。在一個HDFS集群當中DataNode結點可以有任意多台，當然要根據你文件系統的數據量來確定，並且后期如果容量不足的情況下，也支持DataNode結點動態添加、擴容。

NameNode與DataNode之間的連線，DataNode在運行過程當中一直會和NameNode結點保持通信。一方面，在DataNode啟動時，會給NameNode上報自己服務器上有哪些數據塊、也就是block的位置存放信息，NameNode接收到這些block位置信息會維護好一份完整的元數據信息，從而找到具體數據存放在哪些DataNode上；另一方面，運行過程當中，DataNode會每隔3秒定時和NameNode做一次心跳，從而NameNode可以知道DataNode的運行狀況。

一個10G的文件上傳到HDFS中，首先，會在客戶端處進行切分，切分成一個個Block塊，默認情況下Block塊的大小是128M。

這些切分后的Block塊，會以多副本的形式均勻放置到DataNode中。

數據存放在DataNode中后，主節點NameNode需要知道這份文件具體切分了多少Block塊和每個Block塊具體存放的位置。所以NameNode節點保存有一份元數據來記錄這些信息。

fsimage可以理解為快照, 但數據塊在DateNode的位置信息不會存, 不會持久化

存儲機制

• Block文件在DataNode本地磁盤中的目錄結構。其中：

• BP-random integer-NameNode-IP address-creation time：BP代表BlockPool，就是Namenode的VERSION中的集群唯一blockpoolID

• finalized/rbw：其中finalized目錄用於實際存儲Block文件，finalized用於存 放Block文件以及Block元數據文件；rbw是“replica being written”的意思，該目錄用於存儲用戶當前正在寫入的數據

• VERSION：VERSION文件是java屬性文件，保存了HDFS的基本信息

• blk_前綴文件：HDFS中的文件塊本身，存儲的是原始文件內容

• in_use.lock：防止一台機器同時啟動多個Datanode進程導致目錄數據不一致

• 為什么有了fsimage內存快照、還需要有edits(日志)文件呢？
  因為如果每次對於文件系統有操作，元數據信息就有可能發生變化，那么每次變化都去更新一下fsimage文件，顯然成本非常之高而且性能也不好，所以fsimage並不會實時去發生變化，那么后邊這些操作則通過edits文件做一個記錄。
  

• 元數據持久化文件在DataNode本地磁盤中的目錄結構：

• fsimage_前綴文件：即fsimage文件，之所以有多個是因為他定時要做合並，所以會保留有多份fsimage文件

• edits_前綴文件：即edits文件。

• VERSION：VERSION文件是java屬性文件，保存了HDFS的基本信息

• seen_txid：是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾數，namenode重啟的時候，會按照seen_txid的數字，循序從頭跑edits_0000001~到seen_txid的數字。

看一下他們的名稱命名規則，fsimage名稱中一大串數字是合並時的一個id標識，edits文件名當中通過下划線分割前后分別代表合並前、后的id標識。

左右分別為NameNode以及SecondaryNameNode。整個合並流程為，NameNode在磁盤中有fsimage，集群在運行過程當中，客戶端各項操作記錄會寫入到edits文件內，當觸發合並時，SecondaryNameNode會主動從NameNode中通過HttpGet方式將edits和fsimage文件拷貝並存放在本地磁盤中，然后開始合並，合並過程其實就是將該fsimage加載到內存當中，然后逐條執行edits日志中的各項操作、來更新內存里的元數據信息，全部日志執行完成后，此時內存當中的元數據信息便是觸發合並那個時間點一份完整的元數據信息，再往后，SecondaryNameNode將內存當中元數據持久化（做快照）產生一個新的fsimage文件，再通過Http Post方式將這個新的fsimage文件發送給NameNode，NameNode接收到新的fsimage文件啟用新的fsimage文件。並且在觸發合並的時候，NameNode除會把fsimage、edits交給SecondaryNameNode去合並，與此同時還會生成一個空的edits文件，SecondaryNameNode在做合並的整個過程中，所有客戶端的操作都會記錄在這個新的空edits文件中，直到SecondaryNameNode把新的fsimage文件推給NameNode，NameNode會同時將新的fsimage、以及新的edits文件啟用整個合並過程完成結束。

SecondaryNameNode只是做了局部備份, 沒有完整備份。

這邊是HDFS元數據合並的機制，在運行過程中HDFS會定期觸發整個合並流程，從而會保證fsimage文件越來越大、但edits文件會在比較的一個范圍內，這樣一個效果。

讀寫操作

寫操作

讀操作

安全模式

• 核心的配置項：dfs.namenode.safemode.threshold-pct: 副本數達到最小要求的block占系統總block數的百分比，當實際比例超過該配置后，才能離開安全模式（但是還需要其他條件也滿足）。默認為0.999f，也就是說符合最小副本數要求的block占比超過99.9%時，並且其他條件也滿足才能離開安全模式。如果為小於等於0，則不會等待任何副本達到要求即可離開。如果大於1，則永遠處於安全模式。其他配置項一般默認不啟用，先不做討論。

高可用

高可用的本質是在主節點宕機之后，從熱備節點可以立馬代替宕機的主節點接管集群，保證服務是不中斷的。那對於NameNode來說，如果要立馬接管集群並且保證服務不中斷，那就需要元數據保持一致。

在QJM這種高可用方案中，Journal集群可以實現edits共享，實現Master主備節點的元數據同步。

• 此時集群一共有兩台NameNode、分別處於Active、Standby狀態，Active狀態的NameNode相當於處於工作狀況、對集群負責管理並且接受客戶端請求，另外一台Standby狀態的NameNode處於一個等待狀況如果Active的出現問題由它來負責接管集群。

• JournalNode集群，它負責管理NameNode日志edits文件的管理，也就是ActiveNameNode寫日志是直接寫入到JournalNode集群上。

• ZKFC – ZookeeperFailoverController，每台NameNode服務器上都會運行一個ZKFC進程，主要負責兩個任務：監控當前NameNode運行狀況信息、與Zookeeper集群保持心跳並將這些信息匯報給Zookeeper集群；控制NameNode Active、Standby狀態的切換管理。

• Zookeeper集群，實際中也是部署2N+1台，核心也是通過Paxos算法，在HDFS集群中主要負責接收到ZKFC匯報的NameNode健康信息做“選舉”，“選舉”哪一台NameNode應該是Active狀態。

• 最下邊是DataNode集群，負責數據的存儲，但是區別於1.x的設計、在2.x集群中DataNode上報block信息會同時上報給兩台NameNode。

HDFS運行過程中，如果Active的NameNode運行出現故障，此時當前NameNode上的ZKFC會將異常的健康信息匯報給Zookeeper集群，或者NameNode這台服務器宕機，Zookeeper集群長時間接收不到ZKFC的數據，都會得知第一台NameNode運行出現了問題。此時，Zookeeper集群會做選舉、推選第二台NameNode作為Active的NameNode來接管集群，之后Zookeeper先通知給第二台NameNode上的ZKFC，由ZKFC將當前這台NameNode狀態從Standby切換為Active。fsimage文件在第二台NameNode上有一份，運行過程中edits文件一直寫在JournalNode集群上、第二台NameNode可以直接拿到這些edits文件，狀態切換之后，便可以先將fsimage加載內存，然后一條一條執行edits日志內容，並且集群在運行過程中DataNode會將各自服務器上block信息匯報給第一台和第二台，第二台上緩存有這些block信息再將它和內存當中部分原數據信息進行拼接。當這些操作全部執行完成之后，此時第二台NameNode內存當中元數據信息和第一台NameNode出現故障時內存當中元數據信息完全一致，這樣整個HA便達到了。

HDFS操作命令

文件系統命令

HDFS運維管理

藍色部分是一段core-site.xml的配置，Hadoop當中大部分配置都是這種xml格式，property標簽為配置項名稱，value標簽為配置值。

fs.defaultFS：配置HDFS默認入口，1.x中只有一台NameNode一般配置為hdfs://namenode:rpcport，但在2.x中有兩台NameNode、並且兩台會自動狀態切換，所以2.x中在hdfs-site.xml中可配置一個nameservice命名服務，通過hdfs://nameservice來訪問HDFS、它會自動轉到對應Active狀態的NameNode來接收請求。

dfs.namenode.name.dir：NameNode結點存放元數據文件fsimage的位置；

dfs.datanode.data.dir：DataNode結點存放數據塊block的位置；

dfs.blocksize：數據塊block大小；

dfs.datanode.du.reserved：DataNode結點磁盤余留空間大小，防止磁盤被HDFS全部寫滿；

dfs.replication：block副本數量；

fs.trash.interval：回收站內數據隔多久之后被徹底刪除。