大数据 hadoop-HDFS

标题## 1 Hadoop 系统架构

1.1 Hadoop1.x和Hadoop2.x 架构
在介绍HA之前，我们先来看下Hadoop的系统架构，这对于理解HA是至关重要的，Hadoop 1.x之前，其官方架构如图1所示:

[ 图1.Hadoop 1.x架构图 ]
从图中可看出，1.x版本之前只有一个Namenode,所有元数据由惟一的Namenode负责管理,可想而之当这个NameNode挂掉时整个集群基本也就不可用。
Hadoop 2.x的架构与1.x有什么区别呢。我们来看下2.x的架构：

[ 图2.Hadoop 2.x架构图 ]
2.x版本中，HDFS架构解决了单点故障问题，即引入双NameNode架构，同时借助共享存储系统来进行元数据的同步，共享存储系统类型一般有几类，如：Shared NAS+NFS、BookKeeper、BackupNode 和 Quorum Journal Manager(QJM)，上图中用的是QJM作为共享存储组件，通过搭建奇数结点的JournalNode实现主备NameNode元数据操作信息同步。
Hadoop的元数据包括哪些信息呢，下面介绍下关于元数据方面的知识。

1.2 Hadoop 2.x元数据

Hadoop的元数据主要作用是维护HDFS文件系统中文件和目录相关信息

1. 元数据的存储形式主要有3类：内存镜像、磁盘镜像(FSImage)、日志(EditLog)。
   (1)在Namenode启动时，会加载磁盘镜像到内存中以进行元数据的管理，存储在NameNode内存；

   (2)磁盘镜像是某一时刻HDFS的元数据信息的快照，包含所有相关Datanode节点文件块映射关系和命名空间(Namespace)信息，存储在NameNode本地文件系统；

   (3)日志文件记录client发起的每一次操作信息，即保存所有对文件系统的修改操作，用于定期和磁盘镜像合并成最新镜像，保证NameNode元数据信息的完整，存储在NameNode本地和共享存储系统(QJM)中。

   (4)如下所示为NameNode本地的EditLog和FSImage文件格式，EditLog文件有两种状态：
   inprocess和finalized,
   inprocess表示正在写的日志文件，文件名形式:editsinprocess[start-txid]

   (5)finalized表示已经写完的日志文件,文件名形式：edits[start-txid][end-txid]；
   FSImage文件也有两种状态, finalized和checkpoint， finalized表示已经持久化磁盘的文件，文件名形式:
   fsimage_[end-txid], checkpoint表示合并中的fsimage

   (6) 2.x版本checkpoint过程在Standby
   Namenode(SNN)上进行，SNN会定期将本地FSImage和从QJM上拉回的ANN的EditLog进行合并，合并完后再通过RPC传回ANN。

data/hbase/runtime/namespace
├── current
│ ├── VERSION
│ ├── edits_0000000003619794209-0000000003619813881
│ ├── edits_0000000003619813882-0000000003619831665
│ ├── edits_0000000003619831666-0000000003619852153
│ ├── edits_0000000003619852154-0000000003619871027
│ ├── edits_0000000003619871028-0000000003619880765
│ ├── edits_0000000003619880766-0000000003620060869
│ ├── edits_inprogress_0000000003620060870
│ ├── fsimage_0000000003618370058
│ ├── fsimage_0000000003618370058.md5
│ ├── fsimage_0000000003620060869
│ ├── fsimage_0000000003620060869.md5
│ └── seen_txid
└── in_use.lock

1. (7)上面所示的还有一个很重要的文件就是seen_txid,保存的是一个事务ID，这个事务ID是EditLog最新的一个结束事务id，当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件，进行元数据恢复，如果该文件丢失或记录的事务ID有问题，会造成数据块信息的丢失。

(8)HA其本质上就是要保证主备NN元数据是保持一致的，即保证fsimage和editlog在备NN上也是完整的。元数据的同步很大程度取决于EditLog的同步，而这步骤的关键就是共享文件系统，下面开始介绍一下关于QJM共享存储机制。

2 Hadoop的HA机制

前言：正式引入HA机制是从hadoop2.0开始，之前的版本中没有HA机制
1.1 HA的运作机制

1. （1）hadoop-HA集群运作机制介绍
   所谓HA，即高可用（7*24小时不中断服务）,实现高可用最关键的是消除单点故障
   hadoop-ha严格来说应该分成各个组件的HA机制——HDFS的HA、YARN的HA

（2）HDFS的HA机制详解
通过双namenode消除单点故障,双namenode协调工作的要点：
A、元数据管理方式需要改变：

(1)内存中各自保存一份元数据

(2)Edits日志只能有一份，只有Active状态的namenode节点可以做写操作

(3)两个namenode都可以读取edits

(4)共享的edits放在一个共享存储中管理（QJM流实现）

B、需要一个状态管理功能模块

(1)实现了一个zkfailover，常驻在每一个namenode所在的节点

(2)每一个zkfailover负责监控自己所在namenode节点，利用zk进行状态标识

(3)当需要进行状态切换时，由zkfailover来负责切换

1.2 HDFS-HA图解：