2 HDFS架构核心

2.1 HDFS简介

HDFS（Hadoop Distributed File System） 是 Apache Hadoop 项目的一个子项目，设计目的是用于存储海量（例如：TB和PB）文件数据，支持高吞吐读写文件并且高度容错。HDFS将多台普通廉价机器组成分布式集群形成分布式文件系统，提供统一的访问接口，用户可以像访问普通文件系统一样来使用HDFS访问文件。

HDFS有如下特点：

HDFS适合处理大规模数据，如：TB和PB，可以处理百万规模以上的文件数量，使用场景是一次写入、多次读取场景。
HDFS将文件线性按字节切分成多个block块进行存储，每个block块默认128M。
每个block块默认有3个副本，提高容错性，如果一个副本丢失不可用，后续可以自动恢复。
HDFS适合大文件写入，不适合大量小文件写入，因为小文件多NameNode要使用更多内存来维护存储文件目录和block信息。此外，读取大量小文件时，文件寻址时间要大于文件读取时间，违反HDFS设计目标。
HDFS不支持并发写入数据，一个文件只能有一个写，不能多个线程同时写。
HDFS数据写入后不支持修改，只支持append追加

2.2 HDFS架构

HDFS是一个主从（Master/Slaves）架构，由一个NameNode和一些DataNode组成，下图是HDFS架构：

2.2.1 NameNode

1. NameNode就是主从架构中的Master，是HDFS中的管理者。HDFS中数据文件分布式存储在各个DataNode节点上，NameNode维护和管理文件系统元数据（空间目录树结构、文件、Block信息、访问权限），随着存储文件的增多，NameNode上存储的信息越来越多，NameNode主要通过两个组件实现元数据管理：**fsimage（命名空间镜像文件）和editslog（编辑日志）**。
2. fsimage：HDFS文件系统元数据的镜像文件，其中包含了HDFS文件系统的所有目录和文件相关信息元数据。
3. edits：用户操作HDFS的编辑日志文件，存放HDFS文件系统的所有操作事件，文件的所有写操作会被记录到Edits文件中。

fsimage中存储了当前HDFS中文件属性（文件名称、路径、权限关系、副本数、修改、访问时间等），当HDFS启动后，首先会将磁盘中的fsimage加载到内存中，这样可以保证用户HDFS的高效和低延迟。需要注意，fsimage中不记录每个block所在的DataNode信息，这些信息在每次HDFS启动时从DataNode重建，之后DataNode会周期性的通过心跳向NameNode报告block信息。
在NameNode运行期间，客户端对HDFS的操作(文件或目录的创建、重命名、删除)日志都会保存在edits文件中，edits文件保存在磁盘中。当NameNode重启时，会将fsimage内容映射到内存中，然后再一条条执行edits文件中的操作就可以恢复到NameNode重启前的状态，做到不丢失数据。

总结，NameNode作用如下：

1. 完全基于内存存储文件元数据、目录结构、文件block的映射信息。
2. 提供文件元数据持久化/管理方案。
3. 提供副本放置策略。
4. 处理客户端读写请求。

2.2.2 SecondaryNameNode

随着操作HDFS的数据变多，久而久之就会造成edits文件变的很大，如果namenode重启后再一条条执行edits日志恢复状态就需要很长时间，导致重启速度慢，所以在NameNode运行的时候就需要将editslog和fsimage定期合并。这个合并操作就由SecondaryNameNode负责。

所以SecondaryNameNode作用就是辅助NameNode定期合并fsimage和editslog，并将合并后的fsimage推送给NameNode。

2.2.3 DataNode

DataNode是主从架构中的Slave,DataNode存储文件block块，Block在DataNode上以文件形式存储在磁盘上，包括2个文件，一个是数据文件本身，一个是元数据（包括block长度、block校验和、时间戳）。
当DataNode启动后会向NameNode进行注册，并汇报block列表信息，后续会周期性（参数dfs.blockreport.intervalMsec决定，默认6小时）向NameNode上报所有的块信息。
同时，DataNode会每隔3秒与NameNode保持心跳，如果超过10分钟NameNode没有收到某个DataNode的心跳，则认为该节点不可用。

总结，DataNode作用如下：
1. 基于本地磁盘存储block数据块。
2. 保存block的校验和数据保证block的可靠性。
3. 与NameNode保持心跳并汇报block列表信息。

2.2.4 Client

Client是操作HDFS的客户端，作用如下：
1. 与NameNode交互，获取文件block位置信息。
2. 与DataNode交互，读写文件block数据。
3. 文件上传时，负责文件切分成block并上传。
4. 可以通过client访问HDFS进行文件操作或管理HDFS。

2.3 fsimage和editslog合并

2.3.1 合并流程

HDFS 中NameNode管理通过fsimage和editslog来管理集群元数据，SecondaryNameNode会负责定期合并fsimage和editslog，以保证HDFS集群重启后快速恢复到之前状态。
下图是SecondaryNameNode进行fsimage和editslog合并整个流程图：

1. 当HDFS集群首次启动会在NameNode上创建空的fsimage，对HDFS的操作会记录到edits文件中。
2. 当开始进行editslog和fsimage合并时，SecondaryNameNode请求namenode生成新的editslog文件并向其中写日志。
3. SecondaryNameNode通过HTTP GET的方式从NameNode下载fsimage和edits文件到本地。
4. SecondaryNameNode将fsimage加载到自己的内存，并根据editslog更新内存中的fsimage信息，然后将更新完毕之后的fsimage写到磁盘上。
5. SecondaryNameNode通过HTTP PUT将新的fsimage文件发送到NameNode，NameNode将该文件保存为.ckpt的临时文件备用。
6. NameNode重命名该临时文件并准备使用，此时NameNode拥有一个新的fsimage文件和一个新的很小的editslog文件（可能不是空的，因为在SecondaryNameNode合并期间可能对元数据进行了读写操作）。
7. 后续SecondaryNameNode会按照以上步骤周期性进行editslog和fsimage的合并。

2.3.2 合并时机

1. 默认情况下，SecondaryNameNode每隔1小时执行edits和fsimage合并，通过参数“dfs.namenode.checkpoint.period”进行控制，默认该参数为3600s，即：1小时。
2. HDFS还会每分钟进行NameNode操作事务数量检查，如果editslog存储的事务(即操作数)到了1000000个也会进行editslog和fsimage的合并。每分钟检查操作事务参数通过dfs.namenode.checkpoint.check.period设置，默认60s，editslog操作数控制参数为dfs.namenode.checkpoint.txns，默认1000000。

2.4 安全模式

2.4.1 安全模式工作流程

当HDFS启动后，工作流程大致如下：

1. 启动NameNode，NameNode加载fsimage到内存，对内存数据执行edits log日志中的事务操作。
2. 文件系统元数据内存镜像加载完毕，进行fsimage和edits log日志的合并，并创建新的fsimage文件和一个空的edits log日志文件。
3. NameNode等待DataNode上传block列表信息，直到副本数满足最小副本条件,这个过程NameNode处于安全模式，最小副本条件指整个文件系统中有99.9%的block达到了最小副本数（默认值是1，可设置）。
4. 当满足了最小副本条件，再过30秒，NameNode就会退出安全模式。

在NameNode安全模式（safemode）下，操作HDFS有如下特点：

5. 对文件系统元数据进行只读操作。
6. 当文件的所有block信息具备的情况下，对文件进行只读操作。不允许进行文件修改（写，删除或重命名文件）。

2.4.2 注意事项

1. NameNode不会持久化block位置信息，DataNode保有各自存储的block列表信息。正常操作时，NameNode在内存中有一个blocks位置的映射信息（所有文件的所有文件块的位置映射信息）。
2. NameNode在安全模式，DataNode需要上传block列表信息到NameNode。
3. 在安全模式NameNode不会要求DataNode复制或删除block。
4. 新格式化的HDFS不进入安全模式，因为DataNode压根就没有block。

2.4.3 配置信息

2.4.4 命令操作

通过以下命令查看namenode是否处于安全模式：

hdfs dfsadmin -safemode get

HDFS的前端webUI页面也可以查看NameNode是否处于安全模式，有时候我们希望等待安全模式退出，之后进行文件的读写操作，尤其是在脚本中，此时可以执行命令：

hdfs dfsadmin -safemode wait

以上这个命令不会经常使用，更多的是集群正常启动后会自动退出安全模式。管理员有权在任何时间让namenode进入或退出安全模式，进入安全模式命令如下：

hdfs dfsadmin -safemode enter

以上命令可以让namenode一直处于安全模式，离开安全模式命令如下：

hdfs dfsadmin -safemode leave

2.5 Block及副本存放策略

2.5.1 Block块

2.5.2 Block副本放置策略

HDFS中每个block块有3副本，由参数dfs.replication决定。三个副本会按照副本放置策略进行存储，如下图所示就是一个block有3副本存储情况。

第一个副本：放置在上传文件的DataNode，也就是Client所在节点上；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
第二个副本：放置在于第一个副本不同的机架的节点上。
第三个副本：与第二个副本相同机架的随机节点。
更多副本：随机节点存放。

2.6 读写流程

2.6.1 HDFS写文件流程

a. 关闭管线，把确认队列中的所有包都添加回数据队列的最前端，以保证故障节点下游的datanode不会漏 掉任何一个数据包。
b. 为存储在另一正常datanode的当前数据块指定一个新的标志，并将该标志传送给namenode，以便故障datanode在恢复后可以删除存储的部分数据块。
c. 从管线中删除故障数据节点并且把余下的数据块写入管线中另外两个正常的datanode。namenode在检测到副本数量不足时，会在另一个节点上创建新的副本。
d. 后续的数据块继续正常接受处理。
e. 在一个块被写入期间可能会有多个datanode同时发生故障，但非常少见。只要设置了dfs.replication.min的副本数（默认为1），写操作就会成功，并且这个块可以在集群中异步复制，直到达到其目标副本数（dfs.replication默认值为3）。

2.6.2 HDFS读文件流程