hadoop 2.x HDFS系统架构详解

在这里插入图片描述
Hadoop 2.0的核心架构,HDFS2、YARN、MapReduce和其他。

HDFS系统架构

分布式文件系统

(1)HDFS的三个组件(三个进程)

在这里插入图片描述

NameNode:

  1. 管理文件系统命名空间(Namespace):
    维护者文件系统树及树中的所有文件和目录
  2. 存储元数据(Metadata)
    • fsimage文件存放元信息
      • 文件名、目录名和它们之间的层级关系
      • 文件目录的所有者及其权限
      • 每个文件块的名和每个文件中有哪些块
    • edits文件保存操作记录
      • 系统运行期间,datanode写操作会造成内存的变化,datanode会告诉namenode哪些文件进行的变动,namenode会根据收到的信息对所有对元信息的操作日志进行改变,改变的记录都被保存于内存中并被持久化存储于edits中。
    • edits文件和fsimage文件会被SecondaryNameNode周期性的合并
  3. 元数据保存在内存中
    NameNode元信息并不包含每个块的位置信息
  4. 保存文件、block、datanode之间的映射关系
    • 文件名—》block
      客户端直接的操作对象是文件,而一个文件可能由多个block组成。客户端向namenode发送对某一文件进行操作指令后,HDFS会根据文件名自动映射,寻找出该文件对应于哪些block。
    • block—》datanode
      block存储于datanode中的存储块。HDFS会根据block自动映射,寻找到block存储于哪台机器(datanode)中。找到后,namenode会告诉客户端,目标文件存储于哪些datanode中。
    • Namenode记录各个文件由哪些block所组成,block位于哪些datanode中。
  • 适于存储大块文件。文件越小,存储同等大小文件所需要的元数据信息机就越多,占用资源就越多。存储一大块文件,可以减少元数据信息数量。
  • 运行NameNode会占用大量内存和I/O资源,一般NameNode不会存储用户数据或执行MapReduce任务。
  • 集群中只有一个NameNode
    • 导致单点问题
      NameNode挂掉会导致元数据信息丢失
    • 两种解决方案
      • 将hadoop元数据写入到本地文件系统的同时再实现同步到一个远程挂载的网络文件系统(NFS)。
      • 运行一个SecondaryNameNode,使之于NameNode进行交互,定期的通过编辑日志文件合并命名空间镜像,当NameNode发生故障时,它会通过自己合并的命名空间镜像副本来恢复。但是,SecondaryNameNode的保存状态会滞后于NameNode,因此也是难免导致部分数据丢失。

SecondaryNameNode:

用于将内存中HDFS的元数据信息持久化存储于磁盘当中

  • NameNode的存储
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OXVU70eB-1643336032921)(捕获3.PNG)]

    • fsimage是在NameNode启动时,对整个文件系统的快照。
    • edit logs是在NameNode启动后,对文件系统的改动序列。
    • 由于fsimage和edit logs总是滞后于Namenode当前信息过多,因此引入SecondNameNode来辅助存储。
  • SecondaryNameNode的存储
    在这里插入图片描述

    • SecondaryNameNode是在文件系统中设置一个检查点来帮助NameNode更好的工作。
    • SecondaryNameNode会定时的向NameNode获取edit logs并更新到fsimage(SecondaryNameNode独有的fsimage)。更新完后,就会将新的fsimage文件拷贝给NameNode。NameNode在下次重启时会使用这个新的fsimage文件,从而减少重启时间。

DataNode:

block—》path

  1. 负责存储数据块。
  2. 为系统客户端提供数据块的读写服务,会根据NameNode的指示进行创建、删除和复制等操作。
  3. 心跳机制,定期向NameNode报告文件块列表信息,默认为3秒钟。NameNode若是在一定时间内没有收到DataNode发来的信息,则会判定为该DataNode已经失效,会将数据给其余的DataNode。
  4. DataNode之间进行通信,对数据块的副本拷贝。
  • 数据块(磁盘读写的基本单位)
    • HDFS默认数据块大小为128MB
    • 磁盘块一般为512B
    • 原因:块增大可以减少寻址时间,降低寻址时间/文件传输时间(用于确定块的大小),若寻址时间为10ms,磁盘传输速率为100MB/s,那么该比例仅为1%。
    • 数据块也不宜过大。一个MapReduce任务通常以一个块作为输入,块过大会导致整体任务数量过小,降低作业处理速度。

(2)机架感知机策略——Block副本放置策略

机房机架中放有各个服务器
在这里插入图片描述

  • 第一个副本:若客户端在集群中,则副本放置在客户端上;若如果客户端是集群外的一台机器,就随机选一个节点,将副本放在该节点上。在此期间,系统会避免挑选太满或者太忙的节点。
  • 第二个副本,放在不同机架(随机选择)的节点。
  • 第三个副本,放在与第二个副本同机架但是不同节点上。
判定datanode间远近程度

判定函数: distance(/机房/机柜/机器)

  • distance(/D1/R1/H1,/D1/R1/H1)=0 相同的datanode
  • distance(/D1/R1/H1,/D1/R1/H3)=2 同一rack下的不同datanode
  • distance(/D1/R1/H1,/D1/R2/H5)=4 同一IDC下的不同datanode
  • distance(/D1/R1/H1,/D2/R3/H9)=6 不同IDC下的datanode

(3)数据完整性校验

  • 不希望在存储和处理数据时丢失或损坏任何数据
  • HDFS 会对写入的数据计算校验和,并在读取数据时验证校验和
  • 两种检验方法:
    • 校验和
      检测损坏数据的常用方法是在第一次进行系统时计算数据的校验和,在通道传输过程中,如果新生成的校验和不完全匹配原始的校验和,那么数据就会被认为是被损坏的。
    • 数据块检测程序DataBlockScanner
      在DataNode节点上开启一个后台线程,来定期验证存储在它上所有块,这个是防止物理介质出现损减情况而 造成的数据损坏。

(4)数据容错-可靠性措施

  • 一个名字节点和多个数据节点
  • 数据复制(冗余机制)
    • 存放的位置(机架感知策略)
  • 故障检测
    • 数据节点
      • 心跳包(检测是否宕机)
      • 快报告(安全模式下检测)
      • 数据完整性检测(校验和比较)
    • 名字节点(日志文件,镜像文件)
  • 空间回收机制
    • Trash目录

(5)HDFS特点

  • 适用于
    • 存储并管理PB级数据
    • 处理非结构化数据
    • 注重数据处理的吞吐量(延迟不敏感)
    • 应用模式:write-once-read-many存取模式(无数据一致性问题)
  • 不适用于
    • 存储小文件(不建议)
    • 大量随机读(不建议)
    • 需要对文件修改(不支持)
    • 多用户写入(不支持)

Yarn(Yet Another Resource Negotiator)

Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的 Hadoop 资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

YARN为整个集群提供资源管理和调度功能,使得多种计算框架可以运行在一个集群中。
在这里插入图片描述
YARN处理操作系统层面的作用,外围为可插拔的插件,为这些应用程序提供最基本的服务,来更好的管理利用底层的设备资源。Hadoop2.0中MapReduce称为MRv2或者Yarn。Yarn中,Job的概念换成了Application。

特点:
(1)良好的扩展性、高可用。
(2)对多种类型应用进行统一管理和调度。
(3)自带多种用户调度器,适合共享集群环境。
(4)相比传统模式,提高了资源利用率、降低运维成本和数据共享成本。
在这里插入图片描述

Yarn的组件

Hadoop 1.0
JobTracker有两大功能:资源管理、作业调度和监控(各个从节点任务的运行情况要向主节点中的JobTracker汇报)。
TaskTracker负责执行任务,并定时向JobTracker汇报任务状态。

Hadoop 2.0
Yarn:将JobTracker的两大功能拆解开来。
(1)RM(ResourceManager) 负责集群资源管理。它是集群资源中唯一的仲裁者,跟踪集群中的活动节点和可用资源,类似于Hadoop1.0中MR的JobTracker。包含两个组件Scheduler(定时调用器)和ApplicationManager(应用管理器),前者负责任务调度,后者负责资源监控。

  • Scheduler(定时调度器) 是RM中有一个可插拔的调度组件Scheduler,负责运行中的各种应用分配资源。它是一个纯粹的调度器,不负责应用程序的监控和状态跟踪。它是一种调度策略,当Client提交一个任务的时候,会根据所需要的资源以及当前集群的资源资源状况进行分配。
  • ApplicationManager(应用管理器) 负责管理Client用户提交的应用,对其进行监控以及跟踪应用程序状态。

(2)AM(ApplicationMaster) 负责作业调度和监控,每个任务的管理者。AM不再在主节点上,而是分配到各个仓节点上,AM也可以管理下属从节点的运行情况,管理Container。(AM的本质其实也是一个Container)每当Client提交一个Application时候,就会创建一个ApplicationMaster。由这个ApplicationMaster去和ResourceManager申请容器资源,获取资源后会将要运行的程序发送到Container上启动执行。

Yarn:用NodeManger代替TaskTracker。
(3)NM(NodeManager) 管理当前节点的资源,是ResourceManager在每台机器上的代理,负责Container的管理,监控它们的资源使用情况(CPU、内存、磁盘、网络等),定时向ResourceManager/Scheduler提供这些资源使用报告。类似于Hadoop1.0中的TaskTracker。

Container: 是Yarn对资源做的一层抽象。就像我们平时开发过程中,经常需要对底层一些东西进行封装。只提供一个上层调用接口,Yarn对资源的管理也用到了这种思想。
Yarn将CPU核数、内存这些计算资源都封装成为一个个容器。注意连点:
(1)Container由NodeManger启动和管理,并被它所监控。
(2)Container被ResourceManager调度。

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

辰阳星宇

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值