HDFS详解(2)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: HDFS详解

第4章 HDFS的数据流

4.1 HDFS写数据流程

4.1.1 剖析文件写入

HDFS写数据流程,如图所示


为.png


1)客户端通过Distributed FileSystem模块向NameNode请求上传文件,NameNode检查目标文件是否已存在,父目录是否存在。


2)NameNode返回是否可以上传。


3)客户端请求第一个 block上传到哪几个datanode服务器上。


4)NameNode返回3个datanode节点,分别为dn1、dn2、dn3。


5)客户端通过FSDataOutputStream模块请求dn1上传数据,dn1收到请求会继续调用dn2,然后dn2调用dn3,将这个通信管道建立完成。


6)dn1、dn2、dn3逐级应答客户端。


7)客户端开始往dn1上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,dn1收到一个packet就会传给dn2,dn2传给dn3;


8)当一个block传输完成之后,客户端再次请求NameNode上传第二个block的服务器。(重复执行3-7步)。


4.2 HDFS读数据流程

HDFS的读数据流程,如图所示


去.png


1)客户端通过Distributed FileSystem向NameNode请求下载文件,NameNode通过查询元数据,找到文件块所在的DataNode地址。


2)挑选一台DataNode(就近原则,然后随机)服务器,请求读取数据。


3)DataNode开始传输数据给客户端(从磁盘里面读取数据输入流,以packet为单位来做校验)。


4)客户端以packet为单位接收,先在本地缓存,然后写入目标文件。


第5章 NameNode和SecondaryNameNode工作机制

其.png


5.1 NN和2NN工作机制

NN和2NN工作机制,如图所示

请.png



1. 第一阶段:NameNode启动


(1)第一次启动NameNode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。


(2)客户端对元数据进行增删改的请求。


(3)NameNode记录操作日志,更新滚动日志。


(4)NameNode在内存中对数据进行增删改查。


2. 第二阶段:Secondary NameNode工作


(1)Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果。


(2)Secondary NameNode请求执行checkpoint。


(3)NameNode滚动正在写的edits日志。


(4)将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。


(5)Secondary NameNode加载编辑日志和镜像文件到内存,并合并。


(6)生成新的镜像文件fsimage.chkpoint。


(7)拷贝fsimage.chkpoint到NameNode。


(8)NameNode将fsimage.chkpoint重新命名成fsimage。


NN和2NN工作机制详解:


Fsimage:namenode内存中元数据序列化后形成的文件。


Edits:记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)。


namenode启动时,先滚动edits并生成一个空的edits.inprogress,然后加载edits(归档后的)和fsimage(最新的)到内存中,此时namenode内存就持有最新的元数据信息。client开始对namenode发送元数据的增删改查的请求,这些请求的操作首先会被记录的edits.inprogress中(查询元数据的操作不会被记录在edits中,因为查询操作不会更改元数据信息),如果此时namenode挂掉,重启后会从edits中读取元数据的信息。然后,namenode会在内存中执行元数据的增删改查的操作。


由于edits中记录的操作会越来越多,edits文件会越来越大,导致namenode在启动加载edits时会很慢,所以需要对edits和fsimage进行合并(所谓合并,就是将edits和fsimage加载到内存中,照着edits中的操作一步步执行,最终形成新的fsimage)。secondarynamenode的作用就是帮助namenode进行edits和fsimage的合并工作。


secondarynamenode首先会询问namenode是否需要checkpoint(触发checkpoint需要满足两个条件中的任意一个,定时时间到和edits中数据写满了)。直接带回namenode是否检查结果。secondarynamenode执行checkpoint操作,首先会让namenode滚动edits并生成一个空的edits.inprogress,滚动edits的目的是给edits打个标记,以后所有新的操作都写入edits.inprogress,其他未合并的edits和fsimage会拷贝到secondarynamenode的本地,然后将拷贝的edits和fsimage加载到内存中进行合并,生成fsimage.chkpoint,然后将fsimage.chkpoint拷贝给namenode,重命名为fsimage后替换掉原来的fsimage。namenode在启动时就只需要加载之前未合并的edits和fsimage即可,因为合并过的edits中的元数据信息已经被记录在fsimage中。


5.2 Fsimage和Edits解析

1. 概念


namenode被格式化之后,将在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目录中产生如下文件
fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION


(1)Fsimage文件:HDFS文件系统元数据的一个永久性的检查点,其中包含HDFS文件系统的所有目录和文件的序列化信息。


(2)Edits文件:存放HDFS文件系统的所有更新操作的路径,文件系统客户端执行的所有写操作首先会被记录到edits文件中。


(3)seen_txid文件保存的是一个数字,就是最后一个edits_的数字


(4)每次NameNode启动的时候都会将fsimage文件读入内存,并edits里面的更新操作,保证内存中的元数据信息是最新的、同步的,可以看成NameNode启动的时候就将fsimage和edits文件进行了合并。


2. oiv查看fsimage文件


(1)查看oiv和oev命令


[root@hadoop101 current]$ hdfs
oiv                 apply the offline fsimage viewer to an fsimage
oev                  apply the offline edits viewer to an edits file


(2)基本语法


hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径


(3)案例实操


[root@hadoop101 current]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current
[root@hadoop101 current]$ hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml
[root@hadoop101 current]$ cat /opt/module/hadoop-2.7.2/fsimage.xml


将显示的xml文件内容拷贝到Idea中创建的xml文件中,并格式化。部分显示结果如下。Xml参数必须大写


<inode>
<id>16386</id>
<type>DIRECTORY</type>
<name>user</name>
<mtime>1512722284477</mtime>
<permission>root:supergroup:rwxr-xr-x</permission>
<nsquota>-1</nsquota>
<dsquota>-1</dsquota>
</inode>
<inode>
<id>16387</id>
<type>DIRECTORY</type>
<name>root</name>
<mtime>1512790549080</mtime>
<permission>root:supergroup:rwxr-xr-x</permission>
<nsquota>-1</nsquota>
<dsquota>-1</dsquota>
</inode>
<inode>
<id>16389</id>
<type>FILE</type>
<name>wc.input</name>
<replication>3</replication>
<mtime>1512722322219</mtime>
<atime>1512722321610</atime>
<perferredBlockSize>134217728</perferredBlockSize>
<permission>root:supergroup:rw-r--r--</permission>
<blocks>
<block>
<id>1073741825</id>
<genstamp>1001</genstamp>
<numBytes>59</numBytes>
</block>
</blocks>
</inode >


3. oev查看edits文件


(1)基本语法


hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径


(2)案例实操


[root@hadoop101 current]$ hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml
[root@hadoop101 current]$ cat /opt/module/hadoop-2.7.2/edits.xml


将显示的xml文件内容拷贝到Idea中创建的xml文件中,并格式化。显示结果如下。


<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
<EDITS_VERSION>-63</EDITS_VERSION>
<RECORD>
<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
<DATA>
<TXID>129</TXID>
</DATA>
</RECORD>
<RECORD>
<OPCODE>OP_ADD</OPCODE>
<DATA>
<TXID>130</TXID>
<LENGTH>0</LENGTH>
<INODEID>16407</INODEID>
<PATH>/hello7.txt</PATH>
<REPLICATION>2</REPLICATION>
<MTIME>1512943607866</MTIME>
<ATIME>1512943607866</ATIME>
<BLOCKSIZE>134217728</BLOCKSIZE>
<CLIENT_NAME>DFSClient_NONMAPREDUCE_-1544295051_1</CLIENT_NAME>
<CLIENT_MACHINE>192.168.1.5</CLIENT_MACHINE>
<OVERWRITE>true</OVERWRITE>
<PERMISSION_STATUS>
<USERNAME>root</USERNAME>
<GROUPNAME>supergroup</GROUPNAME>
<MODE>420</MODE>
</PERMISSION_STATUS>
<RPC_CLIENTID>908eafd4-9aec-4288-96f1-e8011d181561</RPC_CLIENTID>
<RPC_CALLID>0</RPC_CALLID>
</DATA>
</RECORD>
<RECORD>
<OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
<DATA>
<TXID>131</TXID>
<BLOCK_ID>1073741839</BLOCK_ID>
</DATA>
</RECORD>
<RECORD>
<OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
<DATA>
<TXID>132</TXID>
<GENSTAMPV2>1016</GENSTAMPV2>
</DATA>
</RECORD>
<RECORD>
<OPCODE>OP_ADD_BLOCK</OPCODE>
<DATA>
<TXID>133</TXID>
<PATH>/hello7.txt</PATH>
<BLOCK>
<BLOCK_ID>1073741839</BLOCK_ID>
<NUM_BYTES>0</NUM_BYTES>
<GENSTAMP>1016</GENSTAMP>
</BLOCK>
<RPC_CLIENTID></RPC_CLIENTID>
<RPC_CALLID>-2</RPC_CALLID>
</DATA>
</RECORD>
<RECORD>
<OPCODE>OP_CLOSE</OPCODE>
<DATA>
<TXID>134</TXID>
<LENGTH>0</LENGTH>
<INODEID>0</INODEID>
<PATH>/hello7.txt</PATH>
<REPLICATION>2</REPLICATION>
<MTIME>1512943608761</MTIME>
<ATIME>1512943607866</ATIME>
<BLOCKSIZE>134217728</BLOCKSIZE>
<CLIENT_NAME></CLIENT_NAME>
<CLIENT_MACHINE></CLIENT_MACHINE>
<OVERWRITE>false</OVERWRITE>
<BLOCK>
<BLOCK_ID>1073741839</BLOCK_ID>
<NUM_BYTES>25</NUM_BYTES>
<GENSTAMP>1016</GENSTAMP>
</BLOCK>
<PERMISSION_STATUS>
<USERNAME>root</USERNAME>
<GROUPNAME>supergroup</GROUPNAME>
<MODE>420</MODE>
</PERMISSION_STATUS>
</DATA>
</RECORD>
</EDITS >


5.3 checkpoint时间设置

(1)通常情况下,SecondaryNameNode每隔一小时执行一次。如果修改在hdfs-site中


默认值在[hdfs-default.xml]


<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
</property>


(2)一分钟检查一次操作次数,当操作次数达到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 >


5.4 集群安全模式

1. 概述


NameNode启动时,首先将映像文件(fsimage)载入内存,并执行编辑日志(edits)中的各项操作。一旦在内存中成功建立文件系统元数据的映像,则创建一个新的fsimage文件和一个空的编辑日志。此时,NameNode开始监听DataNode请求。但是此刻,NameNode运行在安全模式,即NameNode的文件系统对于客户端来说是只读的。


系统中的数据块的位置并不是由NameNode维护的,而是以块列表的形式存储在DataNode中。在系统的正常操作期间,NameNode会在内存中保留所有块位置的映射信息。在安全模式下,各个DataNode会向NameNode发送最新的块列表信息,NameNode了解到足够多的块位置信息之后,即可高效运行文件系统。


如果满足“最小副本条件”,NameNode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别(默认值:dfs.replication.min=1)。在启动一个刚刚格式化的HDFS集群时,因为系统中还没有任何块,所以NameNode不会进入安全模式。


基本语法

集群处于安全模式,不能执行重要操作(写操作)。集群启动完成后,自动退出安全模式。


(1)bin/hdfs dfsadmin -safemode get (功能描述:查看安全模式状态)
(2)bin/hdfs dfsadmin -safemode enter   (功能描述:进入安全模式状态)
(3)bin/hdfs dfsadmin -safemode leave (功能描述:离开安全模式状态)
(4)bin/hdfs dfsadmin -safemode wait (功能描述:等待安全模式状态,监控安全模式)


3. 案例


模拟等待安全模式


(1)先进入安全模式


[root@hadoop101 hadoop-2.7.2]$ bin/hdfs dfsadmin -safemode enter


(2)执行下面的脚本


编辑一个脚本


#!/bin/bash
bin/hdfs dfsadmin -safemode wait(安全模式关闭)
bin/hdfs dfs -put ~/hello.txt /root/hello.txt


(3)再打开一个窗口,执行


[root@hadoop101 hadoop-2.7.2]$ bin/hdfs dfsadmin -safemode leave


第6章 DataNode工作机制

6.1 DataNode工作机制

DataNode工作机制,如图所示


去.png

1)一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。


2)DataNode启动后向NameNode注册,通过后,周期性(1小时)的向NameNode上报所有的块信息。


3)心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
6月前
|
存储 分布式计算 安全
|
7月前
|
存储 分布式计算 Hadoop
Hadoop分布式文件系统(HDFS)
【5月更文挑战第10天】
90 3
|
存储 分布式计算 资源调度
Hadoop HDFS(分布式文件系统)
Hadoop HDFS(分布式文件系统)
94 0
|
存储 机器学习/深度学习 分布式计算
HDFS最基础使用
HDFS最基础使用
125 0
|
大数据
HDFS
HDFS
53 0
|
机器学习/深度学习 存储 分布式计算
深入理解HDFS 一
深入理解HDFS 一
149 0
|
存储 分布式计算 Hadoop
|
存储 分布式计算 并行计算
第2章 Hadoop分布式文件系统HDFS
第2章 Hadoop分布式文件系统HDFS
626 0
|
存储 机器学习/深度学习 分布式计算
【Hadoop】(一)分布式文件系统 HDFS
【Hadoop】(一)分布式文件系统 HDFS
197 0
【Hadoop】(一)分布式文件系统 HDFS
|
存储 分布式计算 监控
HDFS1.0 与HDFS2.x 架构理解
HDFS1.0 与HDFS2.x 架构理解
328 0
HDFS1.0 与HDFS2.x 架构理解