從零開始的大數據（一） --- HDFS的知識概述（上）

前言

從零開始的高併發系列咱們已經把 zookeeper 給更新完了，順帶一提以前的zookeeper並無結合大數據來進行說明。從新開個坑一方面是一直都想找個理由來總結一下大數據方面的東西，另外一方面則是抓住時代的走向吧，畢竟也是爲了本身，因此廢話很少說咱們就開始吧。

閱讀須知

這相似於一份學習筆記，但是絕對有頭有尾，會用最清晰明瞭的語言來描述知識點，但願你們也能有所收穫

重點：大數據的概念性問題偏多，因此文章中不會像之前同樣出現堆積代碼的狀況，更多都是在闡述概念

大數據的話必定要看命令和日誌！

以往 zookeeper 的連接（僅涉及Java）

從零開始的高併發（一）--- Zookeeper的基礎概念

從零開始的高併發（二）--- Zookeeper實現分佈式鎖

從零開始的高併發（三）--- Zookeeper集羣的搭建和leader選舉

從零開始的高併發（四）--- Zookeeper的分佈式隊列

從零開始的高併發（五）--- Zookeeper的配置中心應用

從零開始的高併發（六）--- Zookeeper的Master選舉及官網小覽

1、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

    <configuration>
        <property>
            <name>dfs.replication</name>
            <value>3</value>
        </property>
    </configuration>
複製代碼

能夠清晰看到value的值爲3，咱們的副本數就爲3

相似於這些個屬性咱們是如何得知它們的做用的呢，在hadoop官網上能夠查看，這裏用的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 機架存儲策略

實際機房中，會有機架，每一個機架上會有若干臺服務器

通常來講咱們會把一個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份了，後面跟着文件路徑和文件名便可

2、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的方式就會幫助咱們解決這個問題

3、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%時會觸發負載均衡策略

finally

下一篇會繼續更新HDFS的讀寫流程和容錯，HA高可用和聯邦