HDFS，是一个文件系统，全称为：Hadoop Distributed File System。用于存储文件通过，目录树来定位文件。其次，这是一个分布式的文件系统，由很多服务器联合起来实现其功能，集群中的服务器各自有各自的角色。

1. HDFS集群包括：NameNode和DataNode以及Secondary NameNode。
2. NameNode负责管理整个文件新系统的元数据，以及每一个路径（文件）所对应的数据块信息。
3. DataNode负责管理用户的文件数据块，每一个数据库块都可以在多个datanode上存储多个副本。
4. Secondary NameNode用啦监控HDFS状态的辅助后台程序，没隔一段时间获取HDFS元数据的快照。

• HDFS中的文件在物理上是分块存储（block），块的代销可以通过配置参数（dfs.blocksize）来规定，默认大小在hadoop2.X版本是128M，老版本则是64M。
• HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。如果块设置的足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需要的时间，因而传输一个由多个块组成的文件的时间取决于磁盘传输速率。
• 如果寻址时间约为10ms，而传输速率为100MB/s，为了是寻址时间占传输时间的1%，我们需要将块大小设置约为100MB。默认的块大小为128MB
• 块的大小：10ms100100M/s = 100M

1. 适合的应用场景

• 存储非常大的文件，需要高吞吐量，对延时没有要求
• 采用流式的数据访问方式：即一次写入，多次读取，数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作
• 运行于商业硬件上：Hadoop不需要特别贵的机器，可运行于普通廉价机器，可以节约成本
• 需要高容错性
• 为数据存储提供所需的扩展能力

2. 不适合的应用场景

• 低延时的数据访问对延时要求在毫秒级别的应用，不适合财通HDFS。HDFS是为高吞吐数据传输设计的，因此可能牺牲延迟
• 大量小文件。文件的元数据保存在NameNode的内存中，整个文件系统的文件数量会受限于NameNode的内存大小。经验而言，一个文件/目录/文件快一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件快，则需要大约300M的内存。因此10亿级别的文件数量在现有商用机器上难以支持。
• 多方读写，需要任意的文件修改HDFS采用追加的方式写入数据。不支持文件任意offset的修改，不支持多个写入器

概念：HDFS是一个主/从（Mater/Slave）体系结构。

HDFS由四部分组成。HDFSClient、NameNode、DataNode、Secondary NameNode。

1. client：就是客户端

• 文件切分。文件上传HDFS的时候，client将文件切分为一个一个的Block，然后进行存储
• 与NameNode交互，获取文件的位置信息
• 与DataNode交互，读取或写入数据
• client提供一些命令来管理和访问HDFS，比如启动或者关闭HDFS

2. NameNode：就是master（主人），是一个主管、管理者

• 管理HDFS的名称空间
• 观念里数据块（Block）映射信息
• 配置副本策略
• 处理客户端读写请求

3. DataNode：就是slave（奴隶）。NameNode下达命令，DataNode执行实际的操作

• 存储实际的数据块
• 执行数据块的读/写操作

4. Secondary（次要的）NameNode ：并不是NameNode的备用。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务

• 辅助NameNode，分担其工作量
• 定期合并fsimage和fsedits，并推送给NameNode
• 在紧急情况下，可辅助恢复NameNode

解读：

1. 第一阶段：namenode启动

2. 第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。

3. 客户端对元数据进行增删改的请求

4. namenode记录操作日志，更新滚动日志。

5. namenode在内存中对数据进行增删改查

6. 第二阶段：Secondary NameNode工作

7. Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。

8. Secondary NameNode请求执行checkpoint。

9. namenode滚动正在写的edits日志

10. 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

11. econdary NameNode加载编辑日志和镜像文件到内存，并合并。

12. 生成新的镜像文件fsimage.chkpoint

13. 拷贝fsimage.chkpoint到namenode

14. namenode将fsimage.chkpoint重新命名成fsimage

15. web端访问SecondaryNameNode

16. 启动集群

17. 浏览器中输入：http://bigdata111:50090/status.html

18. 查看SecondaryNameNode信息

19. chkpoint检查时间参数设置

20. 通常情况下，SecondaryNameNode每隔一小时执行一次。

hdfs-default.xml

2. 分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。

概念：namenode被格式化之后，将在/opt/module/hadoop-2.8.4/data/dfs/name/current目录中产生如下文件

解读：

1. Fsimage文件：

• NameNode 中关于元数据的镜像, 一般称为检查点, fsimage 存放了一份比较完整的元数据信息
• 因为 fsimage 是 NameNode 的完整的镜像, 如果每次都加载到内存生成树状拓扑结构，这是非常耗内存和CPU, 所以一般开始时对 NameNode 的操作都放在 edits 中
• fsimage 内容包含了 NameNode 管理下的所有 DataNode 文件及文件 block 及 block 所在的 DataNode 的元数据信息
• 随着 edits 内容增大, 就需要在一定时间点和 fsimage 合并

2. Edits文件：

• edits 存放了客户端最近一段时间的操作
• 客户端对 HDFS 进行写文件时会首先被记录在 edits 文件中
• edits 修改时元数据也会更新

3. seen_txid文件保存的是一个数字，就是最后一个edits_的数字
4. 每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

3.1.1 oiv查看fsimage文件

1. 查看oiv和oev命令

2. 基本语法

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

3. 案例实操

将显示的xml文件内容拷贝到IDEA中创建的xml文件中，并格式化(ctrl+L)，也可以直接cat查看文件

具体信息如下：

3.1.2oev查看edits文件

1. 基本语法

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