hadoop(一):深度剖析hdfs原理

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