大數據底層技術的三大基石起源于Google在2006年之前的三篇論文GFS、Map-Reduce、 Bigtable，其中GFS、Map-Reduce技術直接支持了Apache Hadoop項目的誕生，Bigtable催生了NoSQL這個嶄新的數據庫領域如Hbase，由于map-Reduce處理框架高延時的缺陷， Google在2009年后推出的Dremel促使了實時計算系統的興起，以此引發大數據第二波技術浪潮，一些大數據公司紛紛推出自己的大數據查詢分析產品，如：Cloudera開源了大數據查詢分析引擎Impala、Hortonworks開源了?Stinger、Fackbook開源了Presto、UC Berkeley AMPLAB實驗室開發了Spark內存迭代式計算框架，所有這些技術的數據來源均基于hdsf, 對于 hdsf?最基本的不外乎就是其讀寫操作。

目錄：

• hdfs 名詞解釋
• hdsf 架構
• NameNode(NN)
• Secondary NN
• hdfs 寫文件
• hdfs 讀文件
• block持久化結構

HDFS名詞解釋：

---

• Block：?在HDFS中，每個文件都是采用的切分塊的方式存儲，每個block放在不同的datanode上，每個block的標識是一個三元組(block id，?numBytes，generationStamp)，其中block id是具有唯一性，具體分配是由namenode節點設置，然后再由datanode上建立block文件，同時建立對應block meta文件
• Packet：在DFSclient與DataNode之間通信的過程中，發送和接受數據過程都是以一個packet為基礎的方式進行
• Chunk：中文名字也可以稱為塊，但是為了與block區分，還是稱之為chunk。在DFSClient與DataNode之間通信的過程中，由于文件采用的是基于塊的方式來進行的，但是在發送數據的過程中是以packet的方式來進行的，每個packet包含了多個chunk，同時對于每個chunk進行checksum計算，生成checksum bytes
• 小結：

一個文件被切分成多個block塊持久化存儲(block size 由配置文件參數決定) ??思考： 修改 block size 對以前持續化的數據有何影響?

數據通訊過程中一個 block 被拆成 多個 packet

一個 packet 包含多個 chunk

• Packet結構與定義：?Packet分為兩類，一類是實際數據包，另一類是heatbeat包。一個Packet數據包的組成結構，如圖所示
• 上圖中，一個Packet是由Header和Data兩部分組成，其中Header部分包含了一個Packet的概要屬性信息，如下表所示：
• Data部分是一個Packet的實際數據部分，主要包括一個4字節校驗和(Checksum)與一個Chunk部分，Chunk部分最大為512字節。
• 在構建一個Packet的過程中，首先將字節流數據寫入一個buffer緩沖區中，也就是從偏移量為25的位置(checksumStart)開始寫Packet數據Chunk的Checksum部分，從偏移量為533的位置(dataStart)開始寫Packet數據的Chunk Data部分，直到一個Packet創建完成為止。
• 當寫一個文件的最后一個Block的最后一個Packet時，如果一個Packet的大小未能達到最大長度，也就是上圖對應的緩沖區中，Checksum與Chunk Data之間還保留了一段未被寫過的緩沖區位置，在發送這個Packet之前，會檢查Chunksum與Chunk Data之間的緩沖區是否為空白緩沖區(gap)，如果有則將Chunk Data部分向前移動，使得Chunk Data 1與Chunk Checksum N相鄰，然后才會被發送到DataNode節點。

hdsf架構：

---

• hdfs的構架圖網上一堆，抓了一張表述比較清楚的圖如下, 主要包含因類角色：Client、NameNode、SecondayNameNode、DataNode
• HDFS Client:?系統使用者，調用HDFS API操作文件;與NN交互獲取文件元數據;與DN交互進行數據讀寫,?注意：寫數據時文件切分由Client完成?
• Namenode：Master節點(也稱元數據節點)，是系統唯一的管理者。負責元數據的管理(名稱空間和數據塊映射信息)；配置副本策略；處理客戶端請求
• Datanode：數據存儲節點(也稱Slave節點)，存儲實際的數據；執行數據塊的讀寫；匯報存儲信息給NN
• Secondary NameNode：小弟角色，分擔大哥namenode的工作量；是NameNode的冷備份；合并fsimage和fsedits然后再發給namenode,?注意：在hadoop 2.x 版本，當啟用 hdfs ha 時，將沒有這一角色。
• 解釋說明：

熱備份：b是a的熱備份，如果a壞掉。那么b馬上運行代替a的工作

冷備份：b是a的冷備份，如果a壞掉。那么b不能馬上代替a工作。但是b上存儲a的一些信息，減少a壞掉之后的損失

• hdfs構架原則：

元數據與數據分離：文件本身的屬性(即元數據)與文件所持有的數據分離

主/從架構：一個HDFS集群是由一個NameNode和一定數目的DataNode組成

一次寫入多次讀取：HDFS中的文件在任何時間只能有一個Writer。當文件被創建，接著寫入數據，最后，一旦文件被關閉，就不能再修改。

移動計算比移動數據更劃算：數據運算，越靠近數據，執行運算的性能就越好，由于hdfs數據分布在不同機器上，要讓網絡的消耗最低，并提高系統的吞吐量，最佳方式是將運算的執行移到離它要處理的數據更近的地方，而不是移動數據

NameNode:

---

• NameNode是整個文件系統的管理節點，也是HDFS中最復雜的一個實體，它維護著HDFS文件系統中最重要的兩個關系：

HDFS文件系統中的文件目錄樹，以及文件的數據塊索引，即每個文件對應的數據塊列表

數據塊和數據節點的對應關系，即某一塊數據塊保存在哪些數據節點的信息

• 第一個關系即目錄樹、元數據和數據塊的索引信息會持久化到物理存儲中，實現是保存在命名空間的鏡像fsimage和編輯日志edits中，注意：在fsimage中，并沒有記錄每一個block對應到哪幾個Datanodes的對應表信息
• 第二個關系是在NameNode啟動后，每個Datanode對本地磁盤進行掃描，將本Datanode上保存的block信息匯報給Namenode，Namenode在接收到每個Datanode的塊信息匯報后，將接收到的塊信息，以及其所在的Datanode信息等保存在內存中。HDFS就是通過這種塊信息匯報的方式來完成 block -> Datanodes list的對應表構建
• fsimage記錄了自最后一次檢查點之前HDFS文件系統中所有目錄和文件的序列化信息;
• edits是元數據操作日志(記錄每次保存fsimage之后到下次保存之間的所有hdfs操作)
• 在NameNode啟動時候，會先將fsimage中的文件系統元數據信息加載到內存，然后根據eidts中的記錄將內存中的元數據同步至最新狀態，將這個新版本的 FsImage 從內存中保存到本地磁盤上，然后刪除 舊的 Editlog，這個過程稱為一個檢查 點?(checkpoint)，?多長時間做一次 checkpoint？（見第四章 參數配置）?checkpoint 能手工觸發嗎？ 驗證重啟hdfs服務后editlog沒刪除呢？
• 類似于數據庫中的檢查點，為了避免edits日志過大，在Hadoop1.X中，SecondaryNameNode會按照時間閾值(比如24小時)或者edits大小閾值(比如1G)，周期性的將fsimage和edits的合并，然后將最新的fsimage推送給NameNode。而在Hadoop2.X中，這個動作是由Standby NameNode來完成.
• 由此可看出，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統不可用，集群安裝過程中，hdfs 默認的只能選擇一個NN，是否意味著NN存在單點呢？(見第二單 hdfs HA)
• 在hadoop1.X為了保證這兩種元數據文件的高可用性，一般的做法，將dfs.namenode.name.dir設置成以逗號分隔的多個目錄，這多個目錄至少不要在一塊磁盤上，最好放在不同的機器上，比如：掛載一個共享文件系統
• fsimage\edits 是序列化后的文件，想要查看或編輯里面的內容，可通過?hdfs 提供的 oiv\oev?命令，如下：
  • 命令:?hdfs oiv （offline image viewer）?用于將fsimage文件的內容轉儲到指定文件中以便于閱讀,，如文本文件、XML文件，該命令需要以下參數：
    • -i? (必填參數)? –inputFile <arg>? 輸入FSImage文件
    • -o (必填參數)? –outputFile <arg> 輸出轉換后的文件，如果存在，則會覆蓋
    • -p (可選參數）?–processor <arg>?? 將FSImage文件轉換成哪種格式： (Ls|XML|FileDistribution).默認為Ls
    • 示例：hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt
• • 命令：hdfs oev?(offline edits viewer 離線edits查看器）的縮寫， 該工具只操作文件因而并不需要hadoop集群處于運行狀態。
    • 示例:??hdfs oev -i edits_0000000000000042778-0000000000000042779 -o edits.xml
    • 支持的輸出格式有binary（hadoop使用的二進制格式）、xml（在不使用參數p時的默認輸出格式）和stats（輸出edits文件的統計信息）
• 小結：

NameNode管理著DataNode，接收DataNode的注冊、心跳、數據塊提交等信息的上報，并且在心跳中發送數據塊復制、刪除、恢復等指令；同時，NameNode還為客戶端對文件系統目錄樹的操作和對文件數據讀寫、對HDFS系統進行管理提供支持

Namenode 啟動后會進入一個稱為安全模式的特殊狀態。處于安全模式 的 Namenode 是不會進行數據塊的復制的。 Namenode 從所有的?Datanode 接收心跳信號和塊狀態報告。塊狀態報告包括了某個 Datanode 所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當 Namenode 檢測確認某個數據塊的副本數目達到這個最小值，那么該數據塊就會被認為是副本安全(safely replicated) 的；在一定百分比(這個參數可配置)的數據塊被 Namenode 檢測確認是安全之后(加上一個額外的 30 秒等待時間)， Namenode 將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒 有達到指定數目，并將這些數據塊復制到其他 Datanode 上。

Secondary NameNode：在HA cluster中又稱為standby node

---

• 定期合并 fsimage 和 edits 日志，將 edits 日志文件大小控制在一個限度下
• namenode 響應 Secondary namenode 請求，將 edit log 推送給 Secondary namenode ， 開始重新寫一個新的 edit log
• Secondary namenode 收到來自 namenode 的 fsimage 文件和 edit log
• Secondary namenode 將 fsimage 加載到內存，應用 edit log ， 并生成一 個新的 fsimage 文件
• Secondary namenode 將新的 fsimage 推送給 Namenode
• Namenode 用新的 fsimage 取代舊的 fsimage ， 在 fstime 文件中記下檢查 點發生的時

?HDFS寫文件：

---

• 寫文件部分參考blog 地址 （http://www.cnblogs.com/laov/p/3434917.html），2.X版本默認block的大小是 128M?（見第四章參數配置）

Client將FileA按64M切塊。分成兩塊，block1和Block2;

Client向nameNode發送寫數據請求，如圖藍色虛線①------>

NameNode節點，記錄block信息。并返回可用的DataNode (NameNode按什么規則返回DataNode? 參見第三單 hadoop機架感知），如粉色虛線②--------->

• Block1: host2,host1,host3
• Block2: host7,host8,host4

client向DataNode發送block1；發送過程是以流式寫入，流式寫入過程如下：

將64M的block1按64k的packet劃分

然后將第一個packet發送給host2

host2接收完后，將第一個packet發送給host1，同時client想host2發送第二個packet

host1接收完第一個packet后，發送給host3，同時接收host2發來的第二個packet

以此類推，如圖紅線實線所示，直到將block1發送完畢

host2,host1,host3向NameNode，host2向Client發送通知，說“消息發送完了”。如圖粉紅顏色實線所示

client收到host2發來的消息后，向namenode發送消息，說我寫完了。這樣就真完成了。如圖黃色粗實線

發送完block1后，再向host7，host8，host4發送block2，如圖藍色實線所示

• ?說明：

當客戶端向 HDFS 文件寫入數據的時候，一開始是寫到本地臨時文件中。假設該文件的副 本系數設置為 3 ，當本地臨時文件累積到一個數據塊的大小時，客戶端會從 Namenode 獲取一個 Datanode 列表用于存放副本。然后客戶端開始向第一個 Datanode 傳輸數據，第一個 Datanode 一小部分一小部分 (4 KB) 地接收數據，將每一部分寫入本地倉庫，并同時傳輸該部分到列表中 第二個 Datanode 節點。第二個 Datanode 也是這樣，一小部分一小部分地接收數據，寫入本地 倉庫，并同時傳給第三個 Datanode 。最后，第三個 Datanode 接收數據并存儲在本地。因此， Datanode 能流水線式地從前一個節點接收數據，并在同時轉發給下一個節點，數據以流水線的 方式從前一個 Datanode 復制到下一個

時序圖如下：

• ?小結：

寫入的過程，按hdsf默認設置，1T文件，我們需要3T的存儲，3T的網絡流量

在執行讀或寫的過程中，NameNode和DataNode通過HeartBeat進行保存通信，確定DataNode活著。如果發現DataNode死掉了，就將死掉的DataNode上的數據，放到其他節點去。讀取時，要讀其他節點去

掛掉一個節點，沒關系，還有其他節點可以備份；甚至，掛掉某一個機架，也沒關系；其他機架上，也有備份

hdfs讀文件：?

---

• ?讀到文件示意圖如下：
• 客戶端通過調用FileSystem對象的open()方法來打開希望讀取的文件，對于HDFS來說，這個對象時分布文件系統的一個實例；
• DistributedFileSystem通過使用RPC來調用NameNode以確定文件起始塊的位置，同一Block按照重復數會返回多個位置，這些位置按照Hadoop集群拓撲結構排序，距離客戶端近的排在前面 (詳見第三章）
• 前兩步會返回一個FSDataInputStream對象，該對象會被封裝成DFSInputStream對象，DFSInputStream可以方便的管理datanode和namenode數據流，客戶端對這個輸入流調用read()方法
• 存儲著文件起始塊的DataNode地址的DFSInputStream隨即連接距離最近的DataNode，通過對數據流反復調用read()方法，將數據從DataNode傳輸到客戶端
• 到達塊的末端時，DFSInputStream會關閉與該DataNode的連接，然后尋找下一個塊的最佳DataNode，這些操作對客戶端來說是透明的，客戶端的角度看來只是讀一個持續不斷的流
• 一旦客戶端完成讀取，就對FSDataInputStream調用close()方法關閉文件讀取

block持久化結構:

---

• ?DataNode節點上一個Block持久化到磁盤上的物理存儲結構，如下圖所示：
• 每個Block文件（如上圖中blk_1084013198文件）都對應一個meta文件（如上圖中blk_1084013198_10273532.meta文件），Block文件是一個一個Chunk的二進制數據（每個Chunk的大小是512字節），而meta文件是與每一個Chunk對應的Checksum數據，是序列化形式存儲。

轉載于:https://www.cnblogs.com/sky-sql/p/6881757.html

總結

以上是生活随笔為你收集整理的深度剖析hdfs原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。