HDFS2.0理论笔记

HDFS2.0相对HDFS1.0有几个新特性

1 NameNode HA

在Hadoop1.0中NameNode在整个HDFS中只有一个，存在单点故障风险，一旦NameNode挂掉，整个集群无法使用，虽然有SNN，但还是不可靠；在Hadoop2.0中，就针对NameNode提供了一个高可用方案。

1.0简图

2.0简图

HDFS的高可用性将通过在同一个集群中运行两个NameNode （active NameNode & standby NameNode）来解决

• 在任何时间，只有一台机器处于Active状态；另一台机器是处于Standby状态• Active NN负责集群中所有客户端的操作；

• Standby NN主要用于备用，它主要维持足够的状态，如果必要，可以提供快速的故障恢复。

HDFS2.0完整架构图

（1）完成两个NN数据一致性

不管2.0还是1.0，底层都是datanode，2.0有两个NN，一个是Active状态，一个是Standby状态，datanode中的block一旦发生了修过，就同时通过心跳的方式通知两个NN，NN中的元数据就随即更新。

为了保证两个NN数据一致性，必须满足两个条件：

1：数据同步

       要保证数据同步，DataNode要对两个NN同时发送心跳

2：命名空间同步（namespace/文件目录树）

       （1）：借助NFS文件系统，network File system

       （2）：Hadoop自身提供了一个服务，叫做QJM

NFS：属于操作系统支持的配置---》镜像文件和编制日记文件

QJM：属于应用软件级别的配置----》JN

DataNode要对两个NN同时发送心跳，为了保证数据一致性，为什么还需要JN？

原因：两者同步的数据不同，之前说过Namenode中有两种不同类型的映射数据

JN对应的映射关系：文件名->block

NN对应的映射关系：block->DN

总结以上：

完成数据一致性要保证这两个之间数据完全一致就需要两个一致：一个是数据（通过数据管理部保证），一个是命名空间（通过JN（QJM起来的进程）来保证的），一个集群中，最少要运行3个JN系统，使得系统有一定的容错能力。

（2）命名空间保持同步

当Active NameNode的命名空间发生变化的时候，它会把这个变化通知所有JN，有的JN收到信息，有的JN是没有收到信息的，如果大部分JN进程接到信息，就认为这个事件是可信的，如果少数的JN接到信息，就认为这个信息是错误的，是屏蔽的，对于可信的信息，standby Namenode才会去同步过来，通过JN这种方式，才能保证Standby Namenode和Active Namenode之间有效信息的一个同步。

 

（3）关于NN与FailoverController与ZK

每一个NN就需要一个ZKFC，Active NN对应Active ZKFC，Standby NN对应Standby

ZKFC；

FailoverController进程（ZKFC）主要是用来协助故障转移用的，是部署在NN上的；对NN进行健康状态检查

ZK是用来用来完成故障转移的，ZK不会与NN建立直接关系，ZKFC是ZK集群的客户端，通过ZKFC用来监控NN的状态信息，ZKFC在ZK上创建节点（删除节点、临时节点、顺序节点等），与NN保持心跳

 

（4）故障转移

什么叫故障转移：就是说我这个active突然挂掉了，standby立马就把状态变成active状态，就是起到这么一个作用。

ZKFC对自己负责的NN进行健康检查，ZKFC是和NN部署在同节点上的，是时时健康检查的，ZKFC与zookeeper通过心跳检测连接，ZKFC会在ZK上注册一个临时节点（要监控，必须要临时节点），目的用于监控NN，ZK通过一些监控的命令不断的去检查NN进程，如果NN失效，相应的临时节点消失，接下来的动作类似于选主（或者申请锁）的流程。

如果当本地的namenode是健康的话，并且当前namenode也是刚好是active状况，那么ZKFC就会持有一把锁，这把锁就是一个临时节点，当本地的namenode失效了，这个节点也就失效了。

还有另外一种情况，NN是健康的，但是，不是Active状态而是Standby状态，这个时间ZKFC进程就会去帮我检查，ZZ中有没有这个临时节点，如果没有的话，就去创建一个，如果创建不了，那么说明当前集群里面有一个NN是处于active状态。

以上就是ZK通过ZKFC进程来完全了整体的一个故障迁移。

ZKFC进程，相当于对zookerper服务和NN服务进行了一定的隔离。

 

（5）为什么只能有一个Active Namenode

对于HA集群来说，同一时刻一定要确保只有一个namenode的状态active，如果有两个active的话，这两个active会互相争夺信息，会出现丢数据，会导致集群不可靠，发现错误的结果。

 

（6）关于JN

JN目的：让StandbyNN和ActiveNN保持数据同步（文件名->block）

JN通常有两种选择：一种是NFS（需要额外的磁盘空间），另外一种QJM（不需要空间）

JN通常要配置成奇数个（2n+1），如果n+1个数据是一致的，数据就确定下来，也就是说能最大允许出错的JN个数是n个。

 

（7）关于QJM

QJM：最低法定人数管理机制，原理：用2n+1台JN机器存储editlog，每次写数据操作属于大多数(>=n+1)的时候，返回成功（认为当前写成功），保证高可用

   QJM本质也是一个小集群，好处：

   1）不需要空间

   2）无单点问题

   3）不会因为个别机器延迟，影响整体性能

   4）系统配置

 

（8）为什么用QJM来实现HA？

第一：不需要配置额外的共享存储（相比NFS来说的）

第二：消除单点问题，

第三：可配置，使得系统更加鲁棒

第四：JN不会因为其中一台的延迟而影响整体的延迟，也不会因为JN的数量增多而影响------》为什么呢？

因为avtive namenode一旦里面命名空间发生数据变化，它会把这个数据同步的写到JN上，它是并行发送的状态，不管是部署少也好，多也好，它都是并行发出的

 

（9）节点分配

NN和JN通常不在一个机器上

FC和NN在同一台机器

RM（Yarn中的资源管理器，相当于1.0中Jobtracker部分功能）和NN在同一台机器

NM（Yarn中从节点）和DN在同一个机器上

通常工业界，Zookeeper是单独维护的独立集群

 

2 联邦

1.0中除了单节点故障还有一个问题，内存空间有限，因为只有一个Namenode，它保持了整个HDFS所有的元数据，创建一个文件，就必然在内存里面占用一定的空间，影响整个HDFS的扩展，所以为什么之前说HDFS不利于过多的保存小文件，因为也就是在这里。

Federation 联邦，主要是针对namenode来说的，所以也叫namenode Federation，

是有多个namenode条件下才建立起来的一个机制，有多个namenode就意味着有多套的命名空间（namespace），一个namenode负责一个命名空间，一个命名空间对应一个block pool（是同一个namespace下的所有block集合，就是一个namenode只对应自己管理的文件目录，目录里面就是文件数据，也就是block）

Federation意味着集群里面有多个block pool，上图中，底层是一个datanode存储，上层是命名空间，每一个命名空间都维护着自己的文件目录树，文件目录树下面都存在着一些文件和数据，这些数据都是由block组成的，block都是由datanode通过心跳数据同步更新过来的，那数据是怎么同步过来的呢？

首先，datanode会先把数据存到各自各自pool里，也就是缓冲区里，然后由namenode管理起来，不管是1.0也好，2.0也好，在整个集群里面，所有的文件，就是整体空间的全集，把所有pool里的信息加起来就是一个整体概念，那这个时候呢，因为要组成一个联邦，每个namenode要管理自己的空间，要把每一个pool分开，每一个namenode来维护自己的一个pool，每一个节点都是这样的，好比这个集群里面有三个namenode，每个namenode都要去维护自己的pool，维护自己的那一套缓存，而且两两之间的内部缓存信息都是不一样的，因为文件内部的逻辑概念不一样。

所以这就是联邦解决内部空间不足的一个解决方案。

 

联邦优势：

（1）命名空间可以横向扩展，使得Hadoop集群的规模可以达到上万台

减轻单一NN压力，将一部分文件转移到其他NN上管理

     如果集群中某一个目录比较大，建议用单独的NN维护起来

     命名空间精简，横向扩展，真正突破单台NN的限制

（2）性能提升

就是说当namenode持有的数据达到一个非常大规模量级时候，比如说集群里面有十亿个文件，这个时候呢，namenode处理效率可以会受到一点影响，但是呢，它可以会容易陷入到一个比较繁难的状态，而且整个集群会受限于单个namenode来处理的这个效率，从而影响整个集群的吞吐量，这个时候呢，你如果用联邦这种方式，显然可以提高性能，原来一个namenode它承载了外部所有的请求，现在不是了，现在是把这个请求给分流了，性能也会提升的

（3）资源的隔离(跟具体应用有关)

通过多个命名空间，可以将关键文件移动到不同的namenode上，那些相对不关键的数据修改，一旦发生了问题，至少不影响关键数据的破坏 就相当于每一个namenode维护的空间可以按部门去分，也可以看重要程度去分

 

每个NN共享所有的DN数据，一个命名空间对应一个块池（是同一个命名空间下的所有块集合）

联邦的本质：就是将一部分文件迁移到其他NN进行管理，让元数据管理（NN）和存储（DN）进行解耦（分开），但是真实的数据存储还是共享的。

 

3 HDFS快照

假设：一个集群，如果全部备份，可能还需要另外一个集群，操作很麻烦，成本还特高；

快照：在某一时刻给当前的文件系统照一个照片，这一照片就是当前时刻，整个集群的数据状态，主要用来做数据备份、灾备、快速恢复；

快照也是数据，也会占空间，但不是占特别大的空间（有些可以忽略不计）；

快照本质：只记录了block列表和文件大小，但不会出现数据的复制。

 

• HDFS快照是一个只读的基于时间点文件系统拷贝

• 快照可以是整个文件系统的也可以是一部分。

• 常用来作为数据备份，防止用户错误操作和容灾恢复。

• Snapshot 并不会影响HDFS 的正常操作：修改会按照时间的反序记录，这样可以直接读取到最新的数据。

• 快照数据是当前数据减去修改的部分计算出来的。

• 快照会存储在snapshottable的目录下。

 

• HDFS快照是对目录进行设定，是某个目录的某一个时刻的镜像

• 对于一个snapshottable文件夹，“.snapshot” 被用于进入他的快照 /foo 是一个

snapshottable目录，/foo/bar是一个/foo下面的文件目录，/foo有一个快照s0，那么路径就是：/foo/.snapshot/s0/bar

• hdfs dfsadmin -allowSnapshot /user/spark

• hdfs dfs -createSnapshot /user/spark s0

• hdfs dfs -renameSnapshot /user/spark s0 s_init

• hdfs dfs -deleteSnapshot /user/spark s_init

• hdfs dfsadmin -disallowSnapshot /user/spark

 

三个目录是包含的关系，A最上层，B在A中，C在B中，当B做了个快照，这时C是不能做快照的，因为B做了快照，它下面的所有子目录都包含了；这时候A也是不能做快照的，子目录做了快照，父目录也是不允许的。

 

4 HDFS缓存

HDFS1.0中也讲过类似缓存的情况，就是当客户端去读这个DN的时候，如果这个数据被频繁读取，在操作系统级别会有一个预读取，这个数据读了，会把未来的数据会提前加载到一个系统级别缓存里面去，这样会加快数据访问。

把HDFS1.0中的缓存叫做是依赖于操作系统本身的缓存机制。这种缓存机制是不能被系统管理员或者中央节点所管理的，这些缓存都是在datanode上的，由datanode自身操作系统来决定的，那对于想在namenode或者master控制整个路径缓存的话是不行的。2.0针对这种情况做了升级。

在HDFS2.0中，叫做是集中式缓存（不局限在具体的机器cpu和操作系统层面上的优化），即是由Namenode集中式管理的，可以提高对于缓存内存的可控性。

集中式缓存作用或者优点：

（1）允许用户指定要缓存的HDFS路径

自由控制缓存，提高缓存内存的可控性。

（2）明确的锁定可以阻止频繁使用的数据被从内存中清除

       对于频繁读取的数据，一旦明确了存储路径，就会告知系统，这个数据是要频繁读取的，让内存清缓存的机制不清除这些数据。

（3）集中化缓存管理对于重复访问的文件很有用

（4）可以换成目录或文件，但目录是非递归的

集中式缓存只能对文件和目录操作，目录是非递归的，只能缓存当前目录

就比如下图，对目录B做了缓存，那C是不受影响的，也没有缓存C中的数据，C还可以再做缓存

非递归这是集中式缓存的特点，但是不能说是优点

Namenode下的内容已经是在内存中的了，没必要再做缓存了

 

5 HDFS ACL

（1）Hadoop从2.4.0开始支持ACL

（2）目前HDFS的权限控制与Linux一致，包括用户、用户组、 其他用户组三类权限，这种方式有很大局限性

（3）首先参数上要开启基本权限和访问控制列表功能

– dfs.permissions.enabled

– dfs.namenode.acls.enabled

（4）常用命令：

– hadoop fs -getfacl /input/acl

– hdfs dfs -setfacl -m user:mapred:r-- /input/acl

– hdfs dfs -setfacl -x user:mapred /input/acl