hadoop:hdfs的講解

轉載自：http://www.cnblogs.com/tgzhu/p/5788634.html  

在配置hbase集羣將 hdfs 掛接到其它鏡像盤時，有很多困惑的地方，結合之前的資料再次學習;  大數據底層技術的三大基石起源於Google在2006年以前的三篇論文GFS、Map-Reduce、 Bigtable，其中GFS、Map-Reduce技術直接支持了Apache Hadoop項目的誕生，Bigtable催生了NoSQL這個嶄新的數據庫領域，因爲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
• 小結：

1. 1. 一個文件被拆成多個block持續化存儲（block size 由配置文件參數決定）   思考： 修改 block size 對之前持續化的數據有何影響?
   2. 數據通信過程當中一個 block 被拆成 多個 packet
   3. 一個 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 時，將沒有這一角色。（詳見第二單）
• 解釋說明：

1. 1. 熱備份：b是a的熱備份，若是a壞掉。那麼b立刻運行代替a的工做
   2. 冷備份：b是a的冷備份，若是a壞掉。那麼b不能立刻代替a工做。可是b上存儲a的一些信息，減小a壞掉以後的損失

• hdfs構架原則：

1. 1. 元數據與數據分離：文件自己的屬性（即元數據）與文件所持有的數據分離
   2. 主/從架構：一個HDFS集羣是由一個NameNode和必定數目的DataNode組成
   3. 一次寫入屢次讀取：HDFS中的文件在任什麼時候間只能有一個Writer。當文件被建立，接着寫入數據，最後，一旦文件被關閉，就不能再修改。
   4. 移動計算比移動數據更划算：數據運算，越靠近數據，執行運算的性能就越好，因爲hdfs數據分佈在不一樣機器上，要讓網絡的消耗最低，並提升系統的吞吐量，最佳方式是將運算的執行移到離它要處理的數據更近的地方，而不是移動數據

NameNode:

---

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

1. 1. HDFS文件系統中的文件目錄樹，以及文件的數據塊索引，即每一個文件對應的數據塊列表
   2. 數據塊和數據節點的對應關係，即某一塊數據塊保存在哪些數據節點的信息

• 第一個關係即目錄樹、元數據和數據塊的索引信息會持久化到物理存儲中，實現是保存在命名空間的鏡像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文件系統不可用，在HDP2.4安裝(五)：集羣及組件安裝  集羣安裝過程當中，hdfs 默認的只能選擇一個NN，是否意味着NN存在單點呢？(見第二單 hdfs HA)
• 在hadoop1.X爲了保證這兩種元數據文件的高可用性，通常的作法，將dfs.namenode.name.dir設置成以逗號分隔的多個目錄，這多個目錄至少不要在一塊磁盤上，最好放在不一樣的機器上，好比：掛載一個共享文件系統
• fsimage\edits 是序列化後的文件，想要查看或編輯裏面的內容，可經過 hdfs 提供的 oiv\oev 命令，以下：
  • 命令: hdfs oiv （offline image viewer） 用於將fsimage文件的內容轉儲到指定文件中以便於閱讀,，如文本文件、XML文件，該命令須要如下參數：
  1. 1. -i  (必填參數)  –inputFile <arg>  輸入FSImage文件
     2. -o (必填參數)  –outputFile <arg> 輸出轉換後的文件，若是存在，則會覆蓋
     3. -p (可選參數） –processor <arg>   將FSImage文件轉換成哪一種格式： (Ls|XML|FileDistribution).默認爲Ls
     4. 示例：hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt
  • 命令：hdfs oev (offline edits viewer 離線edits查看器）的縮寫， 該工具只操做文件於是並不須要hadoop集羣處於運行狀態。
  1. 1. 示例:  hdfs oev -i edits_0000000000000042778-0000000000000042779 -o edits.xml
     2. 支持的輸出格式有binary（hadoop使用的二進制格式）、xml（在不使用參數p時的默認輸出格式）和stats（輸出edits文件的統計信息）
• 小結：

1. NameNode管理着DataNode，接收DataNode的註冊、心跳、數據塊提交等信息的上報，而且在心跳中發送數據塊複製、刪除、恢復等指令；同時，NameNode還爲客戶端對文件系統目錄樹的操做和對文件數據讀寫、對HDFS系統進行管理提供支持
2. 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 （見第四章參數配置）

1. Client將FileA按64M分塊。分紅兩塊，block1和Block2;
2. Client向nameNode發送寫數據請求，如圖藍色虛線①------>
3. NameNode節點，記錄block信息。並返回可用的DataNode (NameNode按什麼規則返回DataNode? 參見第三單 hadoop機架感知），如粉色虛線②--------->
   • Block1: host2,host1,host3
   • Block2: host7,host8,host4
4. client向DataNode發送block1；發送過程是以流式寫入，流式寫入過程以下：
1. 將64M的block1按64k的packet劃分
2. 而後將第一個packet發送給host2
3. host2接收完後，將第一個packet發送給host1，同時client想host2發送第二個packet
4. host1接收完第一個packet後，發送給host3，同時接收host2發來的第二個packet
5. 以此類推，如圖紅線實線所示，直到將block1發送完畢
6. host2,host1,host3向NameNode，host2向Client發送通知，說「消息發送完了」。如圖粉紅顏色實線所示
7. client收到host2發來的消息後，向namenode發送消息，說我寫完了。這樣就真完成了。如圖黃色粗實線
8. 發送完block1後，再向host7，host8，host4發送block2，如圖藍色實線所示

•  說明：

1. 1. 當客戶端向 HDFS 文件寫入數據的時候，一開始是寫到本地臨時文件中。假設該文件的副 本系數設置爲 3 ，當本地臨時文件累積到一個數據塊的大小時，客戶端會從 Namenode 獲取一個 Datanode 列表用於存放副本。而後客戶端開始向第一個 Datanode 傳輸數據，第一個 Datanode 一小部分一小部分 (4 KB) 地接收數據，將每一部分寫入本地倉庫，並同時傳輸該部分到列表中 第二個 Datanode 節點。第二個 Datanode 也是這樣，一小部分一小部分地接收數據，寫入本地 倉庫，並同時傳給第三個 Datanode 。最後，第三個 Datanode 接收數據並存儲在本地。所以， Datanode 能流水線式地從前一個節點接收數據，並在同時轉發給下一個節點，數據以流水線的 方式從前一個 Datanode 複製到下一個
   2. 時序圖以下：

•  小結：

1. 寫入的過程，按hdsf默認設置，1T文件，咱們須要3T的存儲，3T的網絡流量
2. 在執行讀或寫的過程當中，NameNode和DataNode經過HeartBeat進行保存通訊，肯定DataNode活着。若是發現DataNode死掉了，就將死掉的DataNode上的數據，放到其餘節點去。讀取時，要讀其餘節點去
3. 掛掉一個節點，不要緊，還有其餘節點能夠備份；甚至，掛掉某一個機架，也不要緊；其餘機架上，也有備份

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數據，是序列化形式存儲

-----------------漫畫版

根據Maneesh Varshney的漫畫改編，以簡潔易懂的漫畫形式講解HDFS存儲機制與運行原理。

1、角色出演

 

如上圖所示，HDFS存儲相關角色與功能以下：

 

Client：客戶端，系統使用者，調用HDFS API操做文件;與NN交互獲取文件元數據;與DN交互進行數據讀寫。

Namenode：元數據節點，是系統惟一的管理者。負責元數據的管理;與client交互進行提供元數據查詢;分配數據存儲節點等。

Datanode：數據存儲節點，負責數據塊的存儲與冗餘備份;執行數據塊的讀寫操做等。

2、寫入數據

一、發送寫數據請求

 

HDFS中的存儲單元是block。文件一般被分紅64或128M一塊的數據塊進行存儲。與普通文件系統不一樣的是，在HDFS中，若是一個文件大小小於一個數據塊的大小，它是不須要佔用整個數據塊的存儲空間的。

 

二、文件切分

 

三、DN分配

 

 

四、數據寫入

 

 

五、完成寫入

 

 

六、角色定位

 

 

 

3、HDFS讀文件

一、用戶需求

 

HDFS採用的是「一次寫入屢次讀取」的文件訪問模型。一個文件通過建立、寫入和關閉以後就不須要改變。這一假設簡化了數據一致性問題，而且使高吞吐量的數據訪問成爲可能。

 

二、先聯繫元數據節點

 

三、下載數據

 

 

前文提到在寫數據過程當中，數據存儲已經按照客戶端與DataNode節點之間的距離進行了排序，距客戶端越近的DataNode節點被放在最前面，客戶端會優先從本地讀取該數據塊。

 

四、思考

 

 

4、HDFS容錯機制——第一部分：故障類型及監測方法

一、三類故障

(1)第一類：節點失敗

 

(2)第二類：網絡故障

 

 

(3)第三類：數據損壞(髒數據)

 

 

二、故障監測機制

 

(1)節點失敗監測機制

 

(2)通訊故障監測機制

 

 

(3)數據錯誤監測機制

 

 

三、回顧：心跳信息與數據塊報告

 

 

HDFS存儲理念是以最少的錢買最爛的機器並實現最安全、難度高的分佈式文件系統(高容錯性低成本)，從上能夠看出，HDFS認爲機器故障是種常態，因此在設計時充分考慮到單個機器故障，單個磁盤故障，單個文件丟失等狀況。

 

5、容錯第二部分：讀寫容錯

一、寫容錯

 

二、讀容錯

 

 

 

6、容錯第三部分：數據節點(DN)失效

 

 

7、備份規則

 

一、機架與數據節點

 

 

二、副本放置策略

 

 

數據塊的第一個副本優先放在寫入數據塊的客戶端所在的節點上，可是若是這個客戶端上的數據節點空間不足或者是當前負載太重，則應該從該數據節點所在的機架中選擇一個合適的數據節點做爲本地節點。

 

若是客戶端上沒有一個數據節點的話，則從整個集羣中隨機選擇一個合適的數據節點做爲此時這個數據塊的本地節點。

 

HDFS的存放策略是將一個副本存放在本地機架節點上，另外兩個副本放在不一樣機架的不一樣節點上。

 

這樣集羣可在徹底失去某一機架的狀況下還能存活。同時，這種策略減小了機架間的數據傳輸，提升了寫操做的效率，由於數據塊只存放在兩個不一樣的機架上，減小了讀取數據時須要的網絡傳輸總帶寬。這樣在必定程度上兼顧了數據安全和網絡傳輸的開銷。