HDFS的灵魂33问_hdfs namenode -format 格式化成功显示

1 HDFS是什么

• HDFS 是 Hadoop Distribute File System 的简称
• Hadoop 分布式文件系统，是 Hadoop 核心组件之一，作为最底层的分布式存储服务而存在。

2 分布式文件系统解决了什么问题

• 大数据存储的问题

• • 它们是横跨在多台计算机上的存储系统
  • 能够为存储和处理超大规模数据提供所需的扩展能力。

3 HDFS的组成与特性

• HDFS集群包括，NameNode和DataNode以及Secondary Namenode。

• • NameNode负责管理整个文件系统的元数据

  • • 以及每一个路径（文件）所对应的数据块信息。

  • DataNode 负责管理用户的文件数据块

  • • 每一个数据块都可以在多个datanode上存储多个副本。

  • Secondary NameNode用来监控HDFS状态的辅助后台程序

  • • 每隔一段时间获取HDFS元数据的快照。
    • 最主要作用是辅助namenode管理元数据信息

• HDFS的特性

• • 首先，它是一个文件系统，用于存储文件，通过统一的命名空间目录树来定位文件；

  • • 名字空间（NameSpace）

    • • HDFS 支持传统的层次型文件组织结构。
      • 用户或者应用程序可以创建目录，然后将文件保存在这些目录里。
      • 文件系统名字空间的层次结构和大多数现有的文件系统类似：
      • 用户可以创建、删除、移动或重命名文件。

  • 其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。

  • • NameNode元数据管理

    • • 我们把目录结构及文件分块位置信息叫做元数据。
      • Namenode 负责维护整个hdfs文件系统的目录树结构，以及每一个文件所对应的 block 块信息（block 的id，及所在的datanode 服务器）。

    • DataNode数据存储

    • • 文件的各个 block 的具体存储管理由 datanode 节点承担。
      • 每一个 block 都可以在多个datanode 上。
      • Datanode 需要定时向 Namenode 汇报自己持有的 block信息。
      • 存储多个副本（副本数量也可以通过参数设置 dfs.replication，默认是 3）。

  • 拥有副本机制，容错性高。

  • • 为了容错，文件的所有 block 都会有副本。
    • 每个文件的 block 大小和副本系数都是可配置的。
    • 应用程序可以指定某个文件的副本数目。
    • 副本系数可以在文件创建的时候指定，也可以在之后改变。

  • 适合一次写入，多次读出，且不支持文件的修改

  • • 因此，HDFS 适合用来做大数据分析的底层存储服务，并不适合用来做网盘等应用
    • 因为，修改不方便，延迟大，网络开销大，成本太高。

4 HDFS的master/slave架构

• HDFS 采用 master/slave 架构。
• • 一般一个 HDFS 集群是由一个 Namenode 和一定数目的Datanode 组成。
  • Namenode 是 HDFS 集群主节点
  • Datanode 是 HDFS 集群从节点
  • 两种角色各司其职，共同协调完成分布式的文件存储服务。

5 HDFS中的文件物理分库存储的默认大小与block块的默认副本机制

• 在hadoop1.x版本中，默认存储大小是64M
• 在hadoop2.x版本中，默认存储大小是128M
• hdfs的block默认副本机制是默认保存三份，可以手动设置
  • 在hdfs-site.xml当中，修改dfs.replication

6 HDFS的安全模式对我们有什么影响

• 安全模式是HDFS所处的一种特殊状态

• • 在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求。

• 处在安全模式中，文件系统只能被读取，而无法进行增删改的操作

7 如何解决HDFS的安全模式

• 一般在namenode主节点启动时，hdfs会进入安全模式

• • datanode向namenode汇报可用的block状态；
  • 当整个系统达到安全标准时，hdfs会在默认30second后自动离开安全模式。

• 或者，查看一下datanode是否没有启动成功

• • 没有启动成功的话就重新启动一下

• 直接执行命令退出安全模式：hadoop dfsadmin -safemode leave

• • 然后， 执行健康检查，删除损坏掉的block。 hdfs fsck / -delete

8 hdfs将所有的文件全部抽象成为block块来进行存储有什么好处

• 1）一个文件有可能大于集群中任意一个磁盘，抽象后可以存在多个机器上
• 2）可以简化存储的子系统
• 3）数据很适合用于数据备份，提高了数据的容错性和可用性

9 hadoop的常用命令

• （1）-help：输出这个命令参数

• • bin/hdfs dfs -help rm

• （2）-ls: 显示目录信息

• • hdfs dfs -ls /

• （3）-mkdir：在hdfs上创建目录

• • hdfs dfs -mkdir -p /aaa/bbb/cc/dd

• （4）-moveFromLocal从本地剪切粘贴到hdfs

• • ​ hdfs dfs -moveFromLocal /root/install.log /aaa/bbb/cc/dd

• （5）-moveToLocal：从hdfs剪切粘贴到本地

• • • hdfs dfs -moveToLocal /aaa/bbb/cc/dd/install.log /root
    • moveToLocal: Option ‘-moveToLocal’ is not implemented yet.

• （6）–appendToFile ：追加一个文件到已经存在的文件末尾

• • • hdfs dfs -appendToFile /root/install.log /test.txt

• （7）-cat ：显示文件内容

• • ​ hdfs dfs -cat /test.txt

• （8）-tail：显示一个文件的末尾

• • ​ hdfs dfs -tail /test.txt

• （9）-text：以字符形式打印一个文件的内容

• • ​ hdfs dfs -text /test.txt

• （10）-chgrp 、-chmod、-chown：linux文件系统中的用法一样，修改文件所属权限

• • • hdfs dfs -chmod 666 /test.txt
    • hdfs dfs -chown someuser:somegrp /test.txt

• （11）-copyFromLocal：从本地文件系统中拷贝文件到hdfs路径去

• • • hdfs dfs -copyFromLocal /export/softwares/jdk-8u141-linux-x64.tar.gz /

• （12）-copyToLocal：从hdfs拷贝到本地

• • ​ hdfs dfs -copyToLocal /jdk-8u141-linux-x64.tar.gz /export/

• （13）-cp ：从hdfs的一个路径拷贝到hdfs的另一个路径

• • ​ hdfs dfs -cp /jdk-8u141-linux-x64.tar.gz /aaa/

• （14）-mv：在hdfs目录中移动文件

• • ​ hdfs dfs -mv /aaa/jdk-8u141-linux-x64.tar.gz /aaa/bbb

• （15）-get：等同于copyToLocal，就是从hdfs下载文件到本地

• • • hdfs dfs -get /jdk-8u141-linux-x64.tar.gz /export

• （16）-getmerge ：

• • 合并下载多个文件，比如hdfs的目录 /aaa/下有多个文件:log.1, log.2,log.3,…
  • ​ hdfs dfs -put /root/install.log /aaa/1.log
  • ​ hdfs dfs -put /root/install.log /aaa/2.log
  • ​ hdfs dfs -getmerge /aaa/*.log /export/hello.txt

• （17）-put：等同于copyFromLocal

• • • hdfs dfs -put /export/jdk-8u141-linux-x64.tar.gz /user

• （18）-rm：删除文件或文件夹

• • • hdfs dfs -rm -r /user/jdk-8u141-linux-x64.tar.gz

• （19）-rmdir：删除空目录

• • ​ hdfs dfs -mkdir /empty
  • ​ hdfs dfs -rmdir /empty

• （20）-df ：统计文件系统的可用空间信息

• • • hdfs dfs -df -h /

• （21）-du统计文件夹的大小信息

• • • hdfs dfs -du -s -h /aaa

• （22）-count：统计一个指定目录下的文件节点数量

• • • hdfs dfs -count /aaa/

• （23）-setrep：设置hdfs中文件的副本数量

• • hdfs dfs -setrep 1 /jdk-8u141-linux-x64.tar.gz
• • 这里设置的副本数只是记录在namenode的元数据中，
  • 是否真的会有这么多副本，还得看datanode的数量。
  • 因为目前只有3台设备，最多也就3个副本，
  • 只有节点数的增加到10台时，副本数才能达到10。

• （24） - expunge ：清空hdfs垃圾桶

• • • hdfs dfs -expunge

10 HDFS的文件写入过程

• 1）client发起文件上传请求，通过RPC与namenode建立通讯

• • namenode检查目标文件是否存在，父目录是否存在，返回是否可以上传

• 2）client请求namenode第一个block该传输到哪些datanode服务器上

• 3）namenode根据就近原则机制、心跳活跃机制和磁盘空闲情况

• • 返回可用的可用的datanode的三个block节点地址
• • 由于hadoop为了数据的安全与高效
  • 会将数据文件在本地、同机架和不同机架的某个节点各存一分数据

• 4）client请求3台DataNode中的一台A上传数据（本质上是一个RPC调用，建立pipeline），A收到请求会继续调用B，然后B调用C，将整个pipeline建立完成，后逐级返回client；

• 5）client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存）

• • 以packet为单位（默认64K），A收到一个packet就会传给B，B传给C；
  • A每传一个packet会放入一个应答队列等待应答。

• 6）数据被分割成一个个packet数据包在pipeline上依次传输

• • 在pipeline反方向上，逐个发送ack（命令正确应答）
  • 最终由pipeline中第一个DataNode节点A将pipelineack发送给client；

• 7）当一个block传输完成之后，client再次请求NameNode上传第二个block到服务器。

11 HDFS的文件读取过程

• 1）client发起文件读取请求，通过RPC与namenode建立通讯

• • namenode检查目标文件是否存在，父目录是否存在，返回是否可以读取

• 2）NameNode会视情况返回文件的部分或者全部block列表

• • 对于每个block，namenode会返回含有该block副本的datanode地址

• 3）这些dn地址会根据就近原则和心跳机制进行排序，使用排序靠前的dn进行数据的读取

• 4）如果client本身就是datanode，那么将从本地直接获取数据(短路读取特性)；

• 5）底层上本质是建立 Socket Stream（FSDataInputStream）

• • 重复的调用父类 DataInputStream 的 read 方法，直到这个块上的数据读取完毕；

• 6）读取完一个 block 都会进行 checksum 验证

• • 如果读取 DataNode 时出现错误，客户端会通知 NameNode
  • 然后再从下一个拥有该 block 副本的DataNode 继续读。

• 7）read 方法是并行的读取 block 信息，不是一块一块的读取；

• • NameNode 只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；

• 8）最终读取来所有的 block 会合并成一个完整的最终文件。

12 HDFS的文件权限验证

• hdfs的文件权限机制与linux系统的文件权限机制类似

• r:read w:write x:execute 权限x对于文件表示忽略

• 对于文件夹表示是否有权限访问其内容

• • 如果linux系统用户zhangsan使用hadoop命令创建一个文件
  • 那么这个文件在HDFS当中的owner就是zhangsan

• HDFS文件权限的目的，防止好人做错事，而不是阻止坏人做坏事。HDFS相信你告诉我你是谁，你就是谁

13 在本地网络中，两个节点被称为“彼此近邻”是什么意思

• 在海量数据处理中，其主要限制因素是节点之间数据的传输速率——带宽很稀缺。
• 这里的想法是将两个节点间的带宽作为距离的衡量标准。
• 节点距离：两个节点到达最近的共同祖先的距离总和。

14 机架感知（副本节点选择）

• 低版本Hadoop副本节点选择

• • 第一个副本在client所处的节点上。如果客户端在集群外，随机选一个。
  • 第二个副本和第一个副本位于不相同机架的随机节点上。
  • 第三个副本和第二个副本位于相同机架，节点随机。

• Hadoop2.7.2副本节点选择

• • ​ 第一个副本在client所处的节点上。如果客户端在集群外，随机选一个。
  • ​ 第二个副本和第一个副本位于相同机架，随机节点。
  • ​ 第三个副本位于不同机架，随机节点。

15 简述NN与SNN的工作机制

• 1）第一阶段：namenode启动

• • （1）第一次启动namenode格式化后

  • • 创建fsimage（镜像文件）和edits（编辑日志）文件。
    • 如果不是第一次启动，直接加载编辑日志和镜像文件到内存。

  • （2）客户端对元数据进行增删改的请求

  • （3）namenode记录操作日志，更新滚动日志。

  • （4）namenode在内存中对数据进行增删改查

• 2）第二阶段：Secondary NameNode工作

• • （1）Secondary NameNode询问namenode是否需要checkpoint。

  • • 直接带回namenode是否检查结果。

  • （2）Secondary NameNode请求执行checkpoint。

  • （3）namenode滚动正在写的edits日志

  • （4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

  • （5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。

  • （6）生成新的镜像文件fsimage.chkpoint

  • （7）拷贝fsimage.chkpoint到namenode

  • （8）namenode将fsimage.chkpoint重新命名成fsimage

16 NN与SNN的区别与联系

• 区别：
• （1）NameNode负责管理整个文件系统的元数据以及每一个路径（文件）所对应的数据块信息。
• （2）SecondaryNameNode主要用于定期合并镜像文件和编辑日志。
• 联系：
• （1）SNN中保存了一份和namenode一致的镜像文件（fsimage）和编辑日志（edits）。
• （2）在主namenode发生故障时（假设没有及时备份数据），可以从snn恢复数据。

17 hadoop节点动态上线下线怎么操作

• 1）节点上线操作：

• 当要新上线数据节点的时候，需要把数据节点的名字追加在 dfs.hosts 文件中

• • （1）关闭新增节点的防火墙

  • （2）在 NameNode 节点的 hosts 文件中加入新增数据节点的 hostname

  • （3）在每个新增数据节点的 hosts 文件中加入 NameNode 的 hostname

  • （4）在 NameNode 节点上增加新增节点的 SSH 免密码登录的操作

  • （5）在 NameNode 节点上的 dfs.hosts 中追加上新增节点的 hostname,

  • （6）在其他节点上执行刷新操作：hdfs dfsadmin -refreshNodes

  • （7）在 NameNode 节点上，更改 slaves 文件

  • • 将要上线的数据节点 hostname 追加到 slaves 文件中

  • （8）启动 DataNode 节点

  • （9）查看 NameNode 的监控页面看是否有新增加的节点

• 2）节点下线操作：

• • （1）修改/conf/hdfs-site.xml 文件

  • （2）确定需要下线的机器，dfs.osts.exclude 文件中配置好需要下架的机器

  • • 这个是阻止下架的机器去连接 NameNode。

  • （3）配置完成之后进行配置的刷新操作./bin/hadoop dfsadmin -refreshNodes,

  • • 这个操作的作用是在后台进行 block 块的移动。

  • （4）当执行三的命令完成之后，需要下架的机器就可以关闭了

  • • 可以查看现在集群上连接的节点，正在执行 Decommissio（拆除）
    • 会显示：Decommission Status : Decommission in progress
    • 执行完毕后，会显示：
    • Decommission Status : Decommissioned

  • （5）机器下线完毕，将他们从excludes 文件中移除。

18 简述FSImage与edits

• FSImage镜像文件与edits编辑日志文件，用于保存所有数据的元数据信息

• • 客户端对hdfs进行写文件时会首先被记录在edits文件中。
  • edits修改时元数据也会更新。
  • 每次hdfs更新时edits先更新后客户端才会看到最新信息。

• fsimage：是namenode中关于元数据的镜像，一般称为检查点。

19 一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢

• 因为fsimage是namenode的完整的镜像，内容很大
• 如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。
• fsimage内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大，就需要在一定时间点和fsimage合并。

20 SNN如何辅助NN管理FSImage与Edits文件

• SNN通知NameNode切换editlog，暂时将新写操作放入一个新的文件中（edits.new)
• SNN从NameNode中获得FSImage和editlog(通过http方式)
• SNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage
• secondaryNN将新的fsimage发回给NameNode
• NameNode用新的fsimage替换旧的fsimage，把edits.new变成edits

21 fsimage与edits的合并时机取决于什么

• fsimage与edits的合并时机取决于两个参数

• • 第一个参数是：多久（默认1H）fsimage与edits合并一次。
  • 第二个参数：hdfs操作达到多少次（1000000次）会进行合并

22 如果namenode的fsimage与edits文件损坏，如何进行故障恢复

• 在我们的secondaryNamenode对namenode当中的fsimage和edits进行合并的时候，每次都会先将namenode的fsimage与edits文件拷贝一份过来。
• 所以fsimage与edits文件在secondarNamendoe当中也会保存有一份。
• 如果namenode的fsimage与edits文件损坏
• 那么我们可以将secondaryNamenode当中的fsimage与edits拷贝过去给namenode继续使用，只不过有可能会丢失一部分数据。

23 datanode的工作机制

• 1）一个数据块在datanode上以文件形式存储在磁盘上，包括两个文件

• • 一个是数据本身
  • 一个是元数据：包括数据块的长度，块数据的校验和，以及时间戳。

• 2）DataNode启动后向namenode注册

• • 通过后，周期性（1小时）的向namenode上报所有的块信息。

• 3）心跳是每3秒一次

• • 心跳返回结果带有namenode给该datanode的命令
  • 如复制块数据到另一台机器，或删除某个数据块等。
  • 如果超过10分钟没有收到某个datanode的心跳，则认为该节点不可用。

• 4）集群运行中可以安全加入和退出一些机器

24 datanode如何保证数据的完整性

• 1）当DataNode读取block的时候，它会计算checksum
• 2）如果计算后的checksum，与block创建时值不一样，说明block已经损坏。
• 3）client读取其他DataNode上的block.
• 4）datanode在其文件创建后周期验证checksum

25 namenode内存包含什么且如何分配

• NameNode整个内存结构大致可以分成四大部分：

• • Namespace

  • • 维护整个文件系统的目录树结构及目录树上的状态变化；

  • BlockManager

  • • 维护整个文件系统中与数据块相关的信息及数据块的状态变化；

  • NetworkTopology

  • • 维护机架拓扑及DataNode信息，机架感知的基础；

  • 其它

  • • LeaseManager：

    • • 读写的互斥同步就是靠Lease实现
      • 支持HDFS的Write-Once-Read-Many的核心数据结构；

    • CacheManager：

    • • Hadoop 2.3.0引入的集中式缓存新特性
      • 支持集中式缓存的管理，实现memory-locality提升读性能；

    • SnapshotManager：

    • • Hadoop 2.1.0引入的Snapshot新特性
      • 用于数据备份、回滚，以防止因用户误操作导致集群出现数据问题；

    • DelegationTokenSecretManager：管理HDFS的安全访问；

    • 另外还有临时数据信息、统计信息metrics等等。

    • NameNode常驻内存主要被Namespace和BlockManager使用，二者使用占比分别接近50%。其它部分内存开销较小且相对固定，与Namespace和BlockManager相比基本可以忽略。

26 HAnamenode 是如何工作的

• HA(High Available), 高可用，是保证业务连续性的有效解决方案

• • 一般有两个或两个以上的节点，分为活动节点（Active）及备用节点（Standby）。
  • 通常把正在执行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。

• 通过ZKFailoverController对NN进行监控

• • 1）健康监测：

  • • 周期性的向它监控的NN发送健康探测命令
    • 从而来确定某个NameNode是否处于健康状态
    • 如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态。

  • 2）会话管理：

  • • 如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话
    • 如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode
    • 当这个NN挂掉时，这个znode将会被删除，然后备用的NN将会得到这把锁，升级为主NN，同时标记状态为Active。

  • 3）当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置2个NN。

  • 4）master选举：如上所述，通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态

• 当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，ZKFailoverController会诊测到，删除掉znode，让备用节点得到这把锁，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。

27 Failover Controller是什么

• 在HA模式下，Failover Controller作为一个单独的进程，用来监视NN的健康状态和解决脑裂问题，被部署在每个nn节点上

28 HA中的QJM的优势

• 不需要配置额外的高共享存储，降低了复杂度和维护成本。
• 消除spof(单点故障)。
• 系统鲁棒性(Robust)的程度可配置、可扩展。
• 基本原理就是用2N+1台 JournalNode 存储EditLog，每次写数据操作有>=N+1返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有N台机器挂掉，如果多于N台挂掉，这个算法就失效了。这个原理是基于Paxos算法。
• 在HA架构里面SecondaryNameNode已经不存在了，为了保持standby NN时时的与Active NN的元数据保持一致，他们之间交互通过JournalNode进行操作同步。
• 任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录修改log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log，然后同步到自己的目录镜像树里面
• 当发生故障时，Active的 NN 挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。
• 在HA模式下，datanode需要确保同一时间有且只有一个NN能命令DN。
• 为此：每个NN改变状态的时候，向DN发送自己的状态和一个序列号。
• DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active。
• 如果这时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。

29 FailoverController是什么

• HA模式下，会将FailoverController部署在每个NameNode的节点上，作为一个单独的进程用来监视NN的健康状态。

• FailoverController主要包括三个组件:

• HealthMonitor:

• • 监控NameNode是否处于unavailable或unhealthy状态。
  • 当前通过RPC调用NN相应的方法完成。

• ActiveStandbyElector:

• • 监控NN在ZK中的状态。

• ZKFailoverController:

• • 订阅HealthMonitor 和ActiveStandbyElector 的事件
  • 并管理NN的状态,另外zkfc还负责解决fencing（也就是脑裂问题）。

• 上述三个组件都在跑在一个JVM中，这个JVM与NN的JVM在同一个机器上。但是两个独立的进程。一个典型的HA集群，有两个NN组成，每个NN都有自己的ZKFC进程。

30 NameNode的HA源码实现方式

• 1）HealthMonitor初始化完成后通过内部线程调用NameNode的RPC接口对其进行健康检查

• 2）如果检查到NameNode状态异常

• • 会回调ZKFailoverContorller注册的回调函数进行相应的处理

• 3）如果ZKFailoverController发现集群需要进行主备选举

• • 会使用ActiveStanbyElector和zookeeper集群通信完成主备切换

• 4）ActiveStanbyElector在完成主备切换后

• • 回调ZKFailoverController注册的方法使NameNode变成active或者stanby状态

31 HadoopFederation是什么

• 单NameNode的架构使得HDFS在集群扩展性和性能上都有潜在的问题

• 当集群大到一定程度后，NameNode进程使用的内存可能会达到上百G，NameNode成为了性能的瓶颈。

• • 因而提出了namenode水平扩展方案-- Federation。

• Federation中文意思为联邦,联盟，是NameNode的Federation,也就是会有多个NameNode。

• • 多个NameNode的情况意味着有多个namespace(命名空间)，区别于HA模式下的多NameNode，它们是拥有着同一个namespace。
  • 多个NN共用一个集群里的存储资源，每个NN都可以单独对外提供服务每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储。
  • DN会按照存储池id向其对应的NN汇报块信息
  • 同时，DN会向所有NN汇报本地存储可用资源情况。
  • 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录。

32 HDFS的Federation原理结构

• HDFS Federation意味着在集群中将会有多个namenode/namespace

• 这样的方式有什么好处呢?

• • 多namespace的方式可以直接减轻单一NameNode的压力。
  • 一个典型的例子就是上面提到的NameNode内存过高问题
  • 我们完全可以将上面部分大的文件目录移到另外一个NameNode上做管理.
  • 更重要的一点在于，这些NameNode是共享集群中所有的DataNode的，它们还是在同一个集群内的。

• HDFS Federation是解决NameNode单点问题的水平横向扩展方案。

• • 这时候在DataNode上就不仅仅存储一个Block Pool下的数据了，而是多个(大家可以在DataNode的datadir所在目录里面查看BP-xx.xx.xx.xx打头的目录)。
  • 在HDFS Federation的情况下，只有元数据的管理与存放被分隔开了，但真实数据的存储还是共用的，这与viewFs还是不一样的。

• 之前看别的文章在讲述HDFS Federation的时候直接拿viewFs来讲，个人觉得二者还是有些许的不同的，用一句话概况应该这么说。

• • HDFS的viewFs是namespace完全独立(私人化)的Federation方案
  • 可以这么说，viewFs是Federation的一个简单实现方案。

• 因为它们不仅仅是namespace独立，而且真实数据的存放也是独立的,也就是多个完全独立的集群。在这点上我们还是有必要做一下区分，否则让人以为HDFS Federation就是viewFs。

33 HDFS Federation方案的优势

• 第一点,命名空间的扩展。

• • 因为随着集群使用时间的加长，HDFS上存放的数据也将会越来越多。
  • 这个时候如果还是将所有的数据都往一个NameNode上存放,这个文件系统会显得非常的庞大。这时候我们可以进行横向扩展，把一些大的目录分离出去.使得每个NameNode下的数据看起来更加的精简。

• 第二点,性能的提升.

• • 这个也很好理解。当NameNode所持有的数据量达到了一个非常大规模的量级的时候(比如超过1亿个文件)
  • 这个时候NameNode的处理效率可能就会有影响，它可能比较容易的会陷入一个繁忙的状态。而整个集群将会受限于一个单点NameNode的处理效率,从而影响集群整体的吞吐量。这个时候多NameNode机制显然可以减轻很多这部分的压力。

• 第三点,资源的隔离。

• • 这一点考虑的就比较深了。
  • 通过多个命名空间，我们可以将关键数据文件目录移到不同的NameNode上，以此不让这些关键数据的读写操作受到其他普通文件读写操作的影响。
  • 也就是说这些NameNode将会只处理特定的关键的任务所发来的请求，而屏蔽了其他普通任务的文件读写请求，以此做到了资源的隔离。
  • 千万不要小看这一点，当你发现NameNode正在处理某个不良任务的大规模的请求操作导致响应速度极慢时，你一定会非常的懊恼。