標籤：eid 檔案中 binary class 計算 封裝 指定 category idts
HDFS（Hadoop Distributed File System ）
HDFS（Hadoop Distributed File System ）HadoopDistributed File System。是根據google發表的論文翻版的。論文為GFS（Google File System）Google 檔案系統（中文，英文）。
1. 架構分析 基礎名詞解釋：
- 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. 一個檔案被拆成多個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節點
hdfs架構
1、HDFS的組成：
- NameNode：Master節點（也稱中繼資料節點），是系統唯一的管理者。負責中繼資料的管理(名稱空間和資料區塊映射資訊);配置副本策略；處理用戶端請求
- DataNode：資料存放區節點(也稱Slave節點)，儲存實際的資料；執行資料區塊的讀寫；彙報儲存資訊給NameNode
- Sencondary NameNode：分擔namenode的工作量；是NameNode的冷備份；合并fsimage和fsedits然後再發給namenode。注意：在hadoop 2.x 版本，當啟用 hdfs ha 時，將沒有這一角色
- client：系統使用者，調用HDFS API操作檔案;與NameNode互動擷取檔案中繼資料;與DataNode互動進行資料讀寫。注意：寫資料時檔案切分由Client完成
熱備份：b是a的熱備份，如果a壞掉。那麼b立即運行代替a的工作
冷備份：b是a的冷備份，如果a壞掉。那麼b不能立即代替a工作。但是b上儲存a的一些資訊，減少a壞掉之後的損失
2、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)。
- 類似於資料庫中的檢查點，為了避免edits日誌過大，在Hadoop1.X中，SecondaryNameNode會按照時間閾值（比如24小時）或者edits大小閾值（比如1G），周期性的將fsimage和edits的合并，然後將最新的fsimage推送給NameNode。而在Hadoop2.X中，這個動作是由Standby NameNode來完成.
- 由此可看出，這兩個檔案一旦損壞或丟失，將導致整個HDFS檔案系統不可用。
- 在hadoop1.X為了保證這兩種中繼資料檔案的高可用性，一般的做法，將dfs.namenode.name.dir設定成以逗號分隔的多個目錄，這樣，多個目錄至少不要在一塊磁碟上，最好放在不同的機器上，比如：掛載一個共用檔案系統
- fsimage\edits 是序列化後的檔案，想要查看或編輯裡面的內容，可通過 hdfs 提供的 oiv\oev 命令，如下：
- 命令: hdfs oiv （offline image viewer） 用於將fsimage檔案的內容轉儲到指定檔案中以便於閱讀,，如文字檔、XML檔案，該命令需要以下參數：
1. -i (必填參數) –inputFile <arg> 輸入FSImage檔案
2. -o (必填參數) –outputFile <arg> 輸出轉換後的檔案，如果存在，則會覆蓋
3. -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
Secondary NameNode 定期合并 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 檔案中記下檢查點發生的時
工作原理
寫操作：
有一個檔案FileA，100M大小。Client將FileA寫入到HDFS上。HDFS按預設配置(塊大小為64M)。HDFS分布在三個機架上Rack1，Rack2，Rack3。
a. Client將FileA按64M分塊。分成兩塊，block1和Block2;
b. Client向nameNode發送寫資料請求，藍色虛線①------>。
c. NameNode節點，記錄block資訊。並返回可用的DataNode，如粉色虛線②--------->。
Block1: host2,host1,host3
Block2: host7,host8,host4
原理：
NameNode具有RackAware機架感知功能(這個可以配置)。
若client為DataNode節點，那儲存block時，規則為：副本1，同client的節點上；副本2，不同機架節點上；副本3，同第二個副本機架的另一個節點上；其他副本隨機挑選。
若client不為DataNode節點，那儲存block時，規則為：副本1，隨機播放一個節點上；副本2，不同副本1，機架上；副本3，同副本2相同的另一個節點上；其他副本隨機挑選。
client向DataNode發送block1；發送過程是以流式寫入。流式寫入過程:
將64M的block1按64k的package劃分;
然後將第一個package發送給host2;
host2接收完後，將第一個package發送給host1，同時client向host2發送第二個package；
host1接收完第一個package後，發送給host3，同時接收host2發來的第二個package。
以此類推，紅線實線所示，直到將block1發送完畢。
host2,host1,host3向NameNode，host2向Client發送通知，說“訊息發送完了”。粉紅顏色實線所示。
client收到host2發來的訊息後，向namenode發送訊息，說我寫完了。這樣就真完成了。黃色粗實線
發送完block1後，再向host7，host8，host4發送block2，藍色實線所示。
發送完block2後，host7,host8,host4向NameNode，host7向Client發送通知，淺綠色實線所示。
client向NameNode發送訊息，說我寫完了，黃色粗實線。。。這樣就完畢了。
分析，通過寫過程，我們可以瞭解到：
①寫1T檔案，我們需要3T的儲存(有3個副本)，3T的網路流量貸款。
②在執行讀或寫的過程中，NameNode和DataNode通過HeartBeat進行儲存通訊，確定DataNode活著。如果發現DataNode死掉了，就將死掉的DataNode上的資料，放到其他節點去。讀取時，要讀其他節點去。
③掛掉一個節點，沒關係，還有其他節點可以備份；甚至，掛掉某一個機架，也沒關係；其他機架上，也有備份。
說明：
- 當用戶端向 HDFS 檔案寫入資料的時候，一開始是寫到本地臨時檔案中。假設該檔案的副本係數設定為 3 ，當本地臨時檔案累積到一個資料區塊的大小時，用戶端會從 Namenode 擷取一個 Datanode 列表用於存放副本。然後用戶端開始向第一個 Datanode 傳輸資料，第一個 Datanode 一小部分一小部分 (4 KB) 地接收資料，將每一部分寫入本地倉庫，並同時傳輸該部分到列表中 第二個 Datanode 節點。第二個 Datanode 也是這樣，一小部分一小部分地接收資料，寫入本地 倉庫，並同時傳給第三個 Datanode 。最後，第三個 Datanode 接收資料並儲存在本地。因此， Datanode 能流水線式地從前一個節點接收資料，並在同時轉寄給下一個節點，資料以流水線的 方式從前一個 Datanode 複製到下一個
- 時序圖如下：
讀操作：
讀操作流程為：
- 用戶端通過調用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資料，是序列化形式儲存
參考：
HDFS 原理、架構與特性介紹--轉載 -
hadoop(一):深度剖析hdfs原理
【Hadoop】HDFS的運行原理
還不懂HDFS的工作原理？快來掃掃盲
分類: hadoop
HDFS（Hadoop Distributed File System ）
