Hadoop之HDFS子架構

體繫結構

由圖片可以看到HDFS主要包含這樣幾個功能組件
Namenode:儲存文檔的中繼資料資訊，還有整個檔案系統的目錄結構
DataNode:儲存文檔塊資訊，並且文檔塊之間是有冗餘備份的
這裡面提到了文檔塊的概念，同本地檔案系統一樣，HDFS也是按Block Storage的，只不過塊的大小設定的相對大一些，預設為64M。如果一個檔案不足64M，那麼它只儲存在一個塊中，而且並不會佔用64M的磁碟空間，
這一點需要注意，HDFS不適用於小檔案儲存體的原因並不是因為小檔案消耗磁碟空間，而是因為小檔案佔用了太多的塊資訊，每個文檔塊的中繼資料是會儲存在namenode的記憶體裡的，因此當文檔塊較多的時候會十分消耗namenode的記憶體

從功能結構來看，namenode提供了資料定位的功能，datanode提供資料轉送，也就是用戶端在訪問檔案系統的時候是直接從datanode裡面讀取資料的，而不是namenode

從部署結構來看,namenode作為系統的唯一單點，如果一旦出現問題那麼後果是十分危險的，整個文檔系統將面臨癱瘓，HDFS針對此設計了secondNameNode，用來備份namenode的資料

從目錄結構來看，namenode由兩部分資訊組成
fsimage用來封裝檔案系統的中繼資料資訊（包括文檔的訪問時間、存取權限，所包含的資料區塊等）
edits用來記錄文檔系統的動作記錄
當namenode啟動的時候，fsimage會被載入到記憶體，然後對記憶體裡的資料執行edits所記錄的操作，以確保記憶體所保留的資料處於最新的狀態。
當namenode啟動後，所有對檔案系統中繼資料的訪問都是從記憶體中擷取的，而不是fsimage。fsimage和edits只是實現了中繼資料的持久儲存功能，事實上所有基於記憶體的儲存系統大概都是採用這種方式
這樣做的好處是加快了中繼資料的讀取和更新操作(直接在記憶體中進行)，但是也帶來了負面的影響，當edits內容較大時，namenode的啟動會變得非常緩慢
對此，secondNamenode提供了將fsimage和edits彙總的功能，首先將namenode裡的資料拷貝過來，然後執行merge彙總操作，在將彙總後的結果返回給namenode，並且在本地保留備份，這樣不但加快了namenode的啟動速度，也對namenode的資料增加了冗餘。

IO操作

hdfs讀取檔案流程

首先，串連到Distributed File System，從namenode裡擷取要訪問的檔案由哪些塊組成，每一個塊的儲存地址是多少
然後，定位到指定的datanode去讀取檔案
注意：每個塊的儲存地址是在hadoop啟動之後才載入到namenode的記憶體裡的，而不是持久化儲存到namenode本地
namenode和datanode具備心跳通訊的功能，它會定時從datanode那裡收到一些反饋，包括block的儲存地址資訊等等

hdfs寫檔案流程

首先同樣是串連到Distributed File System，向namenode發送建立檔案的命令
namenode儲存文檔的中繼資料資訊之後會調度具體的datanode來執行資料流的寫入操作，寫入成功後，需要執行冗餘備份，將Block複製多份，每一分儲存到不同的機器節點中，防止單點故障的出現
使用HDFS來儲存資料，每個block至少要備份一份，預設是3份，如果沒有指定備份，或者備份的過程中出現了異常，則檔案的寫入操作不會成功

hdfs不適用的情境

1.低延遲的資料訪問
HDFS主要針對大檔案來設計的，多用於線下的資料分析，對於線上應用並且及時性要求較高的系統，可嘗試使用Hbase
2.大量小檔案
消耗namenode記憶體，可以使用SequenceFile或MapFile來作為小檔案的容器
3.多線程寫入，隨機寫入
HDFS系統中，每個檔案只能並發開啟一個Writer，並且寫入操作只能在檔案的末尾進行