Hadoop源码分析五hdfs架构原理剖析

目录
  • 1、 hdfs架构
    • 如果在hadoop配置时写的配置文件不同,启动的服务也有所区别
      • namenode的下方是三台datanode。
      • namenode左右两边的是两个zkfc。
      • namenode的上方是三台journalnode集群。
  • 2、 namenode介绍
    • namenode作为hdfs的核心,它主要的作用是管理文件的元数据
      • 文件与块的对应关系中的块
      • namenode负责管理hdfs的元数据
      • namenode的数据持久化,采用了一种日志加快照的方式
      • 最后还会有一个程序读取这个快照文件和日志文件

1、 hdfs架构

在本系列文章三中出现了与hdfs相关的数个服务。

如果在hadoop配置时写的配置文件不同,启动的服务也有所区别

按照本系列文章二中的配置,会启动以下服务:namenodejournalnodedatanodezkfc。其关系如图:

从图中可以看出namenode是绝对的中心节点,所有的节点都会和它进行交互。图中namenode有两台,一台为active,另一台为standby。其中active是正常提供namenode服务,standby不对外提供服务,它负责及时同步active的数据,并在active故障的时候转换为active继续提供服务。

namenode的下方是三台datanode。

datanode负责存储集群中的数据,并向namenode汇报其存储数据的情况。

namenode左右两边的是两个zkfc。

它负责的是namenode的故障转移,在active的namenode故障的时候,由zkfc将standby的namenode转换为active。zkfc上方连接的是zookeeper,它对namenode的故障转移是依靠zookeeper来实现的。

namenode的上方是三台journalnode集群。

journalnode负责存储namenode的日志文件,由active的namenode向journalnode写入,standby的namenode不会向journalnode写日志,standby主要会从其中读取日志文件。

注意,这里的日志文件不是普通的运行日志,而是namenode的操作日志。例如,客户端向hdfs上传了一个文件,这时namenode会执行一系列操作来完成这次上传,而这些操作连同操作方式与操作内容一起写到操作日志中(journalnode中),通过这些操作日志可以还原这次上传操作。

2、 namenode介绍

namenode作为hdfs的核心,它主要的作用是管理文件的元数据

元数据主要包括三类:文件的命名空间、文件与块的对应关系、块的存储位置。

文件与块的对应关系中的块

是由于hdfs在存储文件的时候并不是将整个文件将存储在某一台datanode上,而是将文件按照指定的大小切割成一定数量的块。

namenode负责管理hdfs的元数据

这意味着所有与hdfs相关的操作都需要与namenode进行交互。这样namenode的速度就不能太慢,所以namenode将元数据存储在内存中。但是数据不能只存储在内存中,所以这时需要将数据持久化到硬盘中。

namenode的数据持久化,采用了一种日志加快照的方式

日志即上文提到的操作日志,快照即将内存中的数据状态直接序列化到硬盘。在安装集群的时候会先格式化namenode,这时便会创建一个快照文件,名为fsimage。然后在namenode运行的时候它会将操作日志写入到fsimage文件所在的文件夹中。这里根据配置的不同写入的路径有所不同。如果使用本系列文章二中的配置,这个日志文件还会被写到journalnode中。

最后还会有一个程序读取这个快照文件和日志文件

将数据恢复到最新的状态,然后再更新原来的快照文件。下一次再读取快照和日志文件的时候就只读最新的文件。这里的程序会根据配置的不同有所区别,按照本系列文章二中的配置来说,是standby的namenode。这里为什么不直接使用active的namenode执行更新fsimage文件,而是使用standby的namenode先读取active的日志,然后再重演一遍操作日志恢复数据再由standby的namenode更新fsimage文件。这是因为更新fsimage操作很费时间,由active的namenode执行会导致整个集群不可用。

以上就是Hadoop源码分析五hdfs架构原理剖析的详细内容,本系列下一篇文章传送门Hadoop源码分析六启动文件namenode原理详解更多关于Hadoop源码分析的资料请持续关注我们更新!

(0)

相关推荐

  • Hadoop源码分析三启动及脚本剖析

    1. 启动 hadoop的启动是通过其sbin目录下的脚本来启动的.与启动相关的叫脚本有以下几个: start-all.sh.start-dfs.sh.start-yarn.sh.hadoop-daemon.sh.yarn-daemon.sh. hadoop-daemon.sh是用来启动与hdfs相关的服务的 yarn-daemon.sh是用来启动和yarn相关的服务 start-dfs.sh是用来启动hdfs集群的 start-yarn.sh是用来启动yarn集群 start-all.sh是用

  • Hadoop源码分析四远程debug调试

    1. hadoop远程debug 从文档(3)中可以知道hadoop启动服务的时候最终都是通过java命令来启动的,其本质是一个java程序.在研究源码的时候debug是一种很重要的工具,但是hadoop是编译好了的代码,直接在liunx中运行的,无法象普通的程序一样可以直接在eclipse之类的工具中直接debug运行. 对于上述情况java提供了一种远程debug的方式. 这种方式需要在java程序启动的时候添加以下参数: -agentlib:jdwp=transport=dt_socket

  • Hadoop中namenode和secondarynamenode工作机制讲解

    1)流程 2)FSImage和Edits nodenode是HDFS的大脑,它维护着整个文件系统的目录树,以及目录树里所有的文件和目录,这些信息以俩种文件存储在文件系统:一种是命名空间镜像(也称为文件系统镜像,File System Image,FSImage),即HDFS元数据的完整快照,每次NameNode启动的时候,默认会加载最新的命名空间镜像,另一种是命令空间镜像的编辑日志(Edit log). FSImage文件其实是文件系统元数据的一个永久性检查点,但并非每一个写操作都会更新这个文件

  • Hadoop之NameNode Federation图文详解

    一. 前言 1.NameNode架构的局限性 (1)Namespace(命名空间)的限制 由于NameNode在内存中存储所有的元数据(metadata),因此单个NameNode所能存储的对象(文件+块)数目受到NameNode所在JVM的heap size的限制.50G的heap能够存储20亿(200million)个对象,这20亿个对象支持4000个DataNode,12PB的存储(假设文件平均大小为40MB).随着数据的飞速增长,存储的需求也随之增长.单个DataNode从4T增长到36

  • Hadoop源码分析六启动文件namenode原理详解

    1. namenode启动 在本系列文章三中分析了hadoop的启动文件,其中提到了namenode启动的时候调用的类为 org.apache.hadoop.hdfs.server.namenode.NameNode 其main方法的内容如下: public static void main(String argv[]) throws Exception { if (DFSUtil.parseHelpArgument(argv, NameNode.USAGE, System.out, true)

  • Hadoop源码分析五hdfs架构原理剖析

    目录 1. hdfs架构 如果在hadoop配置时写的配置文件不同,启动的服务也有所区别 namenode的下方是三台datanode. namenode左右两边的是两个zkfc. namenode的上方是三台journalnode集群. 2. namenode介绍 namenode作为hdfs的核心,它主要的作用是管理文件的元数据 文件与块的对应关系中的块 namenode负责管理hdfs的元数据 namenode的数据持久化,采用了一种日志加快照的方式 最后还会有一个程序读取这个快照文件和日

  • Hadoop源码分析二安装配置过程详解

    目录 1. 创建用户 2. 安装jdk 3. 修改hosts 4. 配置ssh免密登录 5. 安装zookeeper 解压: 修改配置文件 修改内容如下: 配置环境变量 启动 6. 安装hadoop 对于三台节点的配置安排如下: 解压: 修改配置文件: 修改core-site.xml 配置hdfs-site.xml 配置mapred-site.xml 配置yarn-site.xml 配置slaves 7. 初始化 在初始化前需要将所有机器都配置好hadoop (1) 启动zookeeper (2

  • Hadoop源码分析一架构关系简介

    1. 简介 Hadoop是一个由Apache基金会所开发的分布式系统基础架构 Hadoop起源于谷歌发布的三篇论文:GFS.MapReduce.BigTable.其中GFS是谷歌的分布式文件存储系统,MapReduce是基于这个分布式文件存储系统的一个计算框架,BigTable是一个分布式的数据库.hadoop实现了论文GFS和MapReduce中的内容,Hbase的实现了参考了论文BigTable. 2. hadoop架构 hadoop主要有三个组件 HDFS.YARN和MapReduce.其

  • jQuery源码分析-01总体架构分析

    1. 总体架构 1.1 自调用匿名函数 self-invoking anonymous function 打开jQuery源码,首先你会看到这样的代码结构: 复制代码 代码如下: (function( window, undefined ) { // jquery code })(window); 1. 这是一个自调用匿名函数.什么东东呢?在第一个括号内,创建一个匿名函数:第二个括号,立即执行 2. 为什么要创建这样一个"自调用匿名函数"呢? 通过定义一个匿名函数,创建了一个"

  • 浅谈bootstrap源码分析之scrollspy(滚动侦听)

    源码文件: Scrollspy.js 实现功能 1.当滚动区域内设置的hashkey距离顶点到有效位置时,就关联设置其导航上的指定项 2.导航必须是 .nav > li > a 结构,并且a上href或data-target要绑定hashkey 3.菜单上必须有.nav样式 4.滚动区域的data-target与导航父级Id(一定是父级)要一致 <div id="selector" class="navbar navbar-default">

  • SpringBoot静态资源配置原理(源码分析)

    前言: 我们都知道,SpringBoot启动会默认加载很多xxxAutoConfiguration类(自动配置类) 其中SpringMVC的大都数功能都集中在WebMvcAutoConfiguration类中,根据条件ConditionalOnxxx注册类对象:WebMvcAutoConfiguration满足以下ConditionalOnxxx条件,类是生效的,并把其对象注册到容器中. 那WebMvcAutoConfiguration生效给容器中配置了什么呢? WebMvcAutoConfig

  • 从java源码分析线程池(池化技术)的实现原理

    目录 线程池的起源 线程池的定义和使用 方案一:Executors(仅做了解,推荐使用方案二) 方案二:ThreadPoolExecutor 线程池的实现原理 前言: 线程池是一个非常重要的知识点,也是池化技术的一个典型应用,相信很多人都有使用线程池的经历,但是对于线程池的实现原理大家都了解吗?本篇文章我们将深入线程池源码来一探究竟. 线程池的起源 背景: 随着计算机硬件的升级换代,使我们的软件具备多线程执行任务的能力.当我们在进行多线程编程时,就需要创建线程,如果说程序并发很高的话,我们会创建

随机推荐