大數(shù)據(jù) | HDFS 元數(shù)據(jù)持久化筆記
早期文章
一、HDFS 架構(gòu)簡單介紹
? ? ? ? HDFS 是一個(gè)主從（Master/Slaves）的架構(gòu)，它由一個(gè) NameNode 和一些 DataNode 組成。其中，NameNode 是主，DataNode 是從。文件元數(shù)據(jù)由 NameNode 負(fù)責(zé)存儲(chǔ)和管理，且它維護(hù)了一個(gè)層次型的文件目錄樹；文件的數(shù)據(jù)由 DataNode 來按照 block 進(jìn)行存儲(chǔ)，并按照 block?進(jìn)行讀寫。DataNode 與 NameNode 通過心跳來維持，DataNode 會(huì)向 NameNode 匯報(bào)自己持有的?block 信息。當(dāng)客戶端和 NameNode 交互文件元數(shù)據(jù)，和 DataNode 交互 block 數(shù)據(jù)。
二、角色功能
? ? ? ? 從 HDFS 的架構(gòu)來看，它包含兩個(gè)重要的角色，分別是 NameNode 和 DataNode。其中，NameNode 完全基于內(nèi)存存儲(chǔ)文件元數(shù)據(jù)、目錄結(jié)構(gòu)、文件 block 的映射，因此，它需要持久化方案來保證數(shù)據(jù)的可靠性；DataNode 基于磁盤存儲(chǔ) block，并保存了 block 的校驗(yàn)，從而保證 block 的可靠性；DataNode 和 NameNode 之間通過心跳保持，并向 NameNode 匯報(bào) block 狀態(tài)。
三、常用的持久化方案
? ? ? ? 很多基于內(nèi)存的存儲(chǔ)，在使用持久化時(shí)，持久化方案通常有幾種方案，包括日志文件、內(nèi)存 Dump 和?兩種的混合方式。先來說一下比較常用的緩存系統(tǒng) —— Redis。Redis 的持久化方式分為 AOF、RDB 和 混合方式。Redis 的 AOF 屬于日志記錄文件，它會(huì)記錄每條命令到文本文件中，RDB 屬于內(nèi)存 Dump 的方式，它會(huì)全量的保存內(nèi)存的信息，混合方式是 AOF 和 RDB 兩者共用的方式。（Redis 為了解決 AOF 體積的問題，提供了 AOF 重寫的命令）
四、HDFS 元數(shù)據(jù)的持久化
? ? ? ? ?NameNode 基于內(nèi)存存儲(chǔ)文件元數(shù)據(jù)、目錄結(jié)構(gòu)、文件 block 的映射等信息，為了保障其可靠性，需要對(duì)其進(jìn)行持久化。日志文件的方式 和 內(nèi)存 Dump 都有其相應(yīng)的優(yōu)勢與劣勢，因此 HDFS 也使用了混合的方式。HDFS 同樣也同時(shí)使用了這兩種方式，其 日志記錄?方式被稱為 EditsLog，其內(nèi)存 Dump 方式被稱為 FsImage。因?yàn)?EditsLog 和 FsImage 也存在 日志記錄 和 內(nèi)存 Dump 的固有的缺點(diǎn)，因此兩種方式都使用，來彌補(bǔ)對(duì)方的缺點(diǎn)。
? ? ? ? FsImage 嚴(yán)格來講算不上是一個(gè)?內(nèi)存 Dump，因?yàn)?FsImage 的創(chuàng)建是在部署完 HDFS 后格式化時(shí)生成的。在 NameNode 第一次啟動(dòng)時(shí)讀取的是一個(gè)空的 FsImage 文件（當(dāng)然，它可能有它的內(nèi)部結(jié)構(gòu)，但是此時(shí)它不包含元數(shù)據(jù)等信息）。在之后的 NameNode 啟動(dòng)時(shí)，會(huì)去讀 EditsLog 和 FsImage，此時(shí)會(huì)將所有的 EditsLog 中的記錄作用在內(nèi)存中的 FsImage 上，并將新版本的 FsImage 從內(nèi)存中保存到磁盤上，然后刪除舊的 EditsLog 文件。通過這種方式，HDFS 的內(nèi)存中就得到了上次關(guān)機(jī)時(shí)的全量數(shù)據(jù)。
? ? ? ? FsImage 需要滾動(dòng)更新，F(xiàn)sImage 的滾動(dòng)更新并非進(jìn)行 內(nèi)存 Dump，而是通過當(dāng)前 FsImage 文件和增量的 EditsLog 文件形成新的 FsImage 文件，然后將新的 FsImage 替換舊的 FsImage 文件。而增量的 EditsLog 文件則被刪除，重新記錄新的 EditsLog 文件。
? ? ? ? 注意：NameNode 持久化不包含每個(gè)文件的塊的位置，因?yàn)槲募K的位置由 DataNode 主動(dòng)進(jìn)行上報(bào)。
五、Secondary NameNode 的引入
? ? ? ??由于滾動(dòng)更新 FsImage 文件，也是比較耗時(shí)耗力的原因，HDFS 給 NameNode 提供了一個(gè)秘書，即 Secondary NameNode。Secondary NameNode 并非是第二個(gè) NameNode，因?yàn)樗淮鎯?chǔ)元數(shù)據(jù)，它的作用是完成 FsImage 和 EditsLog 的合并。通常 Secondary NameNode 和 NameNode 不在同一主機(jī)。Secondary NameNode 通過 http get 方式獲取 NameNode 主機(jī)上的 FsImage 和 EditsLog，合并后通過 http post 方式提交給 NameNode，從而生成新的 FsImage 文件。
? ? ? ??當(dāng) Secondary NameNode 將 EditsLog 拉取以后，NameNode 會(huì)將將新的日志記錄到新的 EditsLog 中。
六、總結(jié)
? ? ? ? 學(xué)習(xí) HDFS 持久化時(shí)，想到了 Redis 的持久化，因?yàn)楹芏嗉夹g(shù)的實(shí)現(xiàn)不同，但是它們在理論上幾乎是相同的，或者是變通的。這里通過類比的方式，感覺理解其他技術(shù)時(shí)就會(huì)容易一些。上面總結(jié)了 HDFS 的 主/從架構(gòu)，即 NameNode 和 DataNode，其在 HA 模式下還有主備的概念，涉及到選主的一致性算法等知識(shí)，之后再進(jìn)行整理，希望喜歡的讀者可以給點(diǎn)贊、關(guān)注！
公眾號(hào)內(nèi)回復(fù)?【mongo】 下載 SpringBoot 整合操作 MongoDB 的文檔。
? ? ? ? 之前整理的關(guān)于 Redis 的文章：
Redis | Redis Pub/Sub相關(guān)命令
Redis | 基礎(chǔ)數(shù)據(jù)類型應(yīng)用場景