分布式文件系统架构设计1. 前言...................................................... 3.2. HDFS1 (3)3. HDFS2 (5)4. HDFS3 ............................................................................................. 1 15. 结语..................................................... 1.51. 刖言Hadoop 是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。
充分利用集群的威力进行高速运算和存储。
Hadoop 实现了一个分布式文件系统(Hadoop Distributed File System )，简称HDFS，解决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce ，解决了海量数据如何计算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。
而我们今天重点给大家介绍的是Hadoop 里享誉世界的优秀的分布式文件系统-HDFS。
Hadoop 重要的比较大的版本有:Hadoop1 ,Hadoop2 , hadoop3 。
同时也相对应的有HDFS1 ，HDFS2，HDFS3三个大版本。
后面的HDFS的版本，都是对前一个版本的架构进行了调整优化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我们的系统架构能力。
2. HDFS1最早出来投入商业使用的的Hadoop 的版本，我们称为Hadoopl ，里面的HDFS就是HDFS1 ,当时刚出来HDFS1，大家都很兴奋，因为它解决了一个海量数据如何存储的问题。
HDFS1用的是主从式架构，主节点只有一个叫：Name node ，从节点有多个叫：DataNode 。
我们往HDFS上上传一个大文件，HDFS会自动把文件划分成为大小固定的数据块（HDFS1的时候，默认块的大小是64M，可以配置），然后这些数据块会分散到存储的不同的服务器上面，为了保证数据安全，HDFS1里默认每个数据块都有3个副本。
Name node 是HDFS的主节点，里面维护了文件系统的目录树，存储了文件系统的元数据信息，用户上传文件，下载文件等操作都必须跟NameNode 进行交互，因为它存储了元数据信息，Name node 为了能快速响应用户的操作，启动的时候就把元数据信息加载到了内存里面。
DataNode 是HDFS的从节点，干的活就很简单，就是存储block文件块。
01 / HDFS1 架构缺陷缺陷一：单点故障问题（高可用）我们很清楚的看到，HDFS1里面只有一个NameNode ，那么也就是说如果这个Name node 出问题以后，整个分布式文件系统就不能用了。
缺陷二：内存受限问题NameNode 为了能快速响应用户的操作，把文件系统的元数据信息加载到了内存里面，那么如果一个集群里面存储的文件较多，产生的元数据量也很大，大到name node 所在的服务器撑不下去了，那么文件系统的寿命也就到尽头了，所以从这个角度说，之前的HDFS1的架构里Name node 有内存受限的问题。
我们大体能看得出来，在HDFS1架构设计中，DataNode 是没有明显的问题的，主要的问题是在NameNode 这儿。
3. HDFS2HDFS1明显感觉架构不太成熟，所以HDFS2就是对HDFS1的问题进行解决。
01 /单点故障问题解决（高可用）大家先跟着我的思路走，现在我们要解决的是一个单点的问题，其实解决的思路很简单，因为之前是只有一个NameNode ，所以有单点故障问题，那我们把设计成两个Name node 就可以了，如果其中一个name node 有问题，就切换到另外一个NameNode 上。
NameNode所以现在我们想要实现的是：其中一个Name node 有问题，然后可以把服务切换到另外一个Name node 上。
如果是这样的话，首先需要解决一个问题：如何保证两个NameNode 之间的元数据保持一致？因为只有这样才能保证服务切换以后还能正常干活。
保证两个NameNode 之间元数据一致为了解决两个NameNode 之间元数据一致的问题，引入了第三方的一个JournalNode 集群。
IdumalnDde 集群JournO'INodo Journal NodoL -riri -!0$ 1 # ----------Ail JF MJour nalNode 集群的特点：JournalNode 守护进程是相对轻量级的，那么这些守护进程可与其它Hadoop 守护进程，如NameNode ，运行在相同的主机上。
由于元数据的改变必须写入大多数（一半以上）JNs，所以至少存在3个JournalNodes 守护进程，这样系统能够容忍单个Journal Node 故障。
当然也可以运行多于3个JournalNodes ，但为了增加系统能够容忍的故障主机的数量，应该运行奇数个JNs。
当运行N个JNs时，系统最多可以接受（N-1）/2 个主机故障并能继续正常运行，所以Jou nal Node 集群本身是没有单点故障问题的。
元数据，StandBy 状态的NameNode 实时从Journal Node 集群同步元数据，这样就保证了两个NameNode 之间的元数据是一致的。
两个NameNode 自动切换引入了Journal Node 集群以后，Active状态的NameNode 实时的往Journal Node 集群写工的参与把 Sta ndby N ameNode 切换成为 Active NameNode ，这个过程并不是自动化的,但是很明显这个过程我们需要自动化，接下来我们看 HDFS2是如何解决自动切换问题的。
为了解决自动切换问题，HDFS2弓I 入了 ZooKeeper 集群和ZKFC 进程。
ZKFC 是DFSZKFailoverController 的简称，这个服务跟 NameNode 的服务安装在同一台服务器上，主要的作用就是监控 NameNode健康状态并向 ZooKeeper 注册 NameNode ,如果Active 的NameNode挂掉后，ZKFC 为StandBy 的NameNode 竞争锁（分布式锁），获得ZKFC 锁的NameNode 变为active ，所以引入了 ZooKeeper 集群和 ZKFC 进程后就解决了 NameNode 自动切换的问题。
02 / 内存受限冋题解决目前虽然解决了单点故障的问题，但是目前假如Active NameNode 出了问题，还需要我们人• u 11 1 H 廿前面我们虽然解决了高可用的问题，但是如果NameNode 的元数据量很大，大到当前NameNode 所在的服务器存不下，这个时候集群就不可用了，换句话说就是NameNode 的扩展性有问题。
为了解决这个问题，HDFS2弓I入了联邦的机制。
Diffl带9阳顾lorn严nni燧架构之美如上图所示这个是一个完整的集群，由多个name node 构成，name nodel 和name node2构成一套name node ，我们取名叫nn 1 ,这两个name node 之间是高可用关系，管理的元数据是一模一样的；name node3 和name node4 构成一套name node ,假设我们取名叫nn2 ,这两个name node 之间也是高可用关系，管理的元数据也是一模一样的，但是nn1和nn2管理的元数据是不一样的，他们分别只是管理了整个集群元数据的一部分，引入了联邦机制以后，如果后面元数据又存不了，那继续扩nn 3, nn 4… 就可以了。
所以这个时候NameNode 就在存储元数据方面提升了可扩展性，解决了内存受限的问题。
联邦这个名字是国外翻译过来的，英文名是Federation ，之所以叫联邦的管理方式是因为Hadoop 的作者是Doug cutti ng ，在美国上学，美国是联邦制的国家，作者从国家管理的方式上联想到元数据的管理方式，其实这个跟我们国家的管理方式也有点类似，就好比我们整个国家是一个完整的集群，但是如果所有的元数据都由北京来管理的话，内存肯定不够，所以中国分了34个省级行政区域，各个区域管理自己的元数据，这行就解决了单服务器内存受限的问题。
HDFS2弓I入了联邦机制以后，我们用户的使用方式不发生改变，联邦机制对于用户是透明的，因为我们会在上游做一层映射，HDFS2的不同目录的元数据就自动映射到不同的name node 上。
03 / HDFS2的架构缺陷缺陷一：高可用只能有两个name node为了解决单点故障问题，HDFS2设计了两个name node, —个是active，另外一个是sta ndby ,但是这样的话，如果刚好两个NameNode 连续出问题了，这个时候集群照样还是不可用，所以从这这个角度讲，NameNode 的可扩展性还是有待提高的。
注意：这个时候不要跟联邦那儿混淆，联邦那儿是可以有无数个name node 的，咱们这儿说的只能支持两个name node 指的是是高可用方案。
缺陷二：副本为3，存储浪费了200%其实这个问题HDFS1的时候就存在，而且这个问题跟的设计没关系，主要是DataNode 这儿的问题，DataNode 为了保证数据安全，默认一个block都会有3个副本，这样存储就会浪费了200% 。
NameNode4. HDFS3其实到了HDFS2，HDFS就已经比较成熟稳定了，但是HDFS3还是精益求精，再从架构设计上重新设计了一下01 / 高可用之解决只能有两个name node当时在设计HDFS2的时候只是使用了两个NameNode 去解决高可用问题，那这样的话，集群里就只有一个NameNode 是Standby 状态，这个时候假设同时两个NameNode 都有问题的话，集群还是存在不可用的风险，所以在设计HDFS3的时候，使其可支持配置多个NameNode 用来支持高可用，这样的话就保证了集群的稳定性。
02 /解决存储浪费问题HDFS3之前的存储文件的方案是将一个文件切分成多个Block进行存储，通常一个Block 64MB 或者128MB，每个Block 有多个副本(replica)，每个副本作为一个整体存储在一个DataNode 上，这种方法在增加可用性的同时也增加了存储成本。