文章作者邮箱：yugongshiye@sina.cn 地址：广东惠州

▲ 本章节目的

⚪ 了解hadoop的定义和特点；

⚪ 掌握hadoop的基础结构；

⚪ 掌握hadoop的常见命令；

⚪ 了解hadoop的执行流程；

一、简介

1. 概述

1. HDFS(Hadoop Distributed File System - Hadoop分布式文件系统)是Hadoop提供的一套用于进行分布式存储的机制。

2. HDFS是Doug Cutting根据Google的论文<The Google File System>(GFS)来仿照实现的。

2. 特点

1. 能够存储超大文件。在HDFS集群中，只要节点数量足够多，那么一个文件无论是多大都能够进行存储 - HDFS会对文件进行切块处理。

2. 快速的应对和检测故障。在HDFS集群中，运维人员不需要频繁的监听每一个节点，可以通过监听NameNode来确定其他节点的状态 - DataNode会定时的给NameNode来发送心跳。

3. 具有高容错性。在HDFS中，会自动的对数据来保存多个副本，所以不会因为一个或者几个副本的丢失就导致数据产生丢失。

4. 具有高吞吐量。吞吐量实际上指的是集群在单位时间内读写的数据总量。

5. 可以在相对廉价的机器上来进行横向扩展。

6. 不支持低延迟的访问。在HDFS集群中，响应速度一般是在秒级别，很难做到在毫秒级别的响应。

7. 不适合存储大量的小文件。每一个小文件都会产生一条元数据，大量的小文件就会产生大量的元数据。元数据过多，会占用大量内存，同时会导致查询效率变低。

8. 简化的一致性模型。在HDFS中，允许对文件进行一次写入多次读取，不允许修改，但是允许追加写入。

9. 不支持超强事务甚至不支持事务。在HDFS中，因为数据量较大，此时不会因为一个或者几个数据块出现问题就导致所有的数据重新写入 - 在数据量足够大的前提下，允许出现容错误差。

二、基本概念

1. 基本结构

1. HDFS本身是一个典型的主从(M/S)结构：主节点是NameNode，从节点是DataNode。

2. HDFS会对上传的文件进行切分处理，切出来的每一个数据块称之为Block。

3. HDFS会对上传的文件进行自动的备份。每一个备份称之为是一个副本(replication/replicas)。如果不指定，默认情况下，副本数量为3。

4. HDFS仿照Linux设计了一套文件系统，允许将文件存储到不同的虚拟路径下，同时也设计了一套和Linux一样的权限策略。HDFS的根路径是/。

2. Block

1. Block是HDFS中数据存储的基本形式，即上传到HDFS上的数据最终都会以Block的形式落地到DataNode的磁盘上。

2. 如果不指定，默认情况下，Block的大小是134217728B(即128M)。可以通过dfs.blocksize属性来调节，放在hdfs-site.xml文件中，单位是字节。

3. 如果一个文件不足一个Block的指定大小，那么这个文件是多大，它所对应的Block就是多大。例如一个文件是70M，那么对应的Block就是70M。属性dfs.blocksize指定的值实际上可以立即为一个Block的最大容量。

4. 注意，在设计Block大小的时候，Block是维系在DataNode的磁盘上，要考虑Block在磁盘上的寻址时间以及传输时间(写入时间)的比例值。一般而言，当寻址时间是传输时间的1%的时候，效率最高。而计算机在磁盘上的寻址时间大概在10ms左右，那么写入时间就是10ms/0.01=1000ms=1s。考虑到绝大部分的服务器使用的是机械磁盘，机械磁盘的写入速度一般在120MB/s左右，此时一个Block大小是1s*120MB/s=120M左右。

5. HDFS会为每一个Block来分配一个唯一的编号BlockID。

6. 切块的意义：

a. 能够存储超大文件。

b. 能够进行快速备份。

3. NameNode

1. NameNode是HDFS中的主(核心)节点。在Hadoop1.X中，NameNode只能有1个，容易存在单点故障；在Hadoop2.X中，NameNode最多允许存在2个；在Hadoop3.X中，不再限制NameNode的数量，也因此在Hadoop3.X的集群中，NameNode不存在单点故障。

2. NameNode的作用：对外接收请求，记录元数据，管理DataNode。

3. 元数据(metadata)是用于描述数据的数据(大概可以将元数据理解为账本)。在HDFS中，元数据实际上是用于描述文件的一些性质。在HDFS中，将元数据拆分成了很多项，主要包含了以下几项：

a. 上传的文件名以及存储的虚拟路径，例如/log/a.log。

b. 文件对应的上传用户以及用户组。

c. 文件的权限，例如-rwxr-xr--。

d. 文件大小。

e. Block大小。

f. 文件和BlockID的映射关系。

g. BlockID和DataNode的映射关系。

h. 副本数量等。

4. 一条元数据大小大概在150B左右。

5. 元数据是维系在内存以及磁盘中。

a. 维系在内存中的目的是查询快

b. 维系在磁盘中的目的是持久化

6. 元数据在磁盘上的存储位置由属性hadoop.tmp.dir来决定，是放在core-site.xml文件中。如果不指定，默认情况下是放在/tmp下。

7. 和元数据相关的文件：

a. edits：写操作文件。用于记录HDFS的写操作。

b. fsimage：元映像文件。存储了NameNode对元数据的序列化形态(大概可以理解为元数据在磁盘上的持久化存储形式)。

8. 当NameNode接收到写操作(命令)的时候，会先将这个写操作(命令)记录到edits_inprogress文件中。记录成功之后，NameNode会解析这个命令，然后修改内存中的元数据。修改成功之后，会给客户端来返回一个ACK信号表示成功。在这个过程中，会发现，fsimage文件中的元数据并没有发生变化。

9. 随着运行时间的推移，edits_inprogress文件中记录的命令会越来越多，同时fsiamge文件中的元数据和内存中的元数据差别也会越来越大。因此，当达到指定条件的时候，edits_inprogress这个文件会产生滚动，滚动生成一个edits文件，同时产生一个新的edits_ingprogress文件。新来的写操作会记录到新的edits_inprogress文件中。滚动生成edits文件之后，NameNode会将edits文件中的命令再一一取出，解析之后修改fsimage文件中的元数据。

10. edits_inprogress文件的滚动条件：

a. 空间：当edits_inprogress文件达到指定大小(默认是40000，即当edits_inprogress文件中记录的元数据条目数达到40000条，可以通过属性dfs.namenode.checkpoint.txns来修改，放在hdfs-site.xml文件中)的时候，会自动滚动生成一个edits文件。

b. 时间：当距离上一次的滚动时间间隔达到指定大小(默认是3600s，可以通过属性dfs.namenode.checkpoint.period来修改，单位是秒，放在hdfs-site.xml文件汇总)的时候，edits_inprogress文件也会产生滚动。

c. 重启：当NameNode被重启的时候，会自动触发edits_inprogress文件的滚动。

d. 强制：可以通过hdfs dfsadmin -rollEdits命令来强制滚动。

11. 查看edits文件：hdfs oev -i edits_0000000000000000002-0000000000000000009 -o edits.xml

12. 在HDFS中，会将每一个写操作看作是一个事务，会给这个事务分配一个全局递增的编号，称之为事务id，简写为txid

13. 在HDFS中，会将开始记录日志以及结束记录日志都看作是一个写操作，都会分配一个事务id。因此，每一个edits文件，基本上都是以OP_START_LOG_SEGMENT开头，都是以OP_END_LOG_SEGMENT结尾

14. 查看fsimage文件：hdfs oiv -i fsimage_0000000000000000009 -o fsimage.xml -p XML

15. 每一个fsimage文件都会伴随着产生一个.md5文件，这个文件是对fsimage文件进行校验的

16. 需要注意的是，Hadoop在第一次启动之后的1min的时候，会自动触发一次edits_inprogress文件的滚动，之后就是按照指定的时间间隔来进行滚动

17. NameNode通过心跳机制来管理DataNode：DataNode会定时(默认是3s，通过属性dfs.heartbeat.interval来决定，单位是秒，放在hdfs-site.xml文件中)给NameNode发送心跳。如果超过指定的时间，NameNode没有收到DataNode的心跳，那么NameNode就会认为这个DataNode已经lost(丢失)，此时NameNode会将这个DataNode上的数据复制一份备份到其他节点上来保证整个集群中的副本数量

18. 心跳的超时时间是由属性dfs.namenode.heartbeat.recheck-interval来决定。如果不指定，默认是300000，单位是毫秒，即300s=5min。但是在计算超时时间的时候，实际超时时间=2*dfs.namenode.heartbeat.recheck-interval + 10*dfs.heartbeat.interval来决定，所以如果不指定，实际超时时间为 2*5min + 10*3s = 10min30s

19. 心跳信号主要包含：

a. clusterid：集群编号。

Ⅰ. 在HDFS中，当NameNode被格式化(hadoop namenode -format)的时候，会自动计算产生一个clusterid。每次NameNode被格式化，都会自动重新计算产生一个新的clusterid。

Ⅱ. 当HDFS集群启动之后，NameNode就会等待DataNode的心跳。当NameNode第一次收到DataNode的心跳之后，会将clusterid在心跳响应中返回给DataNode。

Ⅲ. 当DataNode收到心跳响应之后，会将clusterid获取并且记录到本地的磁盘中，之后DataNode和NameNode之间进行的每一次通信(包括心跳)都会携带这个clusterid。

Ⅳ. NameNode在收到DataNode的请求之后，会先校验clusterid是否一致，如果不一致，则会放弃这个请求；如果一致，才会处理这个请求。

Ⅴ. 如果NameNode被多次格式化，就会导致DataNode和NameNode之间无法进行通信。

b. 当前DataNode的节点状态(预服役、服役、预退役)。

c. 当前DataNode上存储的Block的校验信息。

20. 安全模式：

a. 当NameNode被重启之后，自动进入安全模式。

b. 在安全模式中，NameNode会先自动触发edits_inprogress文件的滚动，滚动完成之后，会触发fsimage文件的更新。fsiamge文件更新完成之后，NameNode会将fsimage文件中的元数据加载到内存中，加载完成之后，会等待DataNode的心跳。

c. 如果没有收到DataNode的心跳，那么说明NameNode被重启过程中，DataNode也出现了骨渣古，此时NameNode就需要将DataNode上的数据备份到其他节点上来保证集群中的副本数量；如果NameNode收到了DataNode的心跳，会校验DataNode上的Block信息。如果校验失败，那么NameNode会试图恢复这个DataNode上的数据，恢复完成之后会再次校验，如果校验失败，则重新恢复重新校验；如果校验成功，则NameNode自动退出安全模式。

21. 之所以存在安全模式，实际上是HDFS集群保证数据的完整性。

22. 在安全模式中，HDFS集群只能读(下载)不能写(上传)。

23. 在实际过程中，如果在合理时间内，HDFS集群依然没有退出安全模式，则说明数据已经产生了不可挽回的丢失，此时需要考虑强制退出安全模式。

24. 常见命令：

命令	解释
hdfs dfsadmin -safemode enter	进入安全模式
hdfs dfsadmin -safemode get	查看安全模式状态
hdfs dfsadmin -safemode leave	退出安全模式

4. DataNode

1. DataNode是HDFS的从节点，主要用于存储数据，数据会以Block形式落地到磁盘上。

2. 数据在磁盘上的存储位置同样由hadoop.tmp.dir属性来决定。

3. DataNode会为每一个Block生成一个blk_xxx.meta文件，这个meta文件实际上是blk文件的校验文件。

4. DataNode的状态：预服役、服役、预退役、退役、丢失。

5. DataNode通过心跳机制向NameNode来注册信息。

5. SecondaryNameNode

1. SecondaryNameNode不是NameNode的热备份，但是SecondaryNameNode能够一定程度上对元数据做到备份，但不是全部 - SecondaryNameNode主要是负责edits_inprogress文件的滚动和fsimage文件的更新。

2. 在集群中，如果存在SecondaryNameNode，那么edits_inprogress文件的滚动和fsimage文件的更新是由SecondaryNameNode来完成；如果没有SecondaryNameNode，那么edits_inprogress文件的滚动和fsimage文件的更新就会由NameNode自己来完成。

3. 到目前为止，HDFS集群只支持两种结构：

a. 1个NameNode+1个SecondaryNameNode+n个DataNode。

b. n个NameNode(Hadoop2.X中是2个，Hadoop3.X中是n个，1个Active+多个Standby状态)+n个DataNode。

4. 在HDFS集群中，NameNode如果只有1个，那么NameNode宕机之后，整个集群就无法对外提供服务，所以必须对NameNode来进行备份，避免单点故障，所以在集群中，要考虑使用上述的第二种方案。

6. 机架感知策略

1. 在HDFS中，机架感知策略默认是不开启的。如果需要开启机架感知策略，那么需要在hadoop-site.xml文件中添加如下配置：

<name>topology.script.file.name</name>

<value>path/rackaware.py</value>

</property

2. 上述配置的value中，需要指定一个脚本文件的存储路径。脚本文件可以使用Python或者Shell等常见脚本语言来实现。

3. 在这个脚本中，需要定义一个Map。Map的键是主机名或者IP，Map的值是用户指定的机架名。只要保证值一致，那么就表示值对应的键放在同一个机架上。

4. 由于这个机架是通过Map映射来完成的，所以本质上是一个逻辑机架，也因此可以将不同物理机架上的节点配置在同一个逻辑机架上。在实际开发过程中，为了方便管理，往往是将同一个物理机架上的节点配置在同一个逻辑机架上。

7. 副本放置策略

1. 在HDFS中，支持多副本策略，这样能够有效的保证数据的可靠性。如果不指定，默认情况下，副本数量为3。通过属性dfs.replication来修改，放在hdfs-site.xml文件中

2. 在HDFS中，如果没有开启机架感知策略，那么默认也不会开启副本放置策略，那么此时多个副本是放在相对空闲的节点上

3. 如果启用了机架感知策略，那么对应的，HDFS也会启用副本放置策略。

a. 第一个副本：如果是集群内上传，则谁上传就放在谁身上；如果是集群外上传，则谁空闲就放在谁身上。

b. 第二个副本：放在和第一个副本相同机架的节点上。实际过程中，会考虑将同一个物理机架上的节点配置在同一个逻辑机架上，此时机架内传输会比跨机架传输要快一些。

c. 第三个副本：放在和第二个副本不同机架的节点上，保证不会因为一个机架整体出现故障导致数据产生丢失。

d. 更多副本：谁空闲放在谁身上。

8. 常见命令

命令	解释
start-dfs.sh	启动HDFS
stop-dfs.sh	结束HDFS
hdfs --daemon start namenode	启动NameNode
hdfs --daemon start datanode	启动DataNode
hdfs --daemon start secondarynamenode	启动SecondaryNameNode
hadoop fs -put /home/a.txt / 或者 hadoopfs -copyFromLocal /home/a.txt /	上传文件
hadoop fs -get /a.txt /home 或者 hadoop fs -copyToLocal /a.txt /home	下载文件
hadoop fs -mkdir /txt	创建目录
hadoop fs -mkdir -p /video/movie	创建多级目录
hadoop fs -rm /b.txt	删除文件
hadoop fs -rmdir /txt	删除目录
hadoop fs -rm -r /video	递归删除目录
hadoop fs -cat /c.txt	查看文件内容
hadoop fs -tail /c.txt	查看文件最后1000个字节的数据
hadoop fs -mv /c.txt /a.txt	重命名或者剪切
hadoop fs -cp /txt/a.txt /a.txt	复制文件
hadoop fs -ls /	查看子文件或者子目录
hadoop fs -ls -R /	递归查看
hadoop fs -setrep 3 /a.txt	设置副本数量
hadoop fs -chmod 777 /a.txt	更改权限
hadoop fs -chown tom /a.txt	更改用户
hadoop fs -chgrp tedu /a.txt	更改用户组

9. 回收站机制

1. 在HDFS中，回收站机制默认是不开启的，此时删除命令会立即生效，且该操作此时不可逆。

2. 配置回收站策略，配置在cores-site.xml中。

<name>fs.trash.interval</name>

</property>

3. 回收站的默认存放位置为/user/root/.Trash/Current/。

4. 如果需要将文件从回收站中还原回来，那么使用hadoop fs -mv命令即可。

三、流程

1. 写(上传)流程

1. 客户端发起RPC请求到NameNode，请求上传文件。

2. 当NameNode收到请求之后，会先进行校验：

a. 校验是否有指定路径 - FileNotFoundException。

b. 校验是否有写入权限 - AccessControlException。

c. 校验是否有同名文件 - FileAlreadyExistException。

3. 如果校验失败，则直接报错；如果校验成功，则NameNode会给客户端返回信号表示允许上传。

4. 当客户端收到信号之后，会再次给NameNode来发送请求，请求获取第一个Block的存储位置。

5. NameNode收到请求之后，会将这个Block的存储位置(实际上是DataNode的IP或者主机名，默认情况下会返回3个存储位置 - 副本数量为3)返回给客户端。

6. 客户端收到存储位置之后，会从这些地址中选取一个较近(实际上是网络拓扑距离)的地址，发送请求，请求建立pipeline(管道，实际上是基于NIO Channel)用于传输数据；第一个Block所在节点会给下一个Block所在的节点发送请求，请求建立pipeline；依此类推，直到最后一个请求应答成功。

7. 建立好管道应答成功之后，客户端会将当前的Block进行封包，将Packet写入第一个节点；写完之后，第一个Block所在的节点写入第二个节点，依次类推。

8. 当这个Block的所有副本写完之后，客户端会再次给NameNode发送请求，请求获取下一个Block的存储位置，重复5.6.7.8四个步骤，直到所有的Block全部写完。

9. 当客户端写完所有的Block之后，会给NameNode发送一个请求，请求关闭文件(关流)。文件一旦关闭，数据就不能修改。

2. 读(下载)流程

1. 客户端发起RPC请求到NameNode，请求下载文件。

2. NameNode收到请求之后，会先进行校验：

a. 校验是否有读取权限 - AccessControlException。

b. 校验是否有指定文件 - FileNotFoundException。

3. 如果校验失败，会直接报错；如果校验成功，则NameNode就会给客户端返回一个信号表示允许读取。

4. 客户端收到信号之后，会再次发送请求给NameNode，请求获取第一个Block的存储位置。

5. NameNode收到请求之后，会查询元数据，然后将这个Block的存储地址(默认情况下是3个)返回给客户端。

6. 客户端收到地址之后，会从这些地址中选取一个较近的地址来读取这个Block。

7. 读取完这个Block之后，客户端会对这个Block进行checkSum校验。如果校验失败，说明这个Block产生了变动，此时客户端会从剩余的地址中重新选取一个地址重新读取重新校验；如果校验成功，则客户端会再次给NameNode发送请求，请求获取下一个Block的存储位置，重复5.6.7三个步骤，直到读取完所有的Block。

8. 当客户端读取完最后一个Block之后，会给NameNode发送一个结束信号。NameNode收到信号之后会关闭这个文件。

3. 删除流程

1. 客户端发起RPC请求到NameNode，请求删除文件。

2. NameNode收到请求之后，会先进行校验：

a. 校验是否有删除权限 - AccessControlException。

b. 校验是否有指定文件 - FileNotFoundException。

3. 如果校验失败，则直接报错；如果校验成功，则NameNode会将这个写请求记录到edits_inprogress文件中，记录成功之后，会修改内存中的元数据；修改完成之后，NameNode会给客户端返回一个ACK信号表示删除成功。需要注意的是，此时文件并没有真正从HDFS上移除，仅仅是修改了元数据。

4. NameNode给客户端返回信号之后，就会等待DataNode的心跳。NameNode在收到DataNode的心跳之后，会在心跳响应中要求DataNode删除对应的Block。

5. DataNode在收到心跳响应之后，会按照NameNode的要求，去磁盘上删除文件对应的Block。注意，此时文件才真正的从HDFS上移除。