## 一、HDFS的概念 先簡單過一下基礎概念，起碼知道接下來要說的東西和這個東西是用來干啥的

1.1 Hadoop架構 HDFS(Hadoop Distributed FileSystem)，由3個模塊組成：分布式存儲HDFS，分布式計算MapReduce，資源調度框架Yarn  大量的文件可以分散存儲在不同的服務器上面 單個文件比較大，單塊磁盤放不下，可以切分成很多小的block塊，分散存儲在不同的服務器上面，各服務器通過網絡連接，造成一個整體。 

 1.2 核心概念block HDFS3.x上的文件會按照128M為單位切分成一個個的block，分散存儲在集群的不同的數據節點datanode上，需要注意的是，這個操作是HDFS自動完成的。  假設我們現在要存儲一個300M的文件，這個300M就會被切分成 datanode1：128M + datanode2：128M + datanode3：44M 這時我們需要知道，就算它的底層邏輯會按照128M進行劃分，可是datanode3一個實際占用44M的塊也是不會占據128M的空間的 

1.3 block的副本 為什么hadoop直至今天會這么流行，就是因為它的初始設計就是可以部署在商用服務器上，而我們知道，商用服務器是非常廉價的，而這種廉價的服務器就很容易出現故障，比如CPU,IO內存等等都可能會產生問題 按照我們剛剛1.2的說法，一個文件被分成了3塊存儲在不同的datanode上，萬一其中的一個datanode掛掉，那豈不是這個文件就找不回來了嗎，所以hadoop還對我們的每一個數據塊做了一個副本，保證數據的可靠性 副本數可以自己進行手動設置，一般是3個副本 hdfs-site.xml dfs.replication 3 可以清晰看到value的值為3，我們的副本數就為3 類似于這些個屬性我們是如何得知它們的作用的呢，在上可以查看，這里用的2.7.3。點開官方文檔，在左側邊欄拉至最下方可以看到configuration項 當然我們需要找對文件，是HDFS的內容就要找hdfs-default.xml，如果是MapReduce，就要mapred-default.xml，yarn的就是yarn-default.xml  點擊hdfs-default.xml，可以按下ctrl+f進行搜索，輸入dfs.replication回車  這里我們就可以看到了，dfs.replication的默認值就是為3，后面的參數說明寫著default block replication，而下面的參數dfs.replication.max就是副本最大可設置為512的意思了 同樣剛剛在 1.2 核心概念block 時我們提到的block大小為128M在這個文件中也可以找到  所以其實每一個數據塊block的大小也是可以自主設置的 #### 1.3.1 機架存儲策略  實際機房中，會有(https://image.baidu.com/search/index?tn=baiduimage&ipn=r&ct=201326592&cl=2&lm=-1&st=-1&fm=result&fr=&sf=1&fmq=1573029886236_R&pv=&ic=&nc=1&z=&hd=&latest=©right=&se=1&showtab=0&fb=0&width=&height=&face=0&istype=2&ie=utf-8&sid=&word=%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%9C%BA%E6%9E%B6)，每個機架上會有若干臺服務器 一般來說我們會把一個block的3個副本分別按照下述方法進行存儲： 第一個副本就存儲在一個機架A上 第二個副本存儲在和這個block塊不同機架（比如機架B）的一個服務器上 我們存儲第2個副本時會優先把副本存儲在不同的機架上，這是為了防止出現一個機架斷電的情況，如果副本也存儲在同機架上的不同服務器上，這時候數據就可能丟失了。 第三個副本存儲在機架B的另外一個服務器上（注意副本2,3都存儲在了機架B） 為什么會這么選擇，因為如果我們把副本3也放在另外一個機架C上，副本2和副本3之間的通信就需要副本2通過它的交換機去聯系總交換機，然后總交換機去聯系機架C的交換機，需要走的路線非常長，而且機房中的帶寬資源非常寶貴，如果處于高并發的情況，很容易就把機房的帶寬打滿，此時整一個集群的響應速度會急劇下降，這時候服務就會出現問題了。 當然我們的副本數也是可以手動通過命令增加的，在客戶端訪問量多的時候，可以適當分配一下壓力 $ hadoop fs -setrep -R 4 path+FileName setrep的意思其實就是set replication，設置副本數的縮寫，上面命令就是將副本數設置成4份了，后面跟著文件路徑和文件名即可 ### 二、HDFS的三大組件  再次強調一下，大數據的框架大部分其實都是主從架構，就是一主多從，等下要講到的HDFS就是一個NameNode，多個DataNode，MapReduce就是一個JobTracker，多個TaskTracker，Yarn則是一個ResourceManager，多個NodeManager，而Spark就是一個Master和多個Slave DataNode的介紹其實可以省略，姑且只需要知道它的作用是存放block塊的即可。 

 2.1 NameNode的介紹 大數據框架都是分布式的，可能每個角色都運行在各個不同的服務器上面，需要進行通信的時候就要需要網絡的支持，而在我們客戶端需要讀一個文件的信息時，必須知道我們這個文件被分成了多少個block，各個block又分別存儲在哪個服務器上，這種用于描述文件的信息被稱為文件的元數據信息（metaData），而metaData就是存儲在NameNode的內存中的

2.2 metaData的介紹 metaData的大小：文件，block，目錄占用大概150byte字節的元數據，所以為什么說HDFS適合存儲大文件而不適合存儲小文件，可想而知存儲一個大文件就只有一份150byte的元數據，存儲N多個小文件就會伴隨存在N份150Byte字節的元數據文件，這就非常地不劃算 元數據信息以命名空間鏡像文件（以下稱為fsimage）和編輯日志（以下稱為edits log）的方式保存，兩者的作用分別是 fsimage：元數據鏡像文件，保存了文件系統目錄樹信息以及文件和塊的對應關系 edits log：日志文件，保存了文件的更改記錄 為什么元數據需要存儲在NameNode的內存中呢，答案很簡單，存儲在內存中意味著快，當然也會存在問題，就是如果NameNode宕機了，內存就無法讀取了，此時為了防止這種情況出現，也為了加快NameNode從故障中恢復的速度，就設計了一個SecondaryNameNode的角色 日志緩存方面：客戶端向 HDFS 寫文件，會記錄下來操作日志，而這時我們會預先準備好兩塊緩存區域，這個日志在寫滿了第一塊緩存時，會開始錄入磁盤，也就是edits log，NameNode的內存中，這種狀態就是一個雙緩存異步寫的操作。這樣可以保證客戶端寫的日志時刻都能被記錄下來。 #### 2.3 SecondaryNameNode的介紹 它的作用主要有以下幾點 1.備份NameNode中的元數據信息 2.提高NameNode的重啟速度 3.必要的時候可作為新的NameNode ##### 為什么說SecondaryNameNode可以提高NameNode的恢復速度？ 當集群啟動的時候，會記錄下啟動的時間t，而隨著一段時間過去后或者NameNode中的edits log文件存滿后就會觸發checkPoint操作，在Spark中也會有這個知識點，主要作用就是對重要的數據進行備份的一個操作 對操作步驟進行一個分點闡述方便大家閱讀 1.SecondaryNameNode 會通過http get方式把edits log和fsimage的信息拉取過來 2.在SecondaryNameNode中把edits log和fsimage做一個合并，產生一個新的文件叫做fsimage.ckpt 3.在SecondaryNameNode中合并完成之后，再回傳給NameNode里面 4.這時大概率會有客戶端還在對NameNode進行讀寫操作，也會產生新的日志，會單獨放在一份edits new文件中 5.剛剛回傳回來的fsimage.ckpt進行分解，原本的fsimage和edits log，不過此時的edits log會把edits new中的日志文件一同合并作為完整的一份edits log文件 ##### 為什么說SecondaryNameNode可以提高NameNode的重啟速度 首先搞清楚NameNode節點掛掉后它是如何進行恢復的 首先它會把內存中的鏡像文件fsimage讀到內存當中，然后通過edits log所記錄的所有操作重新執行一遍，把所有的元數據都恢復之后，才能回到關機之前的狀態，這個過程十分緩慢 但是有了SecondaryNameNode之后，通過它提供的fsimage.ckpt可以恢復很大一部分的元數據信息，再直接通過執行edits log中所記錄下來的，從edits new中合并過來的新操作，就可以進行恢復 而在NameNode確定無法重啟之后，SecondaryNameNode就可以通過以下命令作為新的NameNode對外提供服務 hadoop-daemon.sh start namenode 當然我們不難發現，這種方式非常地不優雅，因為在NameNode進行重啟或者SecondaryNameNode進行上位的時間段中我們的集群肯定都會有一段空白期，所以之后講到的hadoop HA的方式就會幫助我們解決這個問題 

三、HDFS機制 

3.1 心跳機制  心跳機制解決了HDFS集群間的通信問題，還是NameNode命令DataNode執行操作的途徑 1.master namenode啟動之后，會開一個ipc server 2.slave DataNode啟動，連接NameNode，每隔3s向NameNode發送一個心跳，并攜帶狀態信息 3.NameNode通過對這個心跳的返回值來給DataNode傳達任務指令 心跳機制的作用

 1.NameNode全權管理數據塊的復制，它周期性從集群中的每個DataNode接收心跳信號和塊狀態報告（blockReport），接收到心跳信號意味著該DataNode節點工作正常，塊狀態報告包含了該DataNode上所有數據塊的列表

 2.DataNode啟動時向NameNode注冊，通過后周期性地向NameNode上報blockReport，每3秒向NameNode發送一次心跳，NameNode返回對該DataNode的指令，如將數據塊復制到另一臺機器，或刪除某個數據塊等···而當某一個DataNode超過10min還沒向NameNode發送心跳，此時NameNode就會判定該DataNode不可用，此時客戶端的讀寫操作就不會再傳達到該DataNode上

 3.hadoop集群剛開始啟動時會進入安全模式（99.99%），就用到了心跳機制，其實就是在集群剛啟動的時候，每一個DataNode都會向NameNode發送blockReport，NameNode會統計它們上報的總block數，除以一開始知道的總個數total，當 block/total < 99.99% 時，會觸發安全模式，安全模式下客戶端就沒法向HDFS寫數據，只能進行讀數據。 

3.2 負載均衡 其實就是節點的增加或減少，或者節點的磁盤使用率高低的問題，主要就是通過網絡進行數據的遷移工作以達到高可用率 觸發命令 $ HADOOP_HOME/sbin/start-balancer.sh -t 5% 5%其實就是剛剛提到的磁盤的利用率差值，大于5%時會觸發負載均衡策略。