目录
HDFS
（
Hadoop Distributed File System
），它是一个文件系统
，用于存储文件，通过目
录树来定位文件；
其次，它是分布式的
，由很多服务器联合起来实现其功能，集群中的服务
器有各自的角色。
HDFS
的使用场景：适合一次写入，多次读出的场景。
一个文件经过创建、写入和关闭
之后就不需要改变。
HDFS 优缺点
HDFS
优点
1
）高容错性
➢ 数据自动保存多个副本。它通过增加副本的形式，提高容错性。
➢ 某一个副本丢失以后，它可以自动恢复。
2
）适合处理大数据
➢ 数据规模：能够处理数据规模达到GB
、
TB
、甚至
PB
级别的数据
；
➢ 某一个副本丢失以后，它可以自动恢复。
➢ 文件规模：能够处理
百万
规模以上的
文件数量
，数量相当之大。
3
）可
构建在廉价机器上
，通过多副本机制，提高可靠性。
HDFS
缺点
1
）
不适合低延时数据访问
，比如毫秒级的存储数据，是做不到的。
2
）
无法高效的对大量小文件进行存储。
➢ 存储大量小文件的话，它会占用NameNode
大量的内存来存储文件目录和
块信息。这样是不可取的，因为
NameNode
的内存总是有限的；
➢ 小文件存储的寻址时间会超过读取时间，它违反了HDFS
的设计目标。
3
）不支持并发写入、文件随机修改。
➢ 一个文件只能有一个写，不允许多个线程同时写；
➢ 仅支持数据append
（追加），
不支持文件的随机修改。
HDFS 组成架构
3
）
Client
：就是客户端。
（
1
）文件切分。文件上传
HDFS
的时候，
Client
将文件切分成一个一个的
Block
，然后进行上传；
（
2
）与
NameNode
交互，获取文件的位置信息；
（
3
）与
DataNode
交互，读取或者写入数据；
（
4
）
Client
提供一些命令来管理
HDFS
，比如
NameNode
格式化；
（
5
）
Client
可以通过一些命令来访问
HDFS
，比如对
HDFS
增删查改操作；
4
）
Secondary NameNode
：并非
NameNode
的热备。当
NameNode
挂掉的时候，它并不
能马上替换
NameNode
并提供服务。
（
1
）辅助
NameNode
，分担其工作量，比如定期合并
Fsimage
和
Edits
，并推送给
NameNode
；
（
2
）在紧急情况下，可辅助恢复
NameNode
。
HDFS 文件块大小
思考：为什么块的大小不能设置太小，也不能设置太大？
（
1
）
HDFS
的块设置
太小
，
会增加寻址时间
，程序一直在找块的开始位置；
（
2
）如果块设置的
太大
，从
磁盘传输数据的时间
会明显
大于定位这个块开
始位置所需的时间
。导致程序在处理这块数据时，会非常慢。
总结：
HDFS
块的大小设置主要取决于磁盘传输速率。
HDFS 写数据流程
网络拓扑-节点距离计算
在
HDFS
写数据的过程中，
NameNode
会选择距离待上传数据最近距离的
DataNode
接
收数据。那么这个最近距离怎么计算呢？
节点距离：两个节点到达最近的共同祖先的距离总和。
HDFS 读数据流程
（
1
）客户端通过
DistributedFileSystem
向
NameNode
请求下载文件，
NameNode
通过查
询元数据，找到文件块所在的
DataNode
地址。
（
2
）挑选一台
DataNode
（就近原则，然后随机）服务器，请求读取数据。
（
3
）
DataNode
开始传输数据给客户端（从磁盘里面读取数据输入流，以
Packet
为单位
来做校验）。
（
4
）客户端以
Packet
为单位接收，先在本地缓存，然后写入目标文件。
NameNode 和 SecondaryNameNode
NN 和 2NN 工作机制
思考：
NameNode
中的元数据是存储在哪里的？
首先，我们做个假设，如果存储在
NameNode
节点的磁盘中，因为经常需要进行随机访
问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在
内存中，一旦断电，元数据丢失，整个集群就无法工作了。
因此产生在磁盘中备份元数据的
FsImage
。
这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新
FsImage
，就会导
致效率过低，但如果不更新，就会发生一致性问题，一旦
NameNode
节点断电，就会产生数
据丢失。
因此，引入
Edits
文件（只进行追加操作，效率很高）。每当元数据有更新或者添
加元数据时，修改内存中的元数据并追加到
Edits
中。
这样，一旦
NameNode
节点断电，可
以通过
FsImage
和
Edits
的合并，合成元数据。
但是，如果长时间添加数据到
Edits
中，会导致该文件数据过大，效率降低，而且一旦
断电，恢复元数据需要的时间过长。因此，需要定期进行
FsImage
和
Edits
的合并，如果这
个操作由
NameNode
节点完成，又会效率过低。
因此，引入一个新的节点
SecondaryNamenode
，
专门用于
FsImage
和
Edits
的合并。
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
。
Fsimage 和 Edits 解析
NameNode被格式化之后，将在/opt/module/hadoop-3.1.3/data/tmp/dfs/name/current目录中产生如下文件
fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION
（
1
）
Fsimage
文件：
HDFS
文件系统元数据的一个
永久性的检查点
，其中包含
HDFS
文件系统的所有目 录和文件inode
的序列化信息。
（
2
）
Edits
文件：存放
HDFS
文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先 会被记录到Edits
文件中。
（
3
）
seen_txid
文件保存的是一个数字，就是最后一个
edits_
的数字
（
4
）每 次
NameNode
启动的时候
都会将
Fsimage
文件读入内存，加 载
Edits
里面的更新操作，保证内存 中的元数据信息是最新的、同步的，可以看成
NameNode
启动的时候就将
Fsimage
和
Edits
文件进行了合并。
DataNode 工作机制
数据完整性
思考：如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号（
1
）和绿灯信号（
0
），
但是存储该数据的磁盘坏了，一直显示是绿灯，是否很危险？同理
DataNode
节点上的数据
损坏了，却没有发现，是否也很危险，那么如何解决呢？
如下是
DataNode
节点保证数据完整性的方法。
（
1
）当
DataNode
读取
Block
的时候，它会计算
CheckSum
。
（
2
）如果计算后的
CheckSum
，与
Block
创建时值不一样，说明
Block
已经损坏。
（
3
）
Client
读取其他
DataNode
上的
Block
。
（
4
）常见的校验算法
crc
（
32
），
md5
（
128
），
sha1
（
160
）
（
5
）
DataNode
在其文件创建后周期验证
CheckSum
。
掉线时限参数设置
1
、
DataNode
进程死亡或 者网络故障造成DataNode 无法与NameNode
通信.
2
、
NameNode
不会立即把该节点判定 为死亡，要经过一段时间，这段时间 暂称作超时时长。
3
、
HDFS
默认的超时时长为
10
分钟
+30
秒。
4
、如果定义超时时间为
TimeOut
，则超时时长的计算公式为：
TimeOut = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval
。
而默认的
dfs.namenode.heartbeat.recheck-interval
大小为
5
分钟，
dfs.heartbeat.interval
默认为
3
秒。
扫一扫
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
