这是我参与更文挑战的第28天，活动详情查看：更文挑战
一、前言
Hadoop由三个模块组成:
- 分布式存储
HDFS- 分布式计算
MapReduce- 资源调度引擎
Yarn
HDFS 架构图：
HDFS 是设计成适应一次写入，多次读出的场景，且不支持文件的随机修改。（支持追加写入，不支持随机更新）
HDFS适合用来做大数据分析的底层存储服务，并不适合用来做网盘等应用（修改不方便，延迟大，网络开销大，成本太高）
二、核心概念
（1）块
为了提高磁盘读写效率，以数据块为单位，而不是以字节为单位（数据块包含若干字节）。 同时一定情况下，减少磁盘寻址开销
Hadoop 3.x版本，默认数据块大小为 128M，旧版本为 64M
所以，在HDFS 3.x版本下，上传文件，会按照 128M 为单位，切分成一个个块（block），并分散的存储在集群的不同数据节点上
问题：若上传一个文件（文件大小：30M），占据的块会是 128M 嘛？
不会，块大小仍是
30M
（2）名称节点（NameNode）
名称节点（NameNode）：负责管理分布式文件系统的命名空间（Namespace）
名称节点记录了每个文件中各个块所在的数据节点的位置信息
作用：
- 维护管理
HDFS的名称空间（Namespace） - 维护副本策略
- 记录文件块（
Block）的映射信息 - 负责处理客户端读写请求
保存了两个核心的数据结构：
FsImage：用于维护文件系统树以及文件树中所有的文件和文件夹的元数据EditLog：记录了所有针对文件的创建、删除、重命名等操作
名称节点的数据结构图：
名称节点启动
- 启动开始时 名称节点在启动的过程中处于： 安全模式
安全模式下：只能对外提供读操作，无法提供写操作
- 启动过程中
会将FsImage的内容加载进内存中，并执行 EditLog文件中的各项操作
这时候
HDFS中的更新操作都会被写入到EditLog，而不是直接写入FsImage
操作完成之后，会创建一个新的FsImage文件和一个空的EditLog文件
名称节点起来之后，
HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢。
- 启动过程结束
系统会退出安全模式，进入正常运行状态，对外提供读写操作
（3）数据节点（DataNode）
数据节点：是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。
（4）第二名称节点（SecondaryNameNode）
问题：更新操作不断写入 EditLog，EditLog不断变大，如何减少文件大小呢？
第二名称节点：用于冷备份，保存名称节点中对HDFS元数据信息，减少名称节点重启的时间
功能：
- 完成
EditLog和FsImage的合并操作
减少
EditLog文件大小，缩短名称节点重启时间
- 作为名称节点的 “检查点”，保存名称节点中的元数据信息
周期性地备份名称节点中的元数据信息，当名称节点发生故障时，就可以用第二名称节点中记录的元数据信息进行系统恢复。
当名称节点发生故障时，系统还是有可能会丢失部分元数据信息（即使有第二名称节点）
假设，第二名称节点执行合并操作时间为: t1 ~ t2
而这时候，名称节点刚好故障，系统就会丢失部分元数据信息
第二名称节点工作过程图，如下：
