目錄
- 1.5.6 NN與2NN
- 1.5.6.1 HDFS元資料管理機制
- 1.5.6.2 Fsimage與Edits檔案決議
- 1.5.6.2.1 Fsimage檔案內容
- 1.5.6.2.2 Edits檔案內容
- 1.5.6.3 checkpoint周期
1.5.6 NN與2NN
1.5.6.1 HDFS元資料管理機制
問題1：NameNode如何管理和存盤元資料？
計算機中存盤資料兩種：記憶體或者是磁盤
元資料存盤磁盤：存盤磁盤無法面對客戶端對元資料資訊的任意的快速低延遲的回應，但是安全性高
元資料存盤記憶體：元資料存放記憶體，可以高效的查詢以及快速回應客戶端的查詢請求，資料保存在內 存，如果斷點，記憶體中的資料全部丟失，
解決方案：記憶體+磁盤；NameNode記憶體+FsImage的檔案（磁盤）
新問題：磁盤和記憶體中元資料如何劃分？
兩個資料一模一樣，還是兩個資料合并到一起才是一份完整的資料呢？
一模一樣：client如果對元資料進行增刪改操作，需要保證兩個資料的一致性，FsImage檔案操作起來 效率也不高，
兩個合并=完整資料：NameNode引入了一個edits檔案（日志檔案：只能追加寫入）edits檔案記錄的 是client的增刪改操作，
不再選擇讓NameNode把資料dump出來形成FsImage檔案（這種操作是比較消耗資源），
元資料管理流程圖
-
第一階段：NameNode啟動
-
第一次啟動NameNode格式化后，創建Fsimage和Edits檔案，如果不是第一次啟動，直接加載編輯日志和鏡像檔案到記憶體，
-
客戶端對元資料進行增刪改的請求，
-
NameNode記錄操作日志，更新滾動日志，
-
NameNode在記憶體中對資料進行增刪改，
-
-
第二階段：Secondary NameNode作業
- Secondary NameNode詢問NameNode是否需要CheckPoint，直接帶回NameNode是否執行檢查點操作結果，
- Secondary NameNode請求執行CheckPoint，
- NameNode滾動正在寫的Edits日志，
- 將滾動前的編輯日志和鏡像檔案拷貝到Secondary NameNode，
- Secondary NameNode加載編輯日志和鏡像檔案到記憶體，并合并，
- 生成新的鏡像檔案fsimage.chkpoint，
- 拷貝fsimage.chkpoint到NameNode，
- NameNode將fsimage.chkpoint重新命名成fsimage，
1.5.6.2 Fsimage與Edits檔案決議
NameNode在執行格式化之后，會在/opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current目錄下產生如下檔案
- Fsimage檔案：是namenode中關于元資料的鏡像，一般稱為檢查點，這里包含了HDFS檔案系統所有目錄以及檔案相關資訊（Block數量，副本數量，權限等資訊）
- Edits檔案 ：存盤了客戶端對HDFS檔案系統所有的更新操作記錄，Client對HDFS檔案系統所有的更新操作都會被記錄到Edits檔案中（不包括查詢操作）
- seen_txid：該檔案是保存了一個數字，數字對應著最后一個Edits檔案名的數字
- VERSION：該檔案記錄namenode的一些版本號資訊，比如：CusterId,namespaceID等
1.5.6.2.1 Fsimage檔案內容
官方地址https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html
-
查看oiv和oev命令
[root@linux121 current]$ hdfs oiv Offline Image Viewer View a Hadoop fsimage INPUTFILE using the specified PROCESSOR,saving the results in OUTPUTFILE. oev Offline edits viewer Parse a Hadoop edits log file INPUT_FILE and save results in OUTPUT_FILE -
基本語法
hdfs oiv -p 檔案型別(xml) -i 鏡像檔案 -o 轉換后檔案輸出路徑 -
案例實操
[root@linux121 current]$ cd /opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current [root@linux121 current]$ hdfs oiv -p XML -i fsimage_0000000000000000265 -o /opt/lagou/servers/fsimage.xml [root@linux121 current]$ cat /opt/lagou/servers/fsimage.xml<?xml version="1.0"?> <fsimage> <version> <layoutVersion>-63</layoutVersion> <onDiskVersion>1</onDiskVersion> <oivRevision>826afbeae31ca687bc2f8471dc841b66ed2c6704</oivRevision> </version> <NameSection> <namespaceId>1393381414</namespaceId> <genstampV1>1000</genstampV1> <genstampV2>1024</genstampV2> <genstampV1Limit>0</genstampV1Limit> <lastAllocatedBlockId>1073741848</lastAllocatedBlockId> <txid>265</txid> </NameSection> <INodeSection> <inode> <id>16398</id> <type>DIRECTORY</type> <name>history</name> <mtime>1592376391028</mtime> <permission>root:supergroup:0777</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16399</id> <type>DIRECTORY</type> <name>done_intermediate</name> <mtime>1592375256896</mtime> <permission>root:supergroup:1777</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16400</id> <type>DIRECTORY</type> <name>root</name> <mtime>1592378079208</mtime> <permission>root:supergroup:0777</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16413</id> <type>FILE</type> <name>job_1592375222804_0001-1592375231176-root-word+count-1592375281926-1-1-SUCCEEDED-default- 1592375261492.jhist</name> <replication>3</replication> <mtime>1592375282039</mtime> <atime>1592375281980</atime> <preferredBlockSize>134217728</preferredBlockSize> <permission>root:supergroup:0777</permission> <blocks> <block> <id>1073741834</id> <genstamp>1010</genstamp> <numBytes>33584</numBytes> </block> </blocks> <storagePolicyId>0</storagePolicyId> </inode> <inode> <id>16414</id> <type>FILE</type> <name>job_1592375222804_0001_conf.xml</name> <replication>3</replication> <mtime>1592375282121</mtime> <atime>1592375282053</atime> <preferredBlockSize>134217728</preferredBlockSize> <permission>root:supergroup:0777</permission> <blocks> <block> <id>1073741835</id> <genstamp>1011</genstamp> <numBytes>196027</numBytes> </block> </blocks> <storagePolicyId>0</storagePolicyId> </inode> <inode> <id>16415</id> <type>DIRECTORY</type> <name>done</name> <mtime>1592376776670</mtime> <permission>root:supergroup:0777</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16427</id> <type>DIRECTORY</type> <name>logs</name> <mtime>1592378009623</mtime> <permission>root:root:0770</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16428</id> <type>DIRECTORY</type> <name>application_1592376944601_0001</name> <mtime>1592378045481</mtime> <permission>root:root:0770</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16430</id> <type>DIRECTORY</type> <name>wcoutput</name> <mtime>1592378037463</mtime> <permission>root:supergroup:0755</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16436</id> <type>FILE</type> <name>part-r-00000</name> <replication>3</replication> <mtime>1592378037264</mtime> <atime>1592378037074</atime> <preferredBlockSize>134217728</preferredBlockSize> <permission>root:supergroup:0644</permission> <blocks> <block> <id>1073741842</id> <genstamp>1018</genstamp> <numBytes>43</numBytes> </block> </blocks> <storagePolicyId>0</storagePolicyId> </inode> <inode> <id>16445</id> <type>FILE</type> <name>linux123_39919</name> <replication>3</replication> <mtime>1592378045469</mtime> <atime>1592378045331</atime> <preferredBlockSize>134217728</preferredBlockSize> <permission>root:root:0640</permission> <blocks> <block> <id>1073741848</id> <genstamp>1024</genstamp> <numBytes>56910</numBytes> </block> </blocks> <storagePolicyId>0</storagePolicyId> </inode> <inode> <id>16446</id> <type>DIRECTORY</type> <name>0617</name> <mtime>1592387393490</mtime> <permission>root:supergroup:0755</permission> <nsquota>-1</nsquota> <dsquota>-1</dsquota> </inode> <inode> <id>16449</id> <type>FILE</type> <name>banzhang.txt</name> <replication>1</replication> <mtime>1592388309046</mtime> <atime>1592388309026</atime> <preferredBlockSize>134217728</preferredBlockSize> <permission>root:supergroup:0644</permission> <storagePolicyId>0</storagePolicyId> </inode> </INodeSection> </fsimage>問題：Fsimage中為什么沒有記錄塊所對應DataNode？
在記憶體元資料中是有記錄塊所對應的dn資訊，但是fsimage中就剔除了這個資訊；HDFS集群在啟動的 時候會加載image以及edits檔案，block對應的dn資訊
都沒有記錄，集群啟動時會有一個安全模式 （safemode）,安全模式就是為了讓dn匯報自己當前所持有的block資訊給nn來補全元資料，后續每隔一段時間dn
都要匯報自己持有的block資訊，
1.5.6.2.2 Edits檔案內容
- 基本語法
hdfs oev -p 檔案型別 -i編輯日志 -o 轉換后檔案輸出路徑
-
案例實操
[root@linux121 current]$ hdfs oev -p XML -i edits_0000000000000000266- 0000000000000000267 -o /opt/lagou/servers/hadoop-2.9.2/edits.xml [root@linux121 current]$ cat /opt/lagou/servers/hadoop-2.9.2/edits.xml<?xml version="1.0" encoding="UTF-8"?> <EDITS> <EDITS_VERSION>-63</EDITS_VERSION> <RECORD> <OPCODE>OP_START_LOG_SEGMENT</OPCODE> <DATA> <TXID>113</TXID> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>114</TXID> <SRC>/wcoutput/_SUCCESS</SRC> <MODE>493</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>115</TXID> <SRC>/wcoutput/part-r-00000</SRC> <MODE>493</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>116</TXID> <SRC>/wcoutput</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>117</TXID> <SRC>/wcoutput/_SUCCESS</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>118</TXID> <SRC>/wcoutput/part-r-00000</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_DELETE</OPCODE> <DATA> <TXID>119</TXID> <LENGTH>0</LENGTH> <PATH>/wcoutput/part-r-00000</PATH> <TIMESTAMP>1592377324171</TIMESTAMP> <RPC_CLIENTID></RPC_CLIENTID> <RPC_CALLID>-2</RPC_CALLID> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>120</TXID> <SRC>/</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>121</TXID> <SRC>/tmp</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>122</TXID> <SRC>/tmp/hadoop-yarn</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>123</TXID> <SRC>/tmp/hadoop-yarn/staging</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>124</TXID> <SRC>/tmp/hadoop-yarn/staging/history</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>125</TXID> <SRC>/tmp/hadoop-yarn/staging/history/done</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD> <OPCODE>OP_SET_PERMISSIONS</OPCODE> <DATA> <TXID>126</TXID> <SRC>/tmp/hadoop-yarn/staging/history/done/2020</SRC> <MODE>511</MODE> </DATA> </RECORD> <RECORD>備注：Edits中只記錄了更新相關的操作，查詢或者下載檔案并不會記錄在內！！
問題：NameNode啟動時如何確定加載哪些Edits檔案呢？
nn啟動時需要加載fsimage檔案以及那些沒有被2nn進行合并的edits檔案，nn如何判斷哪些edits已經被合并了呢？
可以通過fsimage檔案自身的編號來確定哪些已經被合并，
1.5.6.3 checkpoint周期
[hdfs-default.xml]
<!-- 定時一小時 -->
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600</value>
</property>
<!-- 一分鐘檢查一次操作次數，當操作次數達到1百萬時，SecondaryNameNode執行一次 -->
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
<description>操作動作次數</description>
</property>
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60</value>
<description>1分鐘檢查一次操作次數</description>
</property>
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/539726.html
標籤：其他
上一篇：1.5.6 NN與2NN-hadoop-最全最完整的保姆級的java大資料學習資料
下一篇：mysql資料庫和表的基礎操作