Hadoop 分布式文件系統 - HDFS

    當數據集超過一個單獨的物理計算機的存儲能力時，便有必要將它分不到多個獨立的計算機上。管理着跨計算機網絡存儲的文件系統稱為分布式文件系統。Hadoop 的分布式文件系統稱為 HDFS，它 是為 以流式數據訪問模式存儲超大文件而設計的文件系統。

• “超大文件”是指幾百 TB 大小甚至 PB 級的數據；
• 流式數據訪問：HDFS 建立在這樣一個思想上 - 一次寫入、多次讀取的模式是最高效的。一個數據集通常由數據源生成或者復制，接着在此基礎上進行各種各樣的分析。HDFS 是為了達到高數據吞吐量而優化的，這有可能以延遲為代價。對於低延遲訪問，HBase 是更好的選擇。
• 商用硬件：即各種零售店都能買到的普通硬件。這種集群的節點故障率蠻高，HDFD需要能應對這種故障。

因此，HDFS 還不合適某些領域：

• 低延遲數據訪問：需要低延遲數據訪問在毫秒范圍內的應用不合適 HDFS
• 大量的小文件：HDFS 的 NameNode 存儲着文件系統的元數據，因此文件數量的限制也由NameNode 的內存量決定。
• 多用戶寫入、任意修改文件：HDFS 中的文件只有一個寫入者，而且寫操作總是在文件的末尾。它不支持多個寫入者，或者在文件的任意位置修改。

1. Hadoop V1 中HDFS 的架構和原理

1.1 HDFS 的結構

這里的 Client 代表用戶通過名稱節點和數據節點交互來訪問整個文件系統。它提供一個類似於 POSIX 的文件系統接口，因此用戶在編程時並不需要知道名稱節點和數據節點及其功能。

 

Client 通過 RPC 來調用 NameNode 和 DataNode。

HDFS 中大文件被分成默認64M一塊的數據塊分布存儲在集群機器中。比如：

 

在 Hadoop v0.23之前，在整個HDFS集群中只有一個命名空間，並且只有單獨的一個Name Node，這個 Name Node 負責對這單獨的一個命名空間進行管理。 Namenode中命名空間以層次結構組織中存儲着文件名和BlockID的對應關系、BlockID和具體Block位置的對應關系。這個單獨的Namenode管理着數個Datanode，Block分布在各個Datanode中，每個Datanode會周期性的向此Namenode發送心跳消息，報告自己所在Datanode的使用狀態。Block是用來存儲數據的最小單元，通常一個文件會存儲在一個或者多個Block中，默認Block大小為64MB。之后，HDFS 中增加了 BackupNameNode/SecondaryNameNode。 Namenode會實時將變化的HDFS的信息同步給Backup Namenode。Backup Namenode顧名思義是用來做Namenode的備份的。

 

 

1.2 HDFS 中的文件操作

1.2.1 文件讀取

1. client 向 namenode 發出文件讀請求

2. namenode 返回部分或者全部block列表，對每個block，返回有該block的 datanode地址

3. client 選取最近的 datanode 讀取block

4. 讀取完一個 block，關閉通信，尋找下一個 datanode，讀取該block

5. 讀取完 block 進行 checksum，讀取錯誤則從下一個擁有該 block 的datanode 讀取

1.2.2 文件寫入

1. client 向 namnode 發出文件創建請求

2. namenode 檢查文件是否存在，如果不存在，則在文件系統的命名空間中創建一個新的文件，這是並沒有塊與之相聯系。

3. client 將文件分成多個 packet，以 dataqueue 向 namenode 申請新的blocks

4. namenode 返回合適的block 存儲packet 和 packet 副本

5. 以流形式，寫入第一個 datanode

6. 該 datanode 以管道形式，寫入下一個datanode，接着下一個 datanode，最后一個 datanode 存儲成功后，返回 ack

1.2.3 副本放置策略

副本放置策略需要在可靠性與寫入帶寬和讀取帶寬之間進行權衡。默認配置下，一個 Block  會有三份備份：

• 一份放置在於客戶端相同的節點上。若客戶端運行在集群之外，NameNode 會隨即選擇節點，不過系統會避免挑選那些太滿或者太忙的節點。
• 一份放在與與第一份不同的隨即選擇的機架上（離架）
• 最后一份放在與第二份相同的機架上，但放在不同的節點上。

 

總體來說，這樣的方法在穩定性（塊存儲在兩個機架上）、寫入帶寬（寫入操作只需要做一個單一網絡轉換）、讀寫性能（選擇從兩個機架中讀取）和集群中塊的分布（客戶端只在本地機架寫入一個塊）之間，做了較好的權衡。

1.2.4 文件復制

1.  NameNode   發現部分文件的   Block   不符合最小復制數這一要求或部分   DataNode   失效。

2. 通知 DataNode  相互復制 Block 。

3.  DataNode  開始直接相互復制。

1.3 HDFS 適用的場景

1.4. Hadoop 1.0 中 HDFS 的缺陷

1. Block Storage和 namespace 高耦合
  當前namenode中的namespace 和 block management 的結合使得這兩層架構耦合在一起，難以讓其他可能namenode實現方案直接使用block storage。
 2. namenode擴展性
  HDFS的底層存儲是可以水平擴展的(解釋：底層存儲指的是datanode，當集群存儲空間不夠時，可簡單的添加機器已進行水平擴展)，但namespace不可以。當前的namespace只能存放在單個namenode上，而namenode在內存中存儲了整個分布式文件系統中的元數據信息，這限制了集群中數據塊，文件和目錄的數目。
3. 性能
  文件操作的性能制約於單個namenode的吞吐量，單個namenode當前僅支持約60K的task，而下一代Apache MapReduce將支持多於100K的並發任務，這隱含着要支持多個namenode。
4. 隔離性
  現在大部分公司的集群都是共享的，每天有來自不同group的不同用戶提交作業。單個namenode難以提供隔離性，即：某個用戶提交的負載很大的job會減慢其他用戶的job，單一的namenode難以像HBase按照應用類別將不同作業分派到不同namenode上。

 

2. Hadoop 2 中的 HDFS 

2.1 HDFS HA：解決 NameNode 單點故障

在Hadoop 2.0之前，也有若干技術試圖解決 NameNode 單點故障的問題，在這里做個簡短的總結

1. Secondary NameNode：它不是HA，它只是階段性的合並edits和fsimage，以縮短集群啟動的時間。當NameNode(以下簡稱NN)失效的時候，Secondary NN並無法立刻提供服務，Secondary NN甚至無法保證數據完整性：如果NN數據丟失的話，在上一次合並后的文件系統的改動會丟失。
2. Backup NameNode (HADOOP-4539)。它在內存中復制了NN的當前狀態，算是Warm Standby，可也就僅限於此，並沒有failover等。它同樣是階段性的做checkpoint，也無法保證數據完整性。
3. 手動把name.dir指向NFS。這是安全的Cold Standby，可以保證元數據不丟失，但集群的恢復則完全靠手動。
4. Facebook AvatarNode。Facebook有強大的運維做后盾，所以Avatarnode只是Hot Standby，並沒有自動切換，當主NN失效的時候，需要管理員確認，然后手動把對外提供服務的虛擬IP映射到Standby NN，這樣做的好處是確保不會發生腦裂的場景。其某些設計思想和Hadoop 2.0里的HA非常相似，從時間上來看，Hadoop 2.0應該是借鑒了Facebook的做法。
5. 還有若干解決方案，基本都是依賴外部的HA機制，譬如DRBD，Linux HA，VMware的FT等等。

 

2.2 HDFS Federation：解決 NameNode 擴展性和性能問題

 單 NameNode 的架構使得HDFS在集群擴展性和性能上都有潛在的問題，當集群大到一定程度后，NN進程使用的內存可能會達到上百G，常用的估算公式為1G對應1百萬個塊，按缺省塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個文件只有一個塊，所有元數據信息也不會有1KB/ block)。同時，所有的元數據信息的讀取和操作都需要與NN進行通信，譬如客戶端的addBlock、getBlockLocations，還有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群規模變大后，NN成為了性能的瓶頸。

 

HDFS Federation 是 Hadoop 最新發布版本Hadoop-0.23.0 中為 解決HDFS單點故障而提出的 namenode水平擴展方案。該方案允許HDFS創建多個namespace以提高集群的擴展性和隔離性。

2.2.1 HDFS Federation 架構

    為了水平擴展namenode，Federation使用了多個獨立的 namenode/namespace。這些namenode之間是聯合的，也就是說，他們之間相互獨立且不需要互相協調，各自分工，管理自己的區域。分布式的datanode被用作通用的數據塊存儲設備。每個datanode要向集群中所有的namenode注冊，且周期性地向所有namenode發送心跳和塊報告，並執行來自所有namenode的命令。

　　一個block pool由屬於同一個namespace的數據塊組成，每個datanode可能會存儲集群中所有block pool的數據塊。

　　每個block pool內部自治，也就是說各自管理各自的block，不會與其他block pool交流。一個namenode掛掉了，不會影響其他namenode。

　　某個namenode上的namespace和它對應的block pool一起被稱為namespace volume。它是管理的基本單位。當一個namenode/nodespace被刪除后，其所有datanode上對應的block pool也會被刪除。當集群升級時，每個namespace volume作為一個基本單元進行升級。

2.2.2 HDFS Federation 優點

　　擴展性和隔離性：支持多個namenode水平擴展整個文件系統的namespace。可按照應用程序的用戶和種類分離namespace volume，進而增強了隔離性。

　　通用存儲服務：Block Pool 抽象層為HDFS的架構開啟了創新之門。分離block storage layer使得：

　　<1> 新的文件系統(non-HDFS)可以在block storage上構建

　　<2> 新的應用程序(如HBase)可以直接使用block storage層

　　<3> 分離的block storage層為將來完全分布式namespace打下基礎

　　設計簡單：Federation 整個核心設計實現大概用了4個月。大部分改變是在Datanode、Config和Tools中，而Namenode本身的改動非常少，這樣 Namenode原先的魯棒性不會受到影響。雖然這種實現的擴展性比起真正的分布式的Namenode要小些，但是可以迅速滿足需求，另外Federation具有良好的向后兼容性，已有的單Namenode的部署配置不需要任何改變就可以繼續工作

2.2.3 HDFS Federation不足

　　1.單點故障問題

　　HDFS Federation並沒有完全解決單點故障問題。雖然namenode/namespace存在多個，但是從單個namenode/namespace看，仍然存在單點故障：如果某個namenode掛掉了，其管理的相應的文件便不可以訪問。Federation中每個namenode仍然像之前HDFS上實現一樣，配有一個secondary namenode，以便主namenode掛掉一下，用於還原元數據信息。

　　2. 負載均衡問題

　　HDFS Federation采用了Client Side Mount Table分攤文件和負載，該方法更多的需要人工介入已達到理想的負載均衡。

　　原文鏈接：http://shitouer.cn/2012/12/hdfs-federation-introduction/

 

注：以上內容皆來自於互聯網。