HDFS 技術原理(上)
HDFS 概述及應用場景
HDFS 概述:
HDFS(Hadoop Distributed File System) 基於 Google 發佈的 GFS 論文設計開發,運行在通用硬件平臺上的分佈式文件系統。
其除具有其他分佈式文件系統的相同特性外,還有自己特有的特性:
-
高容錯性:認爲硬件總是不可靠的。
-
高吞吐量:爲大量數據訪問的應用提供高可用吞吐量支持。
-
大文件存儲:支持存儲 TB-PB 級別的數據。
HDFS 適合做:大文件存儲、流式數據訪問。
HDFS 不適合做:大量小文件、隨機寫入、低延遲讀取。
HDFS 應用場景舉例:
HDFS 是 Hadoop 技術框架中的分佈式文件系統,對部署在多臺獨立物理機器上的文件進行管理。
可應用與以下幾種場景:
-
網站用戶行爲數據存儲。
-
生態系統數據存儲。
-
氣象數據存儲。
HDFS 在 FusionInsight 產品的位置:
HDFS 位置
圖:HDFS 在 FusionInsight 產品中的位置
FusionInsight HD 提供大數據處理環境,基於社區開源軟件增強,按照場景選擇業界最佳實踐。
HDFS 作爲 Hadoop 的基礎存儲設施,實現了一個分佈式、高容錯、可線性擴展的文件系統。
HDFS 系統架構
系統設計目標:
(1)硬件失效:
-
硬件的異常比軟件的異常更加常見。
-
對於有上百臺服務器的數據中心來說,認爲總有服務器異常,硬件異常是常態。
-
HDFS 需要監測這些異常,並自動恢復數據。
(2)流式數據訪問:
-
基於 HDFS 的應用僅採用流式方式讀數據。
-
運行在 HDFS 上的應用並非以通用業務爲目的的應用程序。
-
應用程序關注的是吞吐量,而非響應時間。
-
非 POSIX 標準接口的數據訪問。
(3)存儲數據大:
-
運行在 HDFS 的應用程序有較大的數據需要處理。
-
典型的文件大小爲 GP 到 TB 級別。
(4)數據一致性:
-
應用程序採用 WORM(Write Once Read Many)的數據讀寫模型。
-
文件僅支持追加,而不允許修改。
(5)多硬件平臺:
- HDFS 可運行在不同的硬件平臺上。
(6)移動計算能力:
-
計算和存儲能力採用就近原則,計算離數據最近。
-
就近原則將有效減少網絡的負載,降低網絡擁塞。
基本系統架構:
HDFS 架構
圖:HDFS 系統架構圖
HDFS 架構包含三個部分:(NameNode,DateNode,Client)
-
NameDode:用於存儲、生成文件系統的元數據、運行一個實例。
-
DateNode:用於存儲實際的數據,將自己管理的數據塊上報給 NameNode,運行多個實例。
-
Client:支持業務訪問 HDFS,從 NameNode,DateNode 獲取數據返回給業務。多個實例,和業務一起運行。
HDFS 數據寫入流程:
HDFS 寫入流程
圖:HDFS 數據寫入流程圖
HDFS 數據寫入流程如下:
-
業務應用調用 HDFS Client 提供的 API 創建文件,請求寫入。
-
HDFS Client 聯繫 NameNode,NameNode 在元數據中創建文件節點。
-
業務應用調用 write API 寫入文件。
-
HDFS Client 收到業務數據後,從 NameNode 獲取到數據塊編號、位置信息後,聯繫 DateNode,並將要寫入數據的 DateNode 建立起流水線。完成後,客戶端再通過自有協議寫入數據到 DateNode1,再由 DateNode1 複製到 NateNode2,DateNode3.
-
寫完的數據,將返回確認信息給 HDFS Client。
-
所有數據確認完成後,業務調用 HDFS CLient 關閉文件。
-
業務調用 close,flush 後 HDFS Client 聯繫 NameNode,確認數據寫完成,NameNode 持久化元數據。
HDFS 數據讀取流程:
HDFS 數據讀取
圖:HDFS 數據讀取流程圖
HDFS 數據讀取流程如下:
-
業務調用 HDFS Client 提供的 API 打開文件。
-
HDFS Client 聯繫 NmaeNode,獲取到文件信息(數據塊、DateNode 位置信息)。
-
業務應用調用 read API 讀取文件。
-
HDFS Client 根據從 NmaeNode 獲取到的信息,聯繫 DateNode,獲取相應的數據塊。(Client 採用就近原則讀取數據)。
-
HDFS Client 會與多個 DateNode 通訊獲取數據塊。
-
數據讀取完成後,業務調用 close 關閉連接。
HDFS 關鍵特性介紹
HDFS 架構關鍵設計:
關鍵特性
圖:HDFS 架構關鍵設計
元數據持久化:
元數據持久 haul
圖:元數據持久化流程圖
元數據持久化流程如下:
-
備 NmaeNode 通知主 NameNode 生成新的日誌文件,以後的日誌寫到 Editlog.new 中,並獲取舊的 Editlog。
-
備 NameNode 從注 NameNode 上獲取 FSImage 文件及位於 JournalNode 上面的舊 Editlog。
-
備 NmaeNode 將日誌和舊的元數據合併,生成新的元數據 FSImage.ckpt。
-
備 NameNode 將元數據上傳到主 NameNode。
-
主 NameNode 將上傳的原書記進行回滾。
-
循環步驟 1.
元數據持久化健壯機制:
HDFS 主要目的是保證存儲數據完整性,對於各組件的失效,做了可靠性處理。
-
重建失效數據盤的副本數據
DateNode 向 NmaeNode 週期上報失敗時,NmaeNode 發起副本重建動作以恢復丟失副本。
-
集羣數據均衡
HDFS 架構設計了數據均衡機制,此機制保證數據在各個 DateNode 上分佈式平均的。
-
數據有效性保證
DateNode 數據在讀取時校驗失敗,則從其他數據節點讀取數據。
-
元數據可靠性保證
採用日誌機制操作元數據,同時元數據存放在主備 NameNode 上。
快照機制實現了文件系統常見的快照機制,保證數據誤操作時,能及時恢復。
-
安全模式
HDFS 提供獨有的安全模式機制,在數據節點故障時,能防止故障擴散。
HDFS 高可靠性 (HA):
HDFS 高可靠性
圖;HDFS 高可靠性原理
HA 解決的是一個熱備份的問題。
HDFS 的高可靠性(HA)架構在基本架構上增加了一下組件:
-
ZooKeeper:分佈式協調,主要用來存儲 HA 下的狀態文件,主備信息、ZK 個數建議 3 個及以上且爲奇數個。
-
NmaeNode 主備:NmaeNode 主備模式,主提供服務,備合併元數據並作爲主的熱備。
-
ZKFC(Zookeeper Failover Controller)用於控制 NmaeNode 節點的主備狀態。
-
JN(JournalNode)日誌節點:用於共享存儲 NmaeNode 生成的 Editlog。
HA
圖:HA 原理
處於待命狀態的名稱節點和處於活狀態的名稱節點,它們元數據的兩個方面的信息是怎麼同步的:
處於待命狀態的名稱節點當中,它的兩方面元數據,一個就是 Editlog,它是通過共享存儲系統來獲得同步的,處於活躍狀態的名稱節點已發生變化,馬上寫入到共享存儲系統,然後這共享存儲系統會通知待命的名稱節點把它取走,這樣可以保證 Editlog 上兩者可以保持同步。對於映射表信息而言,也就是一個文件包含幾個塊,這些塊被保存到哪個數據節點上面。這種映射信息,它的 實時的維護是通過底層數據節點,不斷同時向活躍名稱節點和待命節點名稱節點彙報來進行維護的。這就是它的基本原理。
HDFS 聯邦(Federation):
聯邦
圖;HDFS 聯邦
HDFS Federation 主要能夠解決,單名稱節點中存在的以下問題:
-
HDFS 集羣的擴展性問題。
有了多個名稱節點,每個名稱節點都可以各自的去管理一部分目錄。管理自己對應的子命名空間的子目錄,這樣就可以讓一個集羣擴展到更多節點。
在 HDFS1.0 中會受到內存的限制,制約文件存儲數目等限制。一個名稱節點存儲的文件數目是有限的。
-
性能更高效
多個名稱節點各自都管理它不同的數據,而且可以同時對外服務,所以可以提供更高的數據的吞吐率。
-
良好的隔離性
因爲它已經根據不同業務數據要求,進行了子空間的劃分,某種業務數據可能歸某個名稱節點管理,另外一種業務數據屬於另外一個命名空間,歸另外一個名稱節點管理。所以不同數據都分給不同名稱節點去管理,這樣就可以有效地對不同應用程序進行隔離。不會導致一個應用程序消耗過多資源,而影響另外一個應用程序運行的問題。
HDFS 不能解決單點故障問題。
數據副本機制:
數據副本機制
圖:數據副本機制
副本距離計算公式:
-
Distance(Rack1/D1,Rack1/D1)= 0 , 同一臺服務器的距離爲 0.
-
Distance (Rack1/D1, Rack1/D3) = 2; 同一機架不同的服務器距離爲 2.
-
DIstance(Rack1/D1, Rack2/D1)= 4 ;不同機架的服務器距離爲 4.
副本放置策略:
-
第一個副本在本地機器。
-
第二個副本在遠端機架的節點。
-
第三個副本看之前連個副本是否在同一機架,如果是則選擇其他機架,否則選擇和第一個副本相同機架的不同節點。
-
第四個及以上,隨機選擇副本存放位置。
配置 HDFS 數據存儲策略:
默認情況下,HDFS NmaeNode 自動選擇 DateNode 保存數據的副本。在實際義務中,存在以下場景:
-
DateNode 上存在的不同存儲設備,數據需要選擇一個合適的設備分級存儲數據。
-
DateNode 不同目錄中的數據重要程度不同,數據需要根據目錄標籤選擇一個格式的 DateNode 節點保存。
-
DateNode 集羣使用了異構服務器,關鍵數據需要保存在具有高度可靠性的節點組中。
配置 DateNode 使用分級存儲:
-
HDFS 的分級存儲框架提供了 RAM_DISK(內存盤)、DISK(機械硬盤)、ARCHIVE(高密度低成本存儲介質)、SSD(固態硬盤)四種存儲類型的存儲設備。
-
通過對四種存儲類型進行合理組合,即可形成使用與不公場景的存儲策略。
存儲策略
配置標籤存儲策略:
標籤存儲
圖;標籤存儲策略
配置 DateNode 使用標籤存儲:
用戶通過數據特徵靈活配置 HDFS 數據塊存放策略,即爲一個 HDFS 目錄設置一個標籤表達式,每個 DateNode 可以對應一個或多個標籤;當基於標籤的數據塊存放策略爲指定目錄下的文件選擇 DateNode 節點進行存放時,根據文件的標籤表達式選擇出將要存放的 DateNode 節點範圍,然後在這個 DateNode 節點範圍內,遵守下一個指定的數據塊存放策略進行存放。
配置 DateNode 使用節點組存儲:
節點組存儲
圖:節點組存儲
配置 DateNode 使用節點組存儲:
關鍵數據根據實際業務需要保存在具有高度可靠性的節點中,此時 DateNode 組成了異構集羣。通過修改 DateNode 的存儲策略,系統可以將數據強制保存在指定的節點組中。
使用約束:
-
第一份副本將從強制機架組(機架組 2)中選出,如果在強制機架組中沒用可用節點,則寫入失敗。
-
第二份副本將從本地客戶端機器或機架組中的隨機節點(當客戶端機架組不爲強制機架組時)選出。
-
第三份副本將從其他機架組中選出。
-
各副本應放在不同的機架組中。如果所需副本的數量大於可用的機架組數量,則會將多出的副本存放在隨機機架組中。
Colocation 同分布:
同分布(Colocation)的定義:將存在關聯關係的數據或可能要進行關聯操作的數據存儲在相同的存儲節點上。
按照下圖存放,假設要將文件 A 和文件 D 進行關聯操作,此時不可避免地要進行大量的數據搬遷,整個集羣將由於數據傳輸佔用大量網絡帶寬,嚴重影響大數據的處理速度與系統性能。
NN
HDFS 文件同分布的特性,將那些需要進行關聯操作的文件存放在相同的數據節點上,在進行關聯操作計算是避免了到其他數據節點上獲取數據,大大降低了網絡帶寬的佔用。
使用同分布特性,文件 A、D 進行 join 時,由於其對應的 block 都在相同的節點,因此大大降低了資源消耗。如下圖:
效果他
圖:Colocation 同分布效果圖
HDFS 架構其他關鍵設計要點說明:
-
統一的文件系統:
HDFS 對外僅呈現一個統一的文件系統。
-
統一的通訊協議:
統一採用 RPC 方式通信、NmaeNode 被動的接收 Client,DateNode 的 RPC 請求。
-
空間回收機制:
支持回收站機制,以及副本數的動態設置機制。
-
數據組織:
數據存儲以數據塊爲單位,存儲在操作系統的 HDFS 文件系統上。
-
訪問方式:
提供 Java API,http,shell 方式訪問 HDFS 數據。
常用的 shell 命令:
shell
HDFS 主要組件的功能
名稱節點的數據結構:
- 在 HDFS 中,名稱節點(NameNode)負責管理分佈式文件系統的命名空間(Namespace),保存了兩個核心的數據結構,即 FsImage 和 EditLog
-
FsImage 用於維護文件系統樹以及文件樹中所有的文件和文件夾的元數據
-
操作日誌文件 EditLog 中記錄了所有針對文件的創建、刪除、重命名等操作
- 名稱節點記錄了每個文件中各個塊所在的數據節點的位置信息
名稱節點數據結構
圖:名稱節點的數據結構
FsImage 文件:
FsImage 文件包含文件系統中所有目錄和文件 inode 的序列化形式。每個 inode 是一個文件或目錄的元數據的內部表示,幷包含此類信息:文件的複製等級、修改和訪問時間、訪問權限、塊大小以及組成文件的塊。對於目錄,則存儲修改時間、權限和配額元數據.
FsImage 文件沒有記錄塊存儲在哪個數據節點。而是由名稱節點把這些映射保留在內存中,當數據節點加入 HDFS 集羣時,數據節點會把自己所包含的塊列表告知給名稱節點,此後會定期執行這種告知操作,以確保名稱節點的塊映射是最新的。
名稱節點的啓動:
-
在名稱節點啓動的時候,它會將 FsImage 文件中的內容加載到內存中,之後再執行 EditLog 文件中的各項操作,使得內存中的元數據和實際的同步,存在內存中的元數據支持客戶端的讀操作。
-
一旦在內存中成功建立文件系統元數據的映射,則創建一個新的 FsImage 文件和一個空的 EditLog 文件。
-
名稱節點起來之後,HDFS 中的更新操作會重新寫到 EditLog 文件中,因爲 FsImage 文件一般都很大(GB 級別的很常見),如果所有的更新操作都往 FsImage 文件中添加,這樣會導致系統運行的十分緩慢,但是,如果往 EditLog 文件裏面寫就不會這樣,因爲 EditLog 要小很多。每次執行寫操作之後,且在向客戶端發送成功代碼之前,edits 文件都需要同步更新。
名稱節點運行期間 Editlog 不斷變大的問題:
-
在名稱節點運行期間,HDFS 的所有更新操作都是直接寫到 EditLog 中,久而久之, EditLog 文件將會變得很大。
-
雖然這對名稱節點運行時候是沒有什麼明顯影響的,但是,當名稱節點重啓的時候,名稱節點需要先將 FsImage 裏面的所有內容映像到內存中,然後再一條一條地執行 EditLog 中的記錄,當 EditLog 文件非常大的時候,會導致名稱節點啓動操作非常慢,而在這段時間內 HDFS 系統處於安全模式,一直無法對外提供寫操作,影響了用戶的使用。
如何解決?答案是:SecondaryNameNode 第二名稱節點
第二名稱節點是 HDFS 架構中的一個組成部分,它是用來保存名稱節點中對 HDFS 元數據信息的備份,並減少名稱節點重啓的時間。SecondaryNameNode 一般是單獨運行在一臺機器上。
SecondaryNameNode 的工作情況:
(1)SecondaryNameNode 會定期和 NameNode 通信,請求其停止使用 EditLog 文件,暫時將新的寫操作寫到一個新的文件 edit.new 上來,這個操作是瞬間完成,上層寫日誌的函數完全感覺不到差別;
(2)SecondaryNameNode 通過 HTTP GET 方式從 NameNode 上獲取到 FsImage 和 EditLog 文件,並下載到本地的相應目錄下;
(3)SecondaryNameNode 將下載下來的 FsImage 載入到內存,然後一條一條地執行 EditLog 文件中的各項更新操作,使得內存中的 FsImage 保持最新;這個過程就是 EditLog 和 FsImage 文件合併;
(4)SecondaryNameNode 執行完(3)操作之後,會通過 post 方式將新的 FsImage 文件發送到 NameNode 節點上 (5)NameNode 將從 SecondaryNameNode 接收到的新的 FsImage 替換舊的 FsImage 文件,同時將 edit.new 替換 EditLog 文件,通過這個過程 EditLog 就變小了。
數據節點:
-
數據節點是分佈式文件系統 HDFS 的工作節點,負責數據的存儲和讀取,會根據客戶端或者是名稱節點的調度來進行數據的存儲和檢索,並且向名稱節點定期發送自己所存儲的塊的列表。
-
每個數據節點中的數據會被保存在各自節點的本地 Linux 文件系統中。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/YO__G46LzDu2uqAWW544wQ