您的位置: 首页  >  文章  >  0094 HDFS架构、读写过程详解、运维

0094 HDFS架构、读写过程详解、运维

分类: 文章 • 2025-01-27 22:31:58

HDFS的架构？

0094 HDFS架构、读写过程详解、运维

HDFS采用Master-Slave 架构，分为4部分：

  • HDFS Client：HDFS客户端，通过与 NameNode和DataNode 交互访问HDFS中的文件
  • NameNode：NameNode是一个中心服务器，负责管理文件系统的名字空间 (Namespace )及客户端对文件的访问
  • DataNode：管理它所在节点上的存储，一般一个节点运行一个DataNode
  • Secondary DataNode：
    官网架构图：
    0094 HDFS架构、读写过程详解、运维

名称空间？

维护文件系统树、文件树中文件、文件夹元数据

管理这些信息的文件有两个，分别是Namespace 镜像文件(fsimage)和操作日志文件(edit log)，这些信息被Cache在RAM中，当然，这两个文件也会被持久化存储在本地硬盘

元数据？

描述数据的数据，又称为中继数据、中介数据。如NameNode中的元数据信息：

“文件名 -> 数据块‘’映射

“数据块 -> DataNode列表”映射

文件Block管理？

NameNode记录着文件中每个块所在数据节点中的位置（元数据信息）。从NameNode中你可以获取每个文件的每个块所在的DataNode，但是NamdNode并不持久化这些信息，因为【NameNode会在每次启动系统时动态地重建这些信息】

DataNode？

DataNode负责存储数据，一个【数据块】（Block）会在多个DataNode中进行冗余备份；定时通过heartbeat（心跳检测）向NameNode发送所存储的文件块信息。

DataNode上数据简单理解：存储数据Block ID和Block，以及他们的对应关系

Secondary NameNode？

定时对NameNode的数据snapshot进行备份，这样可尽量降低NameNode崩溃之后数据丢失风险；

具体为，将NameNode中镜像文件（fsimage)和操作日志（edit log）合并再发送给NamedNode，这样既可完成【减轻NameNode的负担又能安全地备份，一旦HDFS的Master架构失效，就可以借助Secondary NameNode进行数据恢复】

由于辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。通常，Secondary Namenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。

NameNode的目录结构？

${dfs.name.dir}/current/VERSION
/edits
/fsimage
/fstime

Secondary NameNode的目录结构？

${fs.checkpoint.dir}/current/VERSION
/edits
/fsimage
/fstime
/previous.checkpoint/VERSION
/edits
/fsimage
/fstime

Secondary NameNode和NameNode合并？

0094 HDFS架构、读写过程详解、运维

fsimage）文件是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage写非常慢（这个有比较像datafile）。

由于Edit log不断增长，在NameNode重启时，会造成长时间NameNode处于安全模式，不可用状态，是非常不符合Hadoop的设计初衷。所以要周期性合并Edit log，但是这个工作由NameNode来完成，会占用大量资源，这样就出现了Secondary NameNode，它可以进行image检查点的处理工作。步骤如下：
（1） Secondary NameNode请求NameNode进行edit log的滚动（即创建一个新的edit log），将新的编辑操作记录到新生成的edit log文件；
（2） 通过http get方式，读取NameNode上的fsimage和edits文件，到Secondary NameNode上；
（3） 读取fsimage到内存中，即加载fsimage到内存，然后执行edits中所有操作（类似OracleDG，应用redo log），并生成一个新的fsimage文件，即这个检查点被创建；
（4） 通过http post方式，将新的fsimage文件传送到NameNode；
（5） NameNode使用新的fsimage替换原来的fsimage文件，让（1）创建的edits替代原来的edits文件；并且更新fsimage文件的检查点时间。
整个处理过程完成。
Secondary NameNode的处理，是将fsimage和edites文件周期的合并，不会造成nameNode重启时造成长时间不可访问的情况。

参考

HDFS的底层通信原理？

RPC和动态代理对象Proxy

NN与Secondary NN的写过程交互？

0094 HDFS架构、读写过程详解、运维

1)写入数据时，先向NN询问是否可以写入（已存在等情况），NN将元数据写入EditLog文件中

  1. NN通知客户端可写入，客户端写入结束后，通知NN写入完毕，NN将editLog的元数据写入内存

3)当Edit Log写满时，进行FSImage与Edit Log合并，在secondary namenode上进行。并通知NN停止写入Edit Log,此时会创建一个新的Edit Log.new,当合并结束后，将合并后的文件上传到NN，并删除之前的Edit Log,将Edit Lod.new改名为EditLog

注意：在写入时，只要写入了一个块就算写入成功，第二个块由第一个块去写，依次类推，若副本写入失败，通知NN，重新再指定位置写入副本。

数据节点数据存哪儿？

HDFS文件是以Linux系统上的普通文件进行存储，在DataNode节点上。

HDFS的写流程？

0094 HDFS架构、读写过程详解、运维

  1. 客户端向 NameNode（NN)请求 写 数据，NN检查目标文件是否已经存在、父目录是否存在；
  2. NN返回是否可以写数据，若可以则继续执行；
  3. 客户端请求上传的block写到哪个DataNode（DN)服务器上；
  4. NN返回3个DN，分别为dn1、dn2、dn3；
  5. 客户端请求在dn1上写数据，dn1收到请求后，调用dn2，，然后dn2调用dn3，建立通信管道（pipeline）；
  6. dn1、dn2、dn3 逐级应答客户端（ack）；
  7. 客户端将block上传到dn1，以packet为单位，dn1收到packet存储完后传给dn2，并在应答队列中放入一个应答，dn2依次再传给dn3。当dn3存储完，应答dn2，dn2再应答dn1，dn1将应答队列中的应答删除，标志着一次packet数据同步成功；
  8. 当一个block传完，客户端再次请求NN上传第二个block的服务器（重复3~8）；

HDFS读数据过程？

  1. 客户端向NN请求读数据，NN通过查元数据（记录数据位置的数据），找到文件快所在DN地址；
  2. 挑选一台DN（就近原则，然后随机）服务器，请求数据读取；
  3. DN开始向客户端传数据，数据从磁盘读到数据流，以packet为单位验证；
  4. 客户端以packet为单位接受，先在本地缓存，然后写入目标文件。

Hadoop节点动态新增节点？

Created with Raphaël 2.2.0开始关闭新增节点的防火墙在 NameNode 节点的 hosts 文件中加入新增数据节点的 hostname在每个新增数据节点的 hosts 文件中加入 NameNode 的 hostname在 NameNode 节点上增加新增节点的 SSH 免密码登录的操作在 NameNode 节点上的 dfs.hosts 中追加上新增节点的 hostname在其他节点上执行刷新操作：hdfs dfsadmin -refreshNodes在 NameNode 节点上，更改 slaves 文件，将要上线的数据节点 hostname 追加slave节点上启动 DataNode 节点查看 NameNode 的监控页面看是否有新增加的节点动态新增节点结束

HDFS节点线下？

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

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

止下架的机器去连接 NameNode。

（3）配置完成之后进行配置的刷新操作./bin/hadoop dfsadmin -refreshNodes,这个操作的作用是在后台进行 block 块的移动。

（4）当执行三的命令完成之后，需要下架的机器就可以关闭了，可以查看现在集群上连接的节点，正在执行 Decommission，会显示：Decommission Status : Decommission in progress 执行完毕后，会显示：Decommission Status :Decommissioned

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

hadoop的块大小，从哪个版本开始是128M

Hadoop1.x都是64M，hadoop2.x开始都是128M。

Linux中的块大小为4KB, 为什么HDFS中块大小为64MB或128MB?

如果采用4kb的块大小来存放存储在Hadoop中的数据, 就会需要大量的块, 大大增加了寻找块的时间, 降低了读写效率.
并且, 一个map或者一个reduce都是以一个块为单位处理, 如果块很小, mapreduce任务数就会很多, 任务之间的切换开销变大, 效率降低。

并发写入HDFS文件可行吗?

不行, 因为客户端通过namenode接收到在数据块上写入的许可后, 那个块会锁定直到写入操作完成, 所以不能在同一个块上写入.

HDFS 中的 block 默认保存几份?

3

JobTracker和TaskTracker区别？

  • hadoop的集群是基于master/slave模式，namenode和jobtracker属于master，datanode和tasktracker属于slave，master只有一个，而slave有多个。
  • SecondaryNameNode内存需求和NameNode在一个数量级上，所以通常secondary NameNode（运行在单独的物理机器上）和 NameNode 运行在不同的机器上。

JobTracker对应于NameNode,TaskTracker对应于DataNode。

  • DataNode和NameNode是针对数据存放来而言的。JobTracker和TaskTracker是对于MapReduce执行而言的。

  • mapreduce中几个主要概念，mapreduce 整体上可以分为这么几条执行线索：jobclient，JobTracker与TaskTracker。

  • JobClient会在用户端通过JobClient类将已经配置参数打包成jar文件的应用存储到hdfs，并把路径提交到Jobtracker,然后由JobTracker创建每一个Task（即 MapTask 和 ReduceTask）并将它们分发到各个TaskTracker服务中去执行。

  • JobTracker是一master服务，软件启动之后JobTracker接收Job，负责调度Job的每一个子任务。task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它。一般情况应该把JobTracker 部署在单独的机器上。

  • TaskTracker是运行在多个节点上的slaver服务。TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务。TaskTracker 都需要运行在HDFS的DataNode上。

参考

相关推荐