Cloudera Hadoop(二) —— HDFS架构
HDFS 1.0的体系结构
采用主从架构模型，分为名称节点、第二名称节点、数据节点三个角色。一个典型的HDFS集群由一个名称节点、一个第二名称节点、若干个数据节点组成。
- 名称节点(NameNode)：
主要负责文件系统命名空间的管理、存储文件目录的Metadata元数据信息。 - 第二名称节点(SecondaryNameNode)：
是名称节点的冷备份，用来减少名称节点的工作量。 - 数据节点(DataNode)：
负责存储客户端发来的block数据块，执行数据块的读写操作。
NameNode
HDFS集群的命名空间是由NameNode来存储的，NameNode使用了FsImage和EditLog两个核心的数据结构。
- EditLog
是文件系统的事务日志文件，记录了每一个对文件系统元数据的改变，如在HDFS中创建了一个新文件，EditLog会插入一条记录来记录这个改变 - FsImage
整个命名空间的信息包括文件块的映射表都存放在FsImage文件中
名称节点启动时，会从磁盘读取FsImage和EditLog，将EditLog中的所有事务应用到FsImage，然后将新的FsImage刷新到本地磁盘中，然后截去就得EditLog，这个过程叫做检查点。
SecondaryNameNode
SecondaryNameNode是HDFS架构中的一个组成部分，用来保存NameNode元数据信息的备份，减少EditLog的文件大小，从而缩短NameNode重启时间。
减少EditLog的工作流程：
1. 定期和NameNo通信，请求其停止使用EditLog文件，将新的写操作写到新的edit.new文件中，此操作是瞬间完成的。
2. 将NameNode的EditLog、FsImage文件通过HTTP GET方式下载到本地对应目录
3. 将FsImage载入内存，然后一条条执行EditLog，使得内存中的FsImage是最新的。这个过程叫做FsImage、EditLog文件合并
4. 发送POST请求，将最新的FsImage文件传回给NameNode
5. NameNode接收到了最新的FsImage文件替换本地旧的FsImage文件，并将edit.new文件替换已经被执行完毕的EditLog文件，从而缩小了EditLog文件大小
从上面的工作流程可以看出，第二名称节点周期性的对名称节点的元数据进行了备份，这种设计只是一个冷备份，当名称节点故障时并不支持直接切换到第二名称节点。
FsImage、EditLog是HDFS的重要数据结构，如果这些文件损坏，就会导致整个机器失效。因此可以配置成复制多个FsImage、EditLog副本，分别存放在本地磁盘和网络文件系统NFS中。
HDFS 2.0 HA方案
以上是HDFS 1.0的架构设计，在NameNode故障时，只能停机恢复，2.0采用HA架构，解决NameNode单点故障问题。
通常由两台NameNode，一台处于active状态，一台处于standby状态，active NameNode对外提供服务，standby NameNode则不对外提供服务，仅同步active NameNod的状态，以便于在它失败是快速切换。
注意，HA中的两个NameNode属于同一工作空间。两个NameNode为了能够实时同步元数据信息（实际上是共享EditLog），会通过一组称为JournalNodes的独立进程进行相互通信。
每个Journal节点暴露一个简单的RPC接口，允许NameNode读取和写入数据，数据存放在Journal节点本地磁盘。当active NameNode写入EditLog时，它会向集群的所有Journal节点发送写请求，当大多数节点回复确认成功写入后，EditLog就认为是写入成功的。
standby NameNode负责监听，一旦发现有新数据写入，就读取这些数据，并加载到做自己内存中，以保证自己内存状态与active NameNode保持基本一致。
Hadoop使用ZooKeeper支持自动故障转移，ZooKeeper的任务包括NameNode失败检测和NameNode选举。
