HDFS 技術原理(上)

HDFS 概述及應用場景

HDFS 概述:

HDFS(Hadoop Distributed File System) 基於 Google 發佈的 GFS 論文設計開發,運行在通用硬件平臺上的分佈式文件系統。

其除具有其他分佈式文件系統的相同特性外,還有自己特有的特性:

  1. 高容錯性:認爲硬件總是不可靠的。

  2. 高吞吐量:爲大量數據訪問的應用提供高可用吞吐量支持。

  3. 大文件存儲:支持存儲 TB-PB 級別的數據。

HDFS 適合做:大文件存儲、流式數據訪問。

HDFS 不適合做:大量小文件、隨機寫入、低延遲讀取。

HDFS 應用場景舉例:

HDFS 是 Hadoop 技術框架中的分佈式文件系統,對部署在多臺獨立物理機器上的文件進行管理。

可應用與以下幾種場景:

  1. 網站用戶行爲數據存儲。

  2. 生態系統數據存儲。

  3. 氣象數據存儲。

HDFS 在 FusionInsight 產品的位置:

HDFS 位置

圖:HDFS 在 FusionInsight 產品中的位置

FusionInsight HD 提供大數據處理環境,基於社區開源軟件增強,按照場景選擇業界最佳實踐。

HDFS 作爲 Hadoop 的基礎存儲設施,實現了一個分佈式、高容錯、可線性擴展的文件系統。

HDFS 系統架構

系統設計目標:

(1)硬件失效:

(2)流式數據訪問:

(3)存儲數據大:

(4)數據一致性:

(5)多硬件平臺:

(6)移動計算能力:

基本系統架構:

HDFS 架構

圖:HDFS 系統架構圖

HDFS 架構包含三個部分:(NameNode,DateNode,Client)

  1. NameDode:用於存儲、生成文件系統的元數據、運行一個實例。

  2. DateNode:用於存儲實際的數據,將自己管理的數據塊上報給 NameNode,運行多個實例。

  3. Client:支持業務訪問 HDFS,從 NameNode,DateNode 獲取數據返回給業務。多個實例,和業務一起運行。

HDFS 數據寫入流程:

HDFS 寫入流程

圖:HDFS 數據寫入流程圖

HDFS 數據寫入流程如下:

  1. 業務應用調用 HDFS Client 提供的 API 創建文件,請求寫入。

  2. HDFS Client 聯繫 NameNode,NameNode 在元數據中創建文件節點。

  3. 業務應用調用 write API 寫入文件。

  4. HDFS Client 收到業務數據後,從 NameNode 獲取到數據塊編號、位置信息後,聯繫 DateNode,並將要寫入數據的 DateNode 建立起流水線。完成後,客戶端再通過自有協議寫入數據到 DateNode1,再由 DateNode1 複製到 NateNode2,DateNode3.

  5. 寫完的數據,將返回確認信息給 HDFS Client。

  6. 所有數據確認完成後,業務調用 HDFS CLient 關閉文件。

  7. 業務調用 close,flush 後 HDFS Client 聯繫 NameNode,確認數據寫完成,NameNode 持久化元數據。

HDFS 數據讀取流程:

HDFS 數據讀取

圖:HDFS 數據讀取流程圖

HDFS 數據讀取流程如下:

  1. 業務調用 HDFS Client 提供的 API 打開文件。

  2. HDFS Client 聯繫 NmaeNode,獲取到文件信息(數據塊、DateNode 位置信息)。

  3. 業務應用調用 read API 讀取文件。

  4. HDFS Client 根據從 NmaeNode 獲取到的信息,聯繫 DateNode,獲取相應的數據塊。(Client 採用就近原則讀取數據)。

  5. HDFS Client 會與多個 DateNode 通訊獲取數據塊。

  6. 數據讀取完成後,業務調用 close 關閉連接。

HDFS 關鍵特性介紹

HDFS 架構關鍵設計:

關鍵特性

圖:HDFS 架構關鍵設計

元數據持久化:

元數據持久 haul

圖:元數據持久化流程圖

元數據持久化流程如下:

  1. 備 NmaeNode 通知主 NameNode 生成新的日誌文件,以後的日誌寫到 Editlog.new 中,並獲取舊的 Editlog。

  2. 備 NameNode 從注 NameNode 上獲取 FSImage 文件及位於 JournalNode 上面的舊 Editlog。

  3. 備 NmaeNode 將日誌和舊的元數據合併,生成新的元數據 FSImage.ckpt。

  4. 備 NameNode 將元數據上傳到主 NameNode。

  5. 主 NameNode 將上傳的原書記進行回滾。

  6. 循環步驟 1.

元數據持久化健壯機制:

HDFS 主要目的是保證存儲數據完整性,對於各組件的失效,做了可靠性處理。

HDFS 高可靠性 (HA):

HDFS 高可靠性

圖;HDFS 高可靠性原理

HA 解決的是一個熱備份的問題。

HDFS 的高可靠性(HA)架構在基本架構上增加了一下組件:


HA

圖:HA 原理

處於待命狀態的名稱節點和處於活狀態的名稱節點,它們元數據的兩個方面的信息是怎麼同步的:

處於待命狀態的名稱節點當中,它的兩方面元數據,一個就是 Editlog,它是通過共享存儲系統來獲得同步的,處於活躍狀態的名稱節點已發生變化,馬上寫入到共享存儲系統,然後這共享存儲系統會通知待命的名稱節點把它取走,這樣可以保證 Editlog 上兩者可以保持同步。對於映射表信息而言,也就是一個文件包含幾個塊,這些塊被保存到哪個數據節點上面。這種映射信息,它的 實時的維護是通過底層數據節點,不斷同時向活躍名稱節點和待命節點名稱節點彙報來進行維護的。這就是它的基本原理。

HDFS 聯邦(Federation):

聯邦

圖;HDFS 聯邦

HDFS Federation 主要能夠解決,單名稱節點中存在的以下問題:

  1. HDFS 集羣的擴展性問題。

    有了多個名稱節點,每個名稱節點都可以各自的去管理一部分目錄。管理自己對應的子命名空間的子目錄,這樣就可以讓一個集羣擴展到更多節點。

    在 HDFS1.0 中會受到內存的限制,制約文件存儲數目等限制。一個名稱節點存儲的文件數目是有限的。

  2. 性能更高效

    多個名稱節點各自都管理它不同的數據,而且可以同時對外服務,所以可以提供更高的數據的吞吐率。

  3. 良好的隔離性

    因爲它已經根據不同業務數據要求,進行了子空間的劃分,某種業務數據可能歸某個名稱節點管理,另外一種業務數據屬於另外一個命名空間,歸另外一個名稱節點管理。所以不同數據都分給不同名稱節點去管理,這樣就可以有效地對不同應用程序進行隔離。不會導致一個應用程序消耗過多資源,而影響另外一個應用程序運行的問題。

HDFS 不能解決單點故障問題。

數據副本機制:

數據副本機制

圖:數據副本機制

副本距離計算公式:

副本放置策略:

  1. 第一個副本在本地機器。

  2. 第二個副本在遠端機架的節點。

  3. 第三個副本看之前連個副本是否在同一機架,如果是則選擇其他機架,否則選擇和第一個副本相同機架的不同節點。

  4. 第四個及以上,隨機選擇副本存放位置。

配置 HDFS 數據存儲策略:

默認情況下,HDFS NmaeNode 自動選擇 DateNode 保存數據的副本。在實際義務中,存在以下場景:

配置 DateNode 使用分級存儲:

存儲策略

配置標籤存儲策略:

標籤存儲

圖;標籤存儲策略

配置 DateNode 使用標籤存儲:

用戶通過數據特徵靈活配置 HDFS 數據塊存放策略,即爲一個 HDFS 目錄設置一個標籤表達式,每個 DateNode 可以對應一個或多個標籤;當基於標籤的數據塊存放策略爲指定目錄下的文件選擇 DateNode 節點進行存放時,根據文件的標籤表達式選擇出將要存放的 DateNode 節點範圍,然後在這個 DateNode 節點範圍內,遵守下一個指定的數據塊存放策略進行存放。

配置 DateNode 使用節點組存儲:

節點組存儲

圖:節點組存儲

配置 DateNode 使用節點組存儲:

關鍵數據根據實際業務需要保存在具有高度可靠性的節點中,此時 DateNode 組成了異構集羣。通過修改 DateNode 的存儲策略,系統可以將數據強制保存在指定的節點組中。

使用約束:

  1. 第一份副本將從強制機架組(機架組 2)中選出,如果在強制機架組中沒用可用節點,則寫入失敗。

  2. 第二份副本將從本地客戶端機器或機架組中的隨機節點(當客戶端機架組不爲強制機架組時)選出。

  3. 第三份副本將從其他機架組中選出。

  4. 各副本應放在不同的機架組中。如果所需副本的數量大於可用的機架組數量,則會將多出的副本存放在隨機機架組中。

Colocation 同分布:

同分布(Colocation)的定義:將存在關聯關係的數據或可能要進行關聯操作的數據存儲在相同的存儲節點上。

按照下圖存放,假設要將文件 A 和文件 D 進行關聯操作,此時不可避免地要進行大量的數據搬遷,整個集羣將由於數據傳輸佔用大量網絡帶寬,嚴重影響大數據的處理速度與系統性能。

NN


HDFS 文件同分布的特性,將那些需要進行關聯操作的文件存放在相同的數據節點上,在進行關聯操作計算是避免了到其他數據節點上獲取數據,大大降低了網絡帶寬的佔用。

使用同分布特性,文件 A、D 進行 join 時,由於其對應的 block 都在相同的節點,因此大大降低了資源消耗。如下圖:

效果他

圖:Colocation 同分布效果圖

HDFS 架構其他關鍵設計要點說明:

常用的 shell 命令:

shell

HDFS 主要組件的功能

iexg9S

名稱節點的數據結構:

  1. FsImage 用於維護文件系統樹以及文件樹中所有的文件和文件夾的元數據

  2. 操作日誌文件 EditLog 中記錄了所有針對文件的創建、刪除、重命名等操作

名稱節點數據結構

圖:名稱節點的數據結構

FsImage 文件:

FsImage 文件包含文件系統中所有目錄和文件 inode 的序列化形式。每個 inode 是一個文件或目錄的元數據的內部表示,幷包含此類信息:文件的複製等級、修改和訪問時間、訪問權限、塊大小以及組成文件的塊。對於目錄,則存儲修改時間、權限和配額元數據.

FsImage 文件沒有記錄塊存儲在哪個數據節點。而是由名稱節點把這些映射保留在內存中,當數據節點加入 HDFS 集羣時,數據節點會把自己所包含的塊列表告知給名稱節點,此後會定期執行這種告知操作,以確保名稱節點的塊映射是最新的。

名稱節點的啓動:

名稱節點運行期間 Editlog 不斷變大的問題:

如何解決?答案是: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 就變小了。

數據節點:

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/YO__G46LzDu2uqAWW544wQ