Hadoop分布式文件系统——HDFS

一、HDFS架构

namenode

NameNode 负责管理整个分布式系统的元数据，主要包括：

• 目录树结构；
• 文件到数据库 Block 的映射关系；
• Block 副本及其存储位置等管理数据；
• DataNode的状态监控，两者通过段时间间隔的心跳；

这些数据保存在内存中，同时在磁盘保存两个元数据管理文件：fsimage 和 editlog。（元数据持久化为2种形式）

• fsimage：是内存命名空间元数据在外存的镜像文件；
• editlog：则是各种元数据操作的 write-ahead-log 文件，在体现到内存数据变化前首先会将操作记入 editlog 中，以防止数据丢失。

这两个文件相结合可以构造完整的内存数据。

datanode

负责数据块的实际存储和读写工作，当客户端上传一个大文件时，HDFS 会自动将其切割成固定大小的 Block，为了保证数据可用性，每个 Block 会以多备份的形式存储，默认是3份。

Secondary NameNode

定期从 NameNode 拉取 fsimage 和 editlog 文件，并对两个文件进行合并，形成新的 fsimage 文件并传回 NameNode，这样做的目的是减轻 NameNode的工作压力，本质上 SNN 是一个提供检查点功能服务的服务点。
Secondary NameNode工作机制

参考：HDFS架构

二、HDFS的高可用实现

在HDFS中，Namenode可能成为集群的单点故障，Namenode不可用时，整个文件系统是不可用的。HDFS针对单点故障提供了2种解决机制：
1）备份持久化元数据
将文件系统的元数据同时写到多个文件系统， 例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的、原子的。
2）Secondary Namenode
Secondary节点定期合并主Namenode的namespace image和edit log， 避免edit log过大，通过创建检查点checkpoint来合并。它会维护一个合并后的namespace image副本， 可用于在Namenode完全崩溃时恢复数据。

在HDFS集群中，NameNode依然是单点故障，元数据同时写到多个文件系统以及Second NameNode定期checkpoint有利于保护数据丢失，但是并不能提高可用性。 这是因为NameNode是唯一一个对文件元数据和file-block映射负责的地方， 当它挂了之后，包括MapReduce在内的作业都无法进行读写。
当NameNode故障时，常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于：

• 多文件系统写入中的备份
• Second NameNode的检查点文件

Hadoop的HA方案
采用HA的HDFS集群配置两个NameNode，分别处于Active和Standby状态。当Active NameNode故障之后，Standby接过责任继续提供服务。
1） 主备需共享edit log存储。
2）DataNode需要同时往主备发送Block Report

三、HDFS读写流程

RPC：远程过程调用，简单的理解是一个节点请求另一个节点提供的服务
参考：读写流程

四、HDFS常见面试题

参考：常见面试题

hadoop的常用配置文件

参考：hadoop的常用配置

HDFS设计原理

整个HDFS集群由Namenode和Datanode构成master-worker（主从）模式。Namenode负责构建命名空间，管理文件的元数据等，而Datanode负责实际存储数据，负责读写工作。

副本存放

• 第一个副本放在客户端相同的机器上
• 第二个副本随机放在不同于第一个副本的机架上
• 第三个副本放在跟第二个副本同一机架上

HDFS的读写详解

HDFS命令

hadoop fs 可以用于其他文件系统，不止是hdfs文件系统内
hadoop dfs 专门针对hdfs分布式文件系统
hdfs dfs 只HDFS文件系统相关，常用