十一、hdfs的datanode工作機制

一、datanode工作機制

1、基本流程

1）datanode啟動后會根據配置文件中指定的namenode地址，向namenode進行注冊。 2）namenode返回注冊成功 3）此后，datanode會周期性向namenode上報所有塊信息，默認是1小時 4）同時，datanode會每3秒給namenode發(fā)送心跳信息，namenode返回的心跳結果帶有namenode給該datanode的命令，如復制塊數(shù)據到另外一臺機器，或者刪除某個數(shù)據塊。如果超過超過10分鐘（默認）沒有收到某個datanode的心跳信息，則認為該節(jié)點不可用。 5）集群運行過程中可以安全的加入和退出一些datanode機器

2、基本目錄結構

? ? ? ? namenode 的目錄結構是通過手動初始化hdfs namenode -format時創(chuàng)建的，而datanode的則是在啟動時自動創(chuàng)建的，無需手動格式化。而且就算在datanode上格式化了namenode的目錄結構，只要不在datanode在啟動namenode，那么這些格式化的目錄也是沒有任何用處的。 ? ? ? ?一般datanode 的目錄在 ${hadoop.tmp.dir}/dfs/data 下，看看目錄結構

data
├── current
│?? ├── BP-473222668-192.168.50.121-1558262787574 以poolID作為目錄命名
│?? │?? ├── current
│?? │?? │?? ├── dfsUsed
│?? │?? │?? ├── finalized
│?? │?? │?? │?? └── subdir0
│?? │?? │?? │?? ? ? └── subdir0
│?? │?? │?? │?? ? ? ? ? ├── blk_1073741825
│?? │?? │?? │?? ? ? ? ? ├── blk_1073741825_1001.meta
│?? │?? │?? │?? ? ? ? ? ├── blk_1073741826
│?? │?? │?? │?? ? ? ? ? ├── blk_1073741826_1002.meta
│?? │?? │?? │?? ? ? ? ? ├── blk_1073741827
│?? │?? │?? │?? ? ? ? ? ├── blk_1073741827_1003.meta
│?? │?? │?? ├── rbw
│?? │?? │?? └── VERSION
│?? │?? ├── scanner.cursor
│?? │?? └── tmp
│?? └── VERSION
└── in_use.lock

（1）/data/current/VERSION 文件內容如下：

# datanode的id，非全局唯一，沒什么用
storageID=DS-0cb8a268-16c9-452b-b1d1-3323a4b0df60 
# 集群ID，全局唯一
clusterID=CID-c12b7022-0c51-49c5-942f-edc889d37fee
# 創(chuàng)建時間，沒什么用
cTime=0
# datanode 的唯一標識碼，全局唯一
datanodeUuid=085a9428-9732-4486-a0ba-d75e6ff28400
# 存儲類型為datanode
storageType=DATA_NODE
layoutVersion=-57

（2）/data/current/POOL_ID/current/VERSION

# 對接的namenode 的ID
namespaceID=983105879
# 創(chuàng)建時間戳
cTime=1558262787574
# 使用的pool id
blockpoolID=BP-473222668-192.168.50.121-1558262787574
layoutVersion=-57

（3）/data/current/POOL_ID/current/finalized/subdir0/subdir0 這個目錄下是真正存儲數(shù)據塊。一個block主要分為兩個文件存儲：

blk_${BLOCK-ID}
blk_${BLOCK-ID}_xxx.meta

對于目錄來說：

blk_${BLOCK-ID} ：
是一個xml格式的文件，上面記錄了了類似edits文件的操作日志，如：
<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
 ?<EDITS_VERSION>-63</EDITS_VERSION>
 ?<RECORD>
 ? ?<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
 ? ?<DATA>
 ? ? ?<TXID>22</TXID>
 ? ?</DATA>
 ?</RECORD>
 ?<RECORD>
 ? ?<OPCODE>OP_MKDIR</OPCODE>
 ? ?<DATA>
 ? ? ?<TXID>23</TXID>
 ? ? ?<LENGTH>0</LENGTH>
 ? ? ?<INODEID>16386</INODEID>
 ? ? ?<PATH>/input</PATH>
 ? ? ?<TIMESTAMP>1558105166840</TIMESTAMP>
 ? ? ?<PERMISSION_STATUS>
 ? ? ? ?<USERNAME>root</USERNAME>
 ? ? ? ?<GROUPNAME>supergroup</GROUPNAME>
 ? ? ? ?<MODE>493</MODE>
 ? ? ?</PERMISSION_STATUS>
 ? ?</DATA>
 ?</RECORD>
</EDITS>

blk_${BLOCK-ID}_xxx.meta：
是一個raw G3 data, byte-padded格式的文件，主要存儲目錄下的inode記錄

對于文件來說：

blk_${BLOCK-ID} ：
記錄的是block中的實際數(shù)據

blk_${BLOCK-ID}_xxx.meta：
CRC32校驗文件，保存數(shù)據塊的校驗信息

3、驗證數(shù)據塊完整性

1）datanode讀取block時，會計算其對于的checksum，如果和創(chuàng)建block時的checksum不同，那么證明該當前datanode上的該block已經損壞。此時client就會想存儲該block 的其他datanode節(jié)點請求讀取該block。 2）datanode在創(chuàng)建了block之后，會周期性檢查block是否損壞，也是通過檢查checksum的方式實現(xiàn)的。

4、datanode超時參數(shù)設置

datanode進程死亡，或者因為網絡故障導致datanode無法與namenode通信，namenode不會立刻把該datanode判定為死亡，而是經過一段時間內，該datanode都沒有心跳信息的話，就判定為死亡。而超時時間的計算公式為：

timeout ?= 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval

dfs.namenode.heartbeat.recheck-interval：是namenode檢查datanode是否存活的時間間隔，默認是為 5分鐘，單位是毫秒
dfs.heartbeat.interval：datanode上傳心跳信息的時間間隔，默認是3秒，單位是秒

兩者都在 hdfs-site.xml中進行設置

5、datanode的多目錄配置

datanode的多目錄配置和namenode不同，多目錄之間的數(shù)據是不相同的，而是將block數(shù)據分成兩部分，分別放到兩個目錄下而已。配置如下：

//hdfs-site.xml
<property>
 ? ? ? ?<name>dfs.datanode.data.dir</name>
 ? ? ?<value>file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2</value>
</property>

6、關于block的實際大小

雖然說每個block的大小都是128M（hadoop2.x），即使存儲的數(shù)據實際大小并沒有128M，也仍舊占據128M。但是實際存儲到磁盤上時占據的是數(shù)據實際大小，而不是128M。因為物理磁盤的block默認是4KB，所以不可能是會白占128M。