摘要：為了保證元數(shù)據(jù)文件的高可用系統(tǒng)，一般的做法，將設置成一逗號分隔的多個目錄，這個目錄至少不要在一塊磁盤上，最后在不同的機器上。

Hadoop由兩部分組成，分別是分布式文件系統(tǒng)(HDFS)和分布式計算框架MapReduce

架構圖

負責文件元數(shù)據(jù)信息的操作以及客戶端的請求

管理HDFS文件系統(tǒng)的命名空間

維護文件樹中所有的文件和文件夾的元數(shù)據(jù)信息以及文件到快的對應關系和塊到節(jié)點的對應關系

單個NameNode支持4000臺DataNode集群

NameNode在內存中保存著整個文件系統(tǒng)的名字空間和文件數(shù)據(jù)塊的地址映射

文件名，文件目錄結構，文件創(chuàng)建時間，文件副本數(shù)，文件權限，每個文件的block列表

fsimage：元數(shù)據(jù)鏡像文件，里面記錄了自最后一次檢查點之前HDFS文件系統(tǒng)中所有目錄和文件的序列化信息；

注意：Block的位置信息不會保存到fsimage，Block保存在哪個DataNode由DataNode啟動時上報。
edits：操作日志文件，保存了自最后一次檢查點之后所有對HDFS文件的操作，比如：增加文件、重名名文件、刪除文件

在NameNode啟動的時候，先將fsimage中的文件系統(tǒng)元數(shù)據(jù)信息加載到內存，然后根據(jù)edits中的記錄將內存中的元數(shù)據(jù)同步到最新狀態(tài)；所以，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統(tǒng)不可用。

為了保證元數(shù)據(jù)文件的高可用系統(tǒng)，一般的做法，將dfs.namenode.name.dir設置成一逗號分隔的多個目錄，這個目錄至少不要在一塊磁盤上，最后在不同的機器上。

為了避免edits文件過大，SecondaryNameNode會按照時間閾值或者大小閾值，周期性的將fsimage和edits合并，然后將最新的fsimage推送給NameNode。

鏡像備份

日志與鏡像的定期合并

處理文件內容的讀寫請求

一個數(shù)據(jù)快在DataNode以文件存儲在磁盤上，包括兩個文件，一個是數(shù)據(jù)本身，一個是元數(shù)據(jù)，包括數(shù)據(jù)塊的長度，塊數(shù)據(jù)的校驗和，以及時間戳

DataNode啟動后，周期性的向NameNode上報所有的塊信息。

每3秒保持一次心跳，如果超過10分鐘沒有收到某個DataNode的心跳，則認為該節(jié)點不可用。

文件劃分成塊，默認大小128M，以快為單位，每個快有多個副本（默認3個）存儲不同的機器上。

Block數(shù)據(jù)塊是HDFS文件系統(tǒng)基本的存儲單位
小于一個快的文件，不會占據(jù)整個快的空間
使用Block有利于容災備份
Hadoop1.x 默認64M，Hadoop2.X默認128M
Block數(shù)據(jù)塊大小設置較大的原因：

減少文件尋址時間

減少管理快的數(shù)據(jù)開銷，因每個快都需要在NameNode上有對應的記錄

對數(shù)據(jù)快進行讀寫，減少建立網絡的連接成本

優(yōu)點

一個文件的大小可以大于網絡中任意一個磁盤的容量

使用抽象塊而非整個文件作為存儲單元，大大簡化了存儲子系統(tǒng)的設計

塊還非常適合用于數(shù)據(jù)備份進而提供數(shù)據(jù)容錯能力和提高可用性

將hdfs更新記錄寫入一個新的文件--edits.new

將fsimage和edits文件通過http協(xié)議發(fā)送至secondary namenode

將fsimage和edits合并，生成一個新的文件fsimage.ckpt。

將生成的fsimage.ckpt文件通過http協(xié)議發(fā)送至NameNode

重命名fsimage.ckpt為fsimage，edits.new為edits

客戶端通過調用FileSystem對象中的open()方法來讀取需要的數(shù)據(jù)

DistributedFileSystem會通過RPC協(xié)議調用NameNode來確定請求文件塊所在的位置

NameNode只會返回所調用文件中開始的幾個塊而不是全部返回。對于每個返回的塊，都包含塊所在的DataNode的地址。隨后，這些返回的DataNode會按照Hadoop集群的拓撲結構得出客戶端的距離，然后在進行排序。如果客戶端本身就是DataNode，那么它就從本地讀取文件。其次，DistributedFileSystem會向客戶端返回一個支持定位的輸入流對象FSDataInputStream，用于給客戶端讀取數(shù)據(jù)。FSDataInputStream包含一個DFSInputStream對象，這個對象來管理DataNode和NameNode之間的IO

當以上步驟完成時，客戶端便會在這個輸入流上調用read()方法

DFSInputStream對象中包含文件開始部分數(shù)據(jù)塊所在的DataNode地址，首先它會連接文件第一個塊最近的DataNode，隨后在數(shù)據(jù)流中重復調用read方法，直到這個塊讀完為止。

當?shù)谝粋€塊讀取完畢時，DFSInputStream會關閉連接，并查找存儲下一個數(shù)據(jù)塊距離客戶端最近的DataNode，以上這些步驟對客戶端來說都是透明的。

客戶端按照DFSInputStream打開和DataNode連接返回的數(shù)據(jù)流的順序讀取該塊，它也會調用NameNode來檢查下一組塊所在的DataNode位置信息。當完成所有塊的讀取時，客戶端則會在DFSInputStream中調用close()方法。

客戶端發(fā)送請求，調用DistributedFileSystem API的create方法去請求namenode，并告訴namenode上傳文件的文件名、文件大小、文件擁有者。

namenode根據(jù)以上信息算出文件需要切成多少塊block，以及block要存放在哪個datanode上，并將這些信息返回給客戶端。

客戶端調用FSDataInputStream API的write方法首先將其中一個block寫在datanode上，每一個block默認都有3個副本，并不是由客戶端分別往3個datanode上寫3份，而是由

已經上傳了block的datanode產生新的線程，由這個namenode按照放置副本規(guī)則往其它datanode寫副本，這樣的優(yōu)勢就是快。

寫完后返回給客戶端一個信息，然后客戶端在將信息反饋給namenode。