為什么要開發(fā)HDFS分布式文件系統(tǒng)

可以更好的支持分布式計算。
hadoop distribute file system是一個分布式 文件系統(tǒng)，操作的是文件，增、刪都是以文件為單位。

存儲模型

• 文件線性按字節(jié)切割成塊（block），具有offset，id
  offset是指block的偏移量，比如block大小是10，offset可以是0,10,20,30。。。
  id是block的名稱，比如block1，block2。。。
• 文件與文件的block大小可以不一樣
  指不同的文件，block大小可以不一樣，比如A文件block大小是10Byte，B文件的大小是20Byte。
• 一個文件除最后一個block，其他block大小一致
  文件中的數(shù)據(jù)一定會被切壞，如何恢復，后期拼接時恢復。
• block的大小依據(jù)硬件的I/O特性調(diào)整
• block被分散存放在集群的節(jié)點中，具有l(wèi)ocation
  location是指block存儲在集群中的哪個節(jié)點上。
• block具有副本（replication），沒有主從概念，副本不能出現(xiàn)在同一個節(jié)點
  副本沒有主從概念，比如3個副本就是每個block被存儲為三份，三份讀哪一個都行。
• 副本是滿足可靠性和性能的關(guān)鍵
  多個 副本可以讓多個程序并行計算，計算想向數(shù)據(jù)移動，無需拉取文件。
• 文件上傳可以指定block大小和副本數(shù)，上傳后只能修改副本數(shù)
  文件上傳后無法再次調(diào)整block大小，但是可以調(diào)整block的副本數(shù)。
• 一次寫入多次讀取，不支持修改
  只能讀取，不能修改，但是能追加數(shù)據(jù)。
  why：原因是如果修改block數(shù)據(jù)，那邊會導致后面的block偏移量都會改變，導致資源被嚴重浪費（CPU、網(wǎng)絡(luò)帶寬、IO等），這是一個折中設(shè)計，因為hdfs目的是為了更好的支持分布式計算，所以沒必要為了修改操作而產(chǎn)生泛洪操作。
• 支持追加數(shù)據(jù)
  追加數(shù)據(jù)不會導致其他block的偏移量修改，只是最后一個block數(shù)據(jù)產(chǎn)生變化，不會導致泛洪操作，因此支持追加操作。

架構(gòu)設(shè)計

• HDFS是一個主從（Master/Slaves）架構(gòu)
  主和從協(xié)作完成一個任務(wù)；
  主備是指一個干活一個不干活，等主的掛了備的切換為主，其實備就是一個備份。
• 由一個NameNode和一些DataNode組成
  NameNode是主，DataNode是從
• 面向文件包含：文件數(shù)據(jù)（data）和文件元數(shù)據(jù)（metadata）
• NameNode負責存儲和管理文件元數(shù)據(jù)，并維護一個層次型的文件目錄樹
  類似linux的文件目錄樹。
• DataNode負責存儲文件數(shù)據(jù)（block塊），并提供block的讀寫
  客戶端先和NameNode確認去哪里存取，然后到對應(yīng)的DataNode存取。
  NameNode類似一個網(wǎng)關(guān)，會把請求轉(zhuǎn)發(fā)到不同的節(jié)點。
• DataNode與NameNode維持心態(tài)，并匯報自己持有的block信息
  NameNode確認文件是否存儲完成，是根據(jù)DataNode上報的信息確認的。
• Client和NameNode交互文件元數(shù)據(jù)和DataNode交互文件block數(shù)據(jù)
  
  

角色功能

NameNode

• 完全基于內(nèi)存存儲文件元數(shù)據(jù)、目錄樹結(jié)構(gòu)、文件block的映射
  基于內(nèi)存存儲，為了快速訪問，內(nèi)存的IO是磁盤IO的10萬倍
• 需要持久化方案保證數(shù)據(jù)可靠性
• 提供副本放置策略
  DataNode
• 基于本地磁盤存儲block（文件的形式）
  一個文件如果被切分為10個block，那么會被存儲成10個小文件，分散到不同的DataNode上。
• 并保存block的校驗和，保證block的可靠性
  確保下載時block數(shù)據(jù)不會被破壞，下載block后計算出校驗和與DataNode上的校驗和比對，一致數(shù)據(jù)就是正常的。
• 與NameNode保持心跳，匯報block列表狀態(tài)

元數(shù)據(jù)持久化

• 任何對文件系統(tǒng)元數(shù)據(jù)產(chǎn)生修改的操作，NameNode都會使用一種稱為EditLog的事務(wù)日志記錄下
• 使用FsImage存儲內(nèi)存所有的元數(shù)據(jù)狀態(tài)
• 使用本地磁盤保存EditLog和FsImage
• EditLog具有完整性，數(shù)據(jù)丟失少，但恢復速度慢，并有體積膨脹風險。
• FsImage具有恢復速度快，體積與內(nèi)存數(shù)據(jù)相當，但不能實時保存，數(shù)據(jù)丟失多
• NameNode使用了FsImage+EditLog整合的方案
  滾動將增量的EditLog更新到FsImage，以保證更近時間點的FsImage和更小的EditLog體積

日志文件的作用

記錄實時發(fā)生的增刪改的操作，可以通過讀取日志的方式恢復之前的數(shù)據(jù)。
優(yōu)點：日志的完整性比較好，因為是實時的。
缺點：加載數(shù)據(jù)恢復數(shù)據(jù)慢，占用空間大。

鏡像、快照、dump、db的作用

內(nèi)存全量數(shù)據(jù)基于某個時間點寫入磁盤，類似于內(nèi)存全量數(shù)據(jù)序列化到磁盤。
但是間隔時間不能太短，因為I/O讀寫慢。
優(yōu)點：通常是二進制文件存儲，恢復速度快。
缺點：因為間隔保存， 容易丟失部分數(shù)據(jù)。

HDFS元數(shù)據(jù)如何持久化

通過鏡像（FsImage）+日志（EditLog）組合的方式。
HDFS如何組合使用的？
EditLog：盡可能的讓日志文件體積小，記錄少。
FsImage：盡可能更快的管道更新鏡像文件（定時生成FsImage文件）

通過 最近時點的FsImage + 增量的EditLog來持久化數(shù)據(jù)。
比如現(xiàn)在10點：
使用9點的FsImage + 9點到10點的增量EL
恢復步驟：
1、加載FI
2、加載EL
3、內(nèi)存就得到了關(guān)機前的全量數(shù)據(jù)

安全模式

• HDFS搭建時會格式化，格式化操作會產(chǎn)生一個空的FsImage

• 當NameNode啟動時，它從硬盤中讀取Editlog和FsImage

• 將所有Editlog中的事務(wù)作用在內(nèi)存中的FsImage上

• 并將這個新版本中的FsImage從內(nèi)存中保存到本地磁盤上

• 然后刪除舊的EditLog，因為這個舊的Editlog的事務(wù)都已經(jīng)作用在FsImage上了

• NameNode啟動后會進入一個稱為安全模式的特殊狀態(tài)。

• 處于安全模式的NameNode是不會進行數(shù)據(jù)塊的復制的。
  比如文件元數(shù)據(jù)包括：文件屬性，每個塊存在哪個DN上。
  在持久化的時候：文件屬性會持久化，但是文件的每個塊所在的位置不會持久化，因此NN啟動恢復的時候，NN會丟失塊的位置信息。
  這么設(shè)計的原因是：分布式存儲，數(shù)據(jù)一致性很重要，如果持久化了，但是啟動集群的時候，某臺DN掛了，那么下載block就會出錯。所有使用啟動DD上報數(shù)據(jù)到NN。

• NameNode從所有的Datanode接收心跳信號和塊狀態(tài)報告。

• 每當NameNode檢測確認某個數(shù)據(jù)塊的副本數(shù)目達到這個最小值，那么該數(shù)據(jù)塊就會被認為是副本安全（safely repicated）的。

• 在一定百分比（這個參數(shù)可配置）的數(shù)據(jù)塊被NameNode檢測確認是安全之后（加上一個額外的30秒等待時間），NameNode將退出安全模式狀態(tài)。

• 接下來它會確認還有哪些數(shù)據(jù)塊的副本沒有達到指定數(shù)目，并將這些數(shù)據(jù)塊復制到其他DataNode上。

HDFS中的SNN

SecondaryNameNode（SNN）

• 在非Ha模式下，SNN一般是獨立的節(jié)點，周期完成對NN的EditLog想FsImage合并，減少EditLog大小，減少NN啟動時間
• 根據(jù)配置文件設(shè)置的時間間隔fs.checkpoint.period默認3600秒
• 根據(jù)配置文件設(shè)置edits log大小fs.checkpoint.size規(guī)定edits文件最大值默認是64MB
  

Block的副本放置策略

• 第一個副本：放置在上傳文件的DN；如果是集群外提交，則隨機選擇一臺磁盤不太滿，CPU不太忙的節(jié)點。
• 第二個副本：放置在于第一個副本不同的機架的節(jié)點上。
• 第三個副本：與第二個副本相同機架的節(jié)點。
  減少客戶端的成本，如果2,3放置一個機架上，不需要出機架，減少網(wǎng)絡(luò)IO。
• 更多副本：隨機節(jié)點。

讀寫流程

• 客戶端首先從NN中拿到DN的排序列表。
• 客戶端和位置最近的DN建立TCP連接，第一個DN和第二個DN建立tcp連接，第二個DN和第三個DN建立TCP連接，形成一個pipeline，也就是客戶端只和一個DN建立連接?？蛻舳税盐募谐啥鄠€塊，客戶端給第一個DN傳一個塊，傳完了幾下傳第二個塊，無需等待第二個DN、第三個DN傳完，后續(xù)的DN數(shù)據(jù)有前一個DN負責。其實流水線也是一種變種的并行。

詳細的HDFS寫流程

客戶端現(xiàn)象NN申請一個塊的副本位置；客戶端發(fā)完一個block后，再次向NN申請下一個block的副本位置。
下面是客戶端發(fā)送一個block的具體流程。

• Client和NN連接創(chuàng)建文件元數(shù)據(jù)
• NN判定元數(shù)據(jù)是否有效
• NN觸發(fā)副本放置策略，返回一個有序的DN列表
• Client和DN建立Pipeline連接
• Client將塊切分成packet(64KB)，并使用chunk(512B) + chunksum(4B)填充。
  也就是客戶端每次發(fā)送一個packet。
  64KB = (512B + 4B)*n，也就是64KB的數(shù)據(jù)分成多個chunk+chunksum
• Client將Packet放入發(fā)送隊列dataqueue中，并向第一個DN發(fā)送。
• 第一個DN收到packet后本地保存并發(fā)送給第二個DN
• 第二個DN收到packet后本地保存并發(fā)送給第三個DN
• 這一個過程中，上游節(jié)點同時發(fā)送下一個packet
• 生活中類比工程的流水線：結(jié)論：流式其實也是變種的并行計算
• Hdfs使用這種傳輸方式，副本數(shù)對于client是透明的
• 當block傳輸完成，DN們各自向NN匯報，同時client繼續(xù)傳輸下一個block
• 所以，client的傳輸和block的匯報也是并行的

HDFS讀流程

文章來源地址http://www.zghlxwxcb.cn/news/detail-503609.html

HDFS讀流程

• 為了降低整體的帶寬消耗和讀取延時，HDFS會盡量讓讀取程序讀取離它最近的副本。
• 如果在讀取程序的同一個機架上有一個副本，那么就讀取該副本。
• 如果一個HDFS集群跨越多個數(shù)據(jù)中心，那么客戶端也將首先讀本地數(shù)據(jù)中心的副本。
• 語義：下載一個文本：
  • client和NN交互文件元數(shù)據(jù)獲取fileBlockLocation
    文件的所有block的位置。
  • NN會按距離策略排序返回
  • Client嘗試下載block并校驗數(shù)據(jù)完整性。
• 語義：下載一個文件其實是獲取文件的所有的block元件數(shù)據(jù)，那么子集獲取某些block應(yīng)該成立
  • Hdfs支持client給出文件的offset自定義連接哪些block的DN，自定義獲取數(shù)據(jù)
  • 這個是支持計算層的分治、并行計算的核心

到了這里，關(guān)于hadoop-hdfs分布式文件系統(tǒng)理論（一）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！