Hadoop系列（二 ) HDFS原理分析史上最详细，能和面试官吹半个小时

@[TOC]

HDFS架构：

NameNode（NN）：

• 管理文件系统的namespace/元数据
• 一个HDFS集群只有一个Active的NN

说白了就是管理文件的目录

它保存了两个核心的数据结构: Fslmage和EditLog

• FsImage负责维护文件系统树和树中所有文件和文件夹的元数据。
  ———维护文件结构和文件元信息的镜像
• EditLog操作日志文件中记录了所有针对文件的创建，删除，重命名操作。
  ———记录对文件的操作

  PS:
  1.NN的元数据为了读写速度块是写在内存里的，FsImage只是它的一个镜像保存文件
  2.当每输入一个增删改操作，EditLog都会单独生成一个文件，最后EL会生成多个文件
  3.2NN不是NN的备份（但可以做备份），它的主要工作是帮助NN合并edits log，减少NN启动时间。
  4.拓扑距离：根据节点网络构成的树形结构计算最短路径
  5.机架感知：根据拓扑距离得到的节点摆放位置

SecondaryNameNode（2NN）：

• 合并NameNode的editlogs和fsimage文件
• 辅助NN将内存中元数据信息持久化

  DataNode（DN）：

• 数据存储节点，保存和检索Block
• 一个集群可以有多个数据节点

  ResourceManager（RM）：

  它是负责管理机器中的内存、cpu的那个操作系统的调度系统

• ResourceManager负责整个集群的资源管理和分配，是一个全局的资源管理系统。
• NodeManager以心跳的方式向ResourceManager汇报资源使用情况（目前主要是CPU和内存的使用情况）。RM只接受NM的资源回报信息，对于具体的资源处理则交给NM自己处理。
• YARN Scheduler根据application的请求为其分配资源，不负责application job的监控、追踪、运行状态反馈、启动等工作。

NodeManager（NM）：

• NodeManager是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN集群每个节点都运行一个NodeManager。
• NodeManager定时向ResourceManager汇报本节点资源（CPU、内存）的使用情况和Container的运行状态。当ResourceManager宕机时NodeManager自动连接RM备用节点。
• NodeManager接收并处理来自ApplicationMaster的Container启动、停止等各种请求。

HDFS具体工作原理：

---

一：NN——2NN(元数据节点工作原理)

---

第一步： 当客户端对元数据进行增删改请求时，由于hadoop安全性要求比较高，它会先将操作写入到editlog文件里，先持久化

---

第二步： 然后将具体增删改操作，将FSimage和edit写入内存里进行具体的操作，先写文件，即使宕机了也可以恢复数据，不然先内存数据就会消失，此时2NN发现时间到了，或者edit数据满了或者刚开机时，就会请求执行辅助操作，NN收到后将edit瞬间复制一份，这个时候客户端传过来的数据继续写到edit里。

---

第三步：我们把复制的edit和fsimage拷贝到2NN里，操作写在2NN的内存里合并，合并后将文件返回给NN做为新的Fsimage。所以一旦NN宕机2NN比NN差一个edit部分，无法完全恢复原先状态，只能说辅助恢复。

但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。
为了读写速度，datanode的位置信息是存在namenode的内存里的，不存硬盘，又因为会担心宕机，所以要备份一个fsimage，不断传数据，不断备份又会产生一致性问题，节点断电，数据丢失，所以采用editlog，延迟更新的方式，定期更新。但是定期更新这个操作由NN来做压力会太大，效率会变低，所以引入2NN来辅助。

通常，SecondaryNamenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存

namenode的fsimage并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建

---

NN—DN（数据存取原理）

二：HDFS读文件流程：

第一步： 首先调用FileSystem.open()方法，获取到DistributedFileSystem实例。

---

第二步： DistributedFileSystem 向Namenode发起RPC(远程过程调用)请求获得文件的开始部分或全部block列表，对于每个返回的块，都包含块所在的DataNode地址。

---

> 这些DataNode会按照Hadoop定义的集群拓扑结构得出客户端的距离，然后再进行排序。如果客户端本身就是一个DataNode，那么他将从本地读取文件。

第三步： DistributedFileSystem会向客户端client返回一个支持文件定位的输入流对象FSDataInputStream，用于客户端读取数据。

---

第四步： FSDataInputStream包含一个DFSInputStream对象，这个对象用来管理DataNode和NameNode之间的I/O

---

第五步： 客户端调用read()方法，DFSInputStream就会找出离客户端最近的datanode并连接datanode

---

第六步： DFSInputStream对象中包含文件开始部分的数据块所在的DataNode地址，首先它会连接包含文件第一个块最近DataNode。随后，在数据流中重复调用read()函数，直到这个块全部读完为止。如果第一个block块的数据读完，就会关闭指向第一个block块的datanode连接，接着读取下一个block块。

---

第七步： 如果第一批block们都读完了，DFSInputStream就会去namenode拿下一批blocks的location，然后继续读，如果所有的block块都读完，这时就会关闭掉所有的流。read 方法是并行的读取 block 信息，不是一块一块的读取。

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

---

第八步： 最终读取来所有的 block 会合并成一个完整的最终文件。

---

三：HDFS写文件流程：

---

第一步： 客户端通过调用 DistributedFileSystem 的create方法，创建一个新的文件。

---

第二步： DistributedFileSystem 通过 RPC（远程过程调用）调用 NameNode，去创建一个没有blocks关联的新文件。

---

第三步： 创建前，NameNode 会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，NameNode 就会记录下新文件，否则就会抛出IO异常。

---

第四步： NameNode 返回请求成功 的信息后，客户端将文件逻辑分块成数个部分，通过FSDataOutputStream对象，将DataNode写入数据，数据首先被写入FSDataOutputStream对象内部的buffer中，FSDOutputStream 会把数据切成一个个小packet（64k） FSDOutputStream 负责处理namenode和datanode之间的通信。客户端开始写数据FSDOutputStream,，然后排成队列 data queue。 使用管道与 切割成packet的理由 ：并行存储，增加效率。

---

第五步： 输出流 会去处理接受 data queue，它先询问 NameNode 这个新的 block 最适合存储的在哪几个DataNode里，比如重复数是3，通过计算拓扑距离，进行机架感知，完成3个datanode节点最合适存储位置寻找。把它们排成一个 pipeline。DataStreamer 把 packet 按队列输出到管道的第一个 DataNode 中，第一个 DataNode的内存buffer接收到packet将其持久化的同时又把 packet 输出到第二个 DataNode 中，以此类推。

---

第六步： DFSOutputStream 还有 一个队列叫 ack queue ，也是由 packet 组成，等待DataNode的收到响应，当pipeline中的所有DataNode都表示已经收到的时候，这时akc queue才会把对应的packet包移除掉。这组datanode组成的pipeline反方向上，发送ack成功信号，最终由pipeline中第一个datanode节点将pipelineack发送给client，并close关闭掉流，client将成功信息传给namenode，namenode将其对应元数据信息保存下来。

---

第七步： 继续读接下来的剩下来的块，namenode 再会分配三个节点的位置，以此类推，直至写完。

---

HDFS具体应用：

HDFS CLI （命令行）

基本格式：

• hdfs dfs +….
• hadoop fs (已过时)

命令：

• -ls： hdfs dfs -ls /mydemo

• -cat：hdfs dfs -ls /mydemo/niceday.txt

• -put：hdfs dfs -put /opt/soft/niceday.txt /mydemo

• mkdir：hdfs dfs -mkdir /mydemo

• -text：hdfs dfs -ls /mydemo/niceday.txt

• -get：hdfs dfs -get /mydemo/niceday.txt /opt

• rm /rm-R：hdfs dfs -rm /mydemo/niceday.txt

---

HDFS优缺点：

---

HDFS优点：

• 支持处理超大文件
• 可运行廉价机器上
• 高容错性
• 流式文件写入

---

HDFS缺点：——不合适实时

• 不适合低延时数据访问场景。
• 不适合小文件存取场景——占用NN大量内存，寻找时间超过读取时间。
• 不适合并发写入，文件随机修改场景。

---

HDFS小细节：

HDFS副本机制:

• block数据块128M的原因：

  • HDFS平均寻址时间大概为10ms

  • 大量测试发现寻址时间为传输时间的1%，为最佳状态

  • 目前磁盘传输100MB/s，计算出最佳大小：100MB/s * 1 = 100MB

    再经过cpu读取固定是2的整数次幂，所以我们将块设定为128MB

• block数据块过大： 磁盘读写时间过长，易被误判成失效节点

• block数据块过小：
  • 文件过于碎片化，namenode浪费大量内存
  • 元数据信息过多，增加寻址时间。

---

• 副本数默认为3

• 存放机制：

  • 一个在本地机架节点
  • 一个在同一个机架不同节点
  • 一个在不同机架的节点

HDFS的文件夹的作用：

• log：错误在logs上找

• share ：jar包和帮助文档所在地

• tmp/dfs/data： 里存有datanode的版本号，uuid来确认时本机的datanode

• tmp/dfs/name ： 里存有namenode的版本号，他们的集群id是一样的，还存着fsimage和edit

• tmp/dfs/name： 里存有secondnamenode的版本号，，还存着fsimage和edit

HDFS高可用：（High Availability）

• 2.x版本
  • 解决：HDFS Federation方式，共享DN资源
  • Active Namenode
    • 对外提供服务
  • Standby namenode
    • active故障时切换为active

​