Hadoop體系架構詳解
- 1 NameNode職責
- 1.1 NameNode三大職責
- 1.2 edits檔案
- 1.3 fsimage檔案
- 2 DataNode職責
- 3 SecondNameNode職責
- 4 Yarn體系架構和任務排程過程
- 5 Hbase體系架構
- 6 主從架構單點故障問題及解決方案
作者：Be_melting
1 NameNode職責
1.1 NameNode三大職責
- （1） 管理HDFS：資料節點（DataNode）需要向NameNode報告資料塊狀态
- （2） 接受用戶端的請求：資料上傳，資料下載下傳（用戶端有上傳資料的需求，就會把請求發給NameNode，然後NameNode指定DataNode存放資料，俗話了解就是甲方有個需要，讓後找個對應的技術負責方，負責方安排小弟各個完成任務）
- （3） 維護HDFS：展現在維護edits檔案（用戶端記錄檔）、維護fsimage檔案（元資訊檔案）
關于edits檔案和fsimage檔案之前部落格中也有部分梳理，但是沒有詳細地介紹，以下就分别進行詳細介紹
1.2 edits檔案
首先确定一下檔案的位置，確定可以找到它：
$HADOOP_HOME/tmp/dfs/name/current
在進行環境搭建的時候，無論是僞分布模式還是全分布模式，在配置
core-site.xml
檔案前都需要在Hadoop中建立一個
tmp
檔案夾，該檔案目錄就是對應着HDFS作業系統目錄，所有操作内容都将存儲在這個檔案夾中
上機實操如下，進入tmp檔案目錄中，可以看到其下的dfs檔案夾，更進一步就可以知道裡面包含的資訊，由于這裡啟動的是bigdata111虛拟機，設定的是僞分布模式，所有的節點都在一台機器上，故dfs檔案中包含了全部的三個節點的資訊
自然我們要找的edits檔案就在name檔案夾下，然後更進一步擷取資訊，可以發現pwd輸出的結果正式上面列出的edits檔案所在的位置，不過也發現fsimage檔案也是在此路徑下
為了檢視edits檔案的功能，這裡可以在HDFS中建立一個檔案夾，然後檢視一下對應的edits檔案，如下
-
hdfs dfs -mkdir /tools
-
pwd
-
ls edits_*
注意：edits_inprogress_0000000000000000105是目前正在操作的日志，都是二進制，可以使用日志檢視器進行内容的檢視，具體的操作如下，其中
oev
指令，
-i
為參數，後面指定具體的二進制檔案，然後
-o
參數後指定具體的檔案位置，最終生成一個xml的可編輯（檢視）檔案
-
hdfs oev -i edits_inprogress_0000000000000000105 -o ~/a.xml
打開a.xml檔案後，可以發現使用的是
root
使用者，執行的指令是
mkdir
，然後生成的檔案夾名稱為
tools
，還有相應的時間戳，是以如果系統中有檔案/檔案夾損壞，就可以使用這種方式進行恢複
1.3 fsimage檔案
首先确定一下檔案的位置，確定可以找到它：
$HADOOP_HOME/tmp/dfs/name/current
fsimage檔案功能：記錄的是資料塊的位置資訊、備援資訊
為了明确fsimage檔案功能，比如将hadoop媒體直接上傳到剛剛建立的tools檔案夾中，hadoop媒體的記憶體大小204m，操作如下
然後在current中檢視fsimage檔案，同樣HDFS中也提供的有元資訊檢視器，最終生成的也是xml檔案，代碼指令：
hdfs oiv -i fsimage_0000000000000000104 -o ~/b.xml -p XML
對比前面用戶端日志轉化的指令可以發現，之前的
oev
，中間的
e
就是代表着edits檔案，這裡的
oiv
，中間的i就是指的fsimage檔案，最後多了一個
-p XML
要求最終的檔案為xml格式。檢視生成的檔案内容，核實一下是否包含了所說的一些功能（核實無誤）
至此關于NameNode有關的資訊就全部梳理完畢
2 DataNode職責
（1）資料節點（DataNode），自然是用來存放資料。存放的要求，即是按照資料塊來儲存資料：1.x：64M 2.x：128M
（2）資料塊的位置：
$HADOOP_HOME/tmp/dfs/data/current/BP-90413187-192.168.157.111-1582475681214/current/finalized/subdir0/subdir0
之前的NameNode資訊存放在dfs檔案目錄下的name檔案夾下，自然DataNode資訊就存放在data檔案夾下，且資料塊的資訊都是以blk資訊開頭，查找全部的資料塊資訊操作如下，這樣就可以發現資料塊的具體位置（當然直接在data下的current檔案夾下找也可以）
（3） 資料塊資訊，滿128m被分塊細心點可以發現，blk資訊都是成對的出現，有一份是.meta字尾的檔案屬于對應資料塊的元資訊檔案。上面在進行fsimage檔案功能檢視之前上傳了一個hadoop媒體，該檔案的大小為204m。自然上傳完畢後就會被切割為兩個資料塊，可以計算一下兩個資料快的大小，下面框選的就是資料塊的位元組大小，然後除以1024就是以m為機關的大小（134217728+798744467=214092195），算出的位元組數和上面fsimage檔案處檢視hadoop媒體的記憶體大小是一緻。
（4）設定資料塊備援度的一般原則：備援度跟資料節點個數一緻，最大不超過3。
至此關于DataNode的所有知識就梳理完畢
3 SecondNameNode職責
SecondaryNameNode：第二名稱節點，跟NameNode運作在一起
- （1）不是NameNode熱備（還是要強調，如果NameNode故障，SecondaryNameNode不能頂替其進行工作）
- （2）職責：定期進行日志資訊的合并：把edits檔案----> fsimage檔案
- （3）重點：掌握日志合并的過程（可以用于解釋為什麼要和NameNode運作在一起）
上機示範name檔案夾和namesecondary檔案夾之間的差異，唯一多出來的這個檔案顯示inprogress，說明正在進行中，為什麼會有這個檔案？因為檔案的下載下傳、合并、上傳都是需要花費時間的，假定是一分鐘，那麼用戶端在這一分鐘之内就可能産生新的日志檔案，是以就會生成這個inprocess檔案（作用：當合并發生以後，記錄最新的用戶端日志）
然後就可以回答為什麼NameNode要和SecondaryNameNode運作在一起，就是因為這個下載下傳、合并、上傳的過程，發生在本地時候，這時系統處理資料不需要通過網絡連接配接，避免了網絡請求而是直接在本地（同一台機子）上完成，這樣會大大提高資料的處理效率
補充一點：檢查點（就是觸發合并的時間）
（1）HDFS：觸發日志的合并
（2）Oracle：會以最高優先級喚醒資料庫的寫程序，寫髒資料
（3）Spark和Flink：容錯機制
4 Yarn體系架構和任務排程過程
之前已經示範過wordcount程式：
hadoop jar hadoop-mapreduce-examples-2.7.3.jar wordcount /input/data.txt /output/wc1
輸出結果是對檔案中的單詞進行統計并且排序，接下來就解析期間yarn中的各個節點是如何運作，yarn體系架構依然是主從節點組成。
（1）ResourceManager：主節點（職責如下）
- ① 接收用戶端的請求：執行MapReduce任務的請求
- ② 資源的配置設定：CPU、記憶體、網絡
- ③ 任務的配置設定：分給NodeManager去執行
（2）NodeManager：從節點（職責如下）
- ① 從ResourceManager擷取任務和資源
- ② 執行任務
（3）Yarn排程MapReduce任務的過程：注意這裡的NodeManger是要和DataNode連接配接在一塊，這樣就減少了網絡請求，直接加快了效率（也就解釋了為啥這兩個節點要在一塊了）
（4）Yarn的資源配置設定方式：3種
- ① FIFO Scheduler 先來先得，問題：沒有考慮任務的優先級
- ② Capacity Scheduler：容器管理的排程規則，允許多個組織共享叢集的資源
- ③ Fair Scheduler：公平排程原則，假設：任務具有相同的優先級，平均配置設定系統的資源。（之後利用yarn排程spark，必須要是公平排程模式）
5 Hbase體系架構
Hbase也是主從架構，主節點為HMaster，從節點為RegionServer，還有一個ZooKeeper（當做“資料庫”即可）
由于是一個大表存放資料，是以随着資料的加入，列族可能會不斷地增大，這時候為了儲存資料盡量會使用多個region進行存儲，而且用戶端的請求不能直接連接配接到HMaster，需要中間有個ZooKeeper進行架橋（也就是用戶端并不認識HMaster，當其要上傳時候，它就找一下ZooKeeper，然後ZooKeeper告訴它，把請求發給指定的HMaster就行。俗話點就是，你想找一個官場人員辦事，但是你并沒有官場朋友，就打聽到村裡有個人能夠使用他的關系，有能力幫你找到負責人的官場辦事人員，然後你就可以把你的訴求上報給官場的人員了）。