「2-Hadoop」：HDFS架构详述

---

一：HDFS概述

HDFS定义

1. HDFS（Hadoop Distributed File System），它是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
2. HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。

HDFS优点

1. 高容错行，数据自动保存多个副本，丢失副本自动恢复
2. 适合处理大数据，规模达到GB、TB、甚至PB级别
3. 可以构建在廉价的机器上，通过内部副本机制提供可靠性支持

HDFS缺点

1. 不适合低延时数据访问，如毫秒级
2. 无法高效的对大量小文件进行存储
   – 存储大量小文件的话，它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的，因为NameNode的内存总是有限的
3. 不支持并发写入、文件随机修改。

二：HDFS组成架构

NameNode（nn）：就是Master，它是一个主管、管理者

1. 管理HDFS的名称空间；
2. 配置副本策略；
3. 管理数据块（Block）映射信息；
4. 处理客户端读写请求；

DataNode：就是Slave。NameNode下达命令，DataNode执行实际的操作

1. 储实际的数据块；
2. 执行数据块的读/写操作；

Client：就是客户端

1. 文件切分。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行上传；
2. 与NameNode交互，获取文件的位置信息；
3. 与DataNode交互，读取或者写入数据；
4. Client提供一些命令来管理HDFS，比如NameNode格式化；
5. Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作；

Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务。

1. 辅助NameNode，分担其工作量，比如定期合并Fsimage和Edits，并推送给NameNode;
2. 在紧急情况下，可辅助恢复NameNode;

三：HDFS写、读数据流程

HDFS写数据流程

1. 客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在
2. NameNode返回是否可以上传，如上传目录不存在会报错
3. 客户端将数据按照配置分块（默认128Mb）上传，请求上传数据块block1
4. NameNode返回上传block1三副本所需的三个节点dn1，dn2，dn3
5. 客户端与dn1节点请求建立传输通道
6. dn节点逐级响应并放进响应队列进行应答是否成功
7. 将数据包装成packet进行传输

客户端将数据封装成packet放入传输队列，发送packet通常为64K, 数据包包含多个块chunk，每个块大小512 bytes ,并且有相关的校验和（checksum）;
dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答;
传输完成逐级响应传输成功；

8. 当一个数据块block1传输成功之后，开始传输第二个数据快，重复以上步骤

HDFS读数据流程

1. 客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址
2. 挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据
3. DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）
4. 客户端以Packet为单位接收，先在本地缓存，然后写入目标文件

四：NameNode和SecondaryNameNode工作机制

思考：NameNode中的元数据是存储在哪里的？

首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。
这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。
但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。

1. 启动namonode的时候，nn自动加载编辑日志和镜像文件到内存，合并生成元数据
2. client发起增删改查操作
3. nn处理客户端请求，并记录操作到编辑日志文件
4. 2nn定时进行checkpoint，有两个条件：

时间达到checkpoint值，默认一个小时
操作记录达到上限，默认一百万条，一分钟询问一次
达到以上条件之一开始进行checkpoint

5. 滚动正在写的编辑日志edit_inprogress_001生成文件edit_001，同时新的操作日志写入一个新的编辑日志文件edit_inprogress_002
6. 将编辑edit_001复制到2nn，并且加载镜像文件fsImage001到2nn
7. 2nn将镜像文件fsImage001和和编辑日志edit_001进行合并，生成fsImage.checkpoint
8. 复制fsImage.checkpoint新合成的文件到nn，并且重命名为fsImage001，此时nn的镜像文件变成了已经合并了edit_001操作记录的新文件

五：DataNode工作机制

1. 一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳
2. DataNode启动后向NameNode注册，通过后，周期性（1小时）的向NameNode上报所有的块信息
3. 心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用
4. 集群运行中可以安全加入和退出一些机器（黑名单退役/服役）