文档章节

hadoop1.x 与hadoop2.x 架构变化分析

Vegetable
 Vegetable
发布于 2017/07/17 15:51
字数 3497
阅读 15
收藏 0
点赞 0
评论 0

要点

Hadoop2相比较于Hadoop1.x来说,HDFS的架构与MapReduce的都有较大的变化,且速度上和可用性上都有了很大的提高,Hadoop2中有两个重要的变更:

  1. HDFS的NameNode可以以集群的方式布署,增强了NameNodes的水平扩展能力和高可用性,分别是:HDFS FederationHA
  2. MapReduce将JobTracker中的资源管理及任务生命周期管理(包括定时触发及监控),拆分成两个独立的组件,并更名为YARN(Yet Another Resource Negotiator);

一、HDFS的改进

1.1 Hadoop1.x时代的HDFS架构

  在Hadoop1.x中的NameNode只可能有一个,虽然可以通过SecondaryNameNode与NameNode进行数据同步备份,但是总会存在一定的时延,如果NameNode挂掉,但是如果有部份数据还没有同步到SecondaryNameNode上,还是可能会存在着数据丢失的问题。该架构如图1所示:

  图1 Hadoop1.x时代的HDFS结构图

  该架构包含两层:Namespace 和 Block Storage Service;
  其中,Namespace 层面包含目录、文件以及块的信息,支持对Namespace相关文件系统的操作,如增加、删除、修改以及文件和目录的展示;
  而Block Storage Service层面又包含两个部分:
  ①Block Management(块管理)维护集群中DataNode的基本关系,它支持数据块相关的操作,如:创建数据块,删除数据块等,同时,它也会管理副本的复制和存放。
  ②Physical Storage(物理存储)存储实际的数据块并提供针对数据块的读写服务。
  当前HDFS架构只允许整个集群中存在一个Namespace,而该Namespace被仅有的一个NameNode管理。这个架构使得HDFS非常容易实现,但是,它(见上图)在具体实现过程中会出现一些模糊点,进而导致了很多局限性(下面将要详细说明),当然这些局限性只有在拥有大集群的公司,像baidu,腾讯等出现。

Hadoop1.x的HDFS架构的局限:
(1)Block Storage和namespace高耦合
当前namenode中的namespace和block management的结合使得这两层架构耦合在一起,难以让其他可能namenode实现方案直接使用block storage。
(2)NameNode扩展性
HDFS的底层存储是可以水平扩展的(解释:底层存储指的是datanode,当集群存储空间不够时,可简单的添加机器已进行水平扩展),但namespace不可以。当前的namespace只能存放在单个namenode上,而namenode在内存中存储了整个分布式文件系统中的元数据信息,这限制了集群中数据块,文件和目录的数目。
(3)NameNode性能
文件操作的性能制约于单个Namenode的吞吐量,单个Namenode当前仅支持约60K的task,而下一代Apache MapReduce将支持多余100K的并发任务,这隐含着要支持多个Namenode。
(4)隔离性
现在大部分公司的集群都是共享的,每天有来自不同group的不同用户提交作业。单个namenode难以提供隔离性,即:某个用户提交的负载很大的job会减慢其他用户的job,单一的namenode难以像HBase按照应用类别将不同作业分派到不同namenode上。

1.2 Hadoop2.x的HDFS Federation  

(1)全新的Feration架构

  在Hadoop2.x中,HDFS的变化主要体现在增强了NameNode的水平扩展(Horizontal Scalability)及高可用性(HA)->【这不就是针对我们刚刚提到到的Hadoop1.x HDFS架构的局限性而做的改进,么么嗒!】,可以同时部署多个NameNode,这些NameNode之间是相互独立,也就是说他们不需要相互协调,DataNode同时在所有NameNode中注册,作为他们共有的存储节点,并定时向所有的这些NameNode发送心跳块使用情况的报告,并处理所有NameNode向其发送的指令。该架构如图2所示:

图2 Hadoop2.x时代的HDFS结构图

  该架构引入了两个新的概念:存储块池(Block Pool) 和 集群ID(ClusterID);
  ①一个Bock Pool 是块的集合,这些块属于一个单一的Namespace。DataNode存储着集群中所有Block Pool中的块。Block Pool的管理相互之间是独立的。这意味着一个Namespace可以独立的生成块ID,不需要与其他Namespace协调。一个NameNode失败不会导致Datanode的失败,这些Datanode还可以服务其他的Namenode。
  一个Namespace和它的Block Pool一起称作命名空间向量(Namespace Volume)。这是一个自包含单元。当一个NameNode/Namespace删除后,对应的Block Pool也会被删除。当集群升级时,每个Namespace Volume也会升级。
  ②集群ID(ClusterID)的加入,是用于确认集群中所有的节点,也可以在格式化其它Namenode时指定集群ID,并使其加入到某个集群中。


(2)HDFS Federation与老HDFS架构的比较

①老HDFS架构只有一个命名空间(Namespace),它使用全部的块。而HDFS Federation 中有多个独立的命名空间(Namespace),并且每一个命名空间使用一个块池(block pool)。

②老HDFS架构中只有一组块。而HDFS Federation 中有多组独立的块。块池(block pool)就是属于同一个命名空间的一组块。

③老HDFS架构由一个Namenode和一组datanode组成。而HDFS Federation 由多个Namenode和一组Datanode,每一个Datanode会为多个块池(block pool)存储块。

1.3 NameNode的HA

 在Hadoop2.0.0之前,NameNode(NN)在HDFS集群中存在单点故障(single point of failure),每一个集群中存在一个NameNode,如果NN所在的机器出现了故障,那么将导致整个集群无法利用,直到NN重启或者在另一台主机上启动NN守护线程。
  主要在两方面影响了HDFS的可用性:
  (1)、在不可预测的情况下,如果NN所在的机器崩溃了,整个集群将无法利用,直到NN被重新启动;
  (2)、在可预知的情况下,比如NN所在的机器硬件或者软件需要升级,将导致集群宕机。
  HDFS的高可用性将通过在同一个集群中运行两个NN(active NN & standby NN)来解决上面两个问题,这种方案允许在机器破溃或者机器维护快速地启用一个新的NN来恢复故障。
  在典型的HA集群(即一主一备模式)中,有两台不同的机器充当NN。在任何时间,只有一台机器处于Active状态;另一台机器是处于Standby状态。Active NN负责集群中所有客户端的操作;而Standby NN主要用于备用,它主要维持足够的状态,如果必要,可以提供快速的故障恢复。
  为了让Standby NN的状态和Active NN保持同步,即元数据保持一致,它们都将会和JournalNodes守护进程通信。当Active NN执行任何有关命名空间的修改,它需要持久化到一半以上的JournalNodes上(通过edits log持久化存储),而Standby NN负责观察edits log的变化,它能够读取从JNs中读取edits信息,并更新其内部的命名空间。一旦Active NN出现故障,Standby NN将会保证从JNs中读出了全部的Edits,然后切换成Active状态。Standby NN读取全部的edits可确保发生故障转移之前,是和Active NN拥有完全同步的命名空间状态,使用Zookeeper来进行心跳监测监控,在Active NN失效时自动切换Standby NN为Active状态。
  为了提供快速的故障恢复,Standby NN也需要保存集群中各个文件块的存储位置。为了实现这个,集群中所有的Database将配置好Active NN和Standby NN的位置,并向它们发送块文件所在的位置及心跳,如下图所示:

                       图3 Hadoop2.2.0中HDFS的高可用性实现原理图


  在任何时候,集群中只有一个NN处于Active 状态是极其重要的。否则,在两个Active NN的状态下NameSpace状态将会出现分歧,这将会导致数据的丢失及其它不正确的结果。为了保证这种情况不会发生,在任何时间,JNs只允许一个NN充当writer。在故障恢复期间,将要变成Active 状态的NN将取得writer的角色,并阻止另外一个NN继续处于Active状态,这应该也是由Zookeeper保证的。
  为了部署HA集群,你需要准备以下事项:
  (1)、NameNode machines:运行Active NN和Standby NN的机器需要相同的硬件配置;
  (2)、JournalNode machines:也就是运行JN的机器。JN守护进程相对来说比较轻量,所以这些守护进程可以可其他守护线程(比如NN,YARN ResourceManager)运行在同一台机器上。在一个集群中,最少要运行3个JN守护进程,这将使得系统有一定的容错能力。当然,你也可以运行3个以上的JN,但是为了增加系统的容错能力,你应该运行奇数个JN(3、5、7等),当运行N个JN,系统将最多容忍(N-1)/2个JN崩溃。
  在HA集群中,Standby NN也执行namespace状态的checkpoints,所以不必要运行Secondary NN、CheckpointNode和BackupNode;事实上,运行这些守护进程是错误的。

二、MapReduce的改进

2.1 Hadoop1.x时代的MapReduce

  在Hadoop1.x时代,Hadoop中的MapReduce实现是做了很多的事情,而该框架的核心Job Tracker则是既当爹又当妈的意思,如图4所示:

  图4 Hadoop1.x时代的MapReduce框架架构图

  (1)首先用户程序 (JobClient) 提交了一个 job,job 的信息会发送到 Job Tracker 中,Job Tracker 是 Map-reduce 框架的中心,他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上,需要管理所有 job 失败、重启等操作。
  (2)TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分,他做的事情主要是监视自己所在机器的资源情况。
  (3)TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat发送给JobTracker,JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。

Hadoop1.x的MapReduce框架的主要局限:
(1)JobTracker 是 Map-reduce 的集中处理点,存在单点故障;
(2)JobTracker 完成了太多的任务,造成了过多的资源消耗,当 map-reduce job 非常多的时候,会造成很大的内存开销,潜在来说,也增加了 JobTracker 失效的风险,这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限;

2.2 Hadoop2中新方案:YARN+MapReduce  首先的不要被YARN给迷惑住了,它只是负责资源调度管理。而MapReduce才是负责运算的家伙,所以YARN  != MapReduce2. 

YARN 并不是下一代MapReduce(MRv2),下一代MapReduce与第一代MapReduce(MRv1)在编程接口、数据处理引擎(MapTask和ReduceTask)是完全一样的, 可认为MRv2重用了MRv1的这些模块,不同的是资源管理和作业管理系统,MRv1中资源管理和作业管理均是由JobTracker实现的,集两个功能于一身,而在MRv2中,将这两部分分开了。 其中,作业管理由ApplicationMaster实现,而资源管理由新增系统YARN完成,由于YARN具有通用性,因此YARN也可以作为其他计算框架的资源管理系统,不仅限于MapReduce,也是其他计算框架(例如Spark)的管理平台。  

图5 Hadoop2时代的新方案架构图

  从图5中也可以看出,Hadoop1时代中MapReduce可以说是啥事都干,而Hadoop2中的MapReduce的话则是专门处理数据分析,而YARN则做为资源管理器而存在。

  该架构将JobTracker中的资源管理及任务生命周期管理(包括定时触发及监控),拆分成两个独立的服务,用于管理全部资源的ResourceManager以及管理每个应用的ApplicationMaster,ResourceManager用于管理向应用程序分配计算资源,每个ApplicationMaster用于管理应用程序、调度以及协调。一个应用程序可以是经典的MapReduce架构中的一个单独的Job任务,也可以是这些任务的一个DAG(有向无环图)任务。ResourceManager及每台机上的NodeManager服务,用于管理那台主机的用户进程,形成计算架构。每个应用程序的ApplicationMaster实际上是一个框架具体库,并负责从ResourceManager中协调资源及与NodeManager(s)协作执行并监控任务。如图6所示:

图6 YARN架构图

  (1)ResourceManager包含两个主要的组件:定时调用器(Scheduler)以及应用管理器(ApplicationManager)。

  ①定时调度器(Scheduler):

  定时调度器负责向应用程序分配资源,它不做监控以及应用程序的状态跟踪,并且它不保证会重启由于应用程序本身或硬件出错而执行失败的应用程序。
  ②应用管理器(ApplicationManager):
  应用程序管理器负责接收新任务,协调并提供在ApplicationMaster容器失败时的重启功能。
  (2)ApplicationMaster:每个应用程序的ApplicationMaster负责从Scheduler申请资源,以及跟踪这些资源的使用情况以及任务进度的监控。
  (3)NodeManager:NodeManager是ResourceManager在每台机器的上代理,负责容器的管理,并监控他们的资源使用情况(cpu,内存,磁盘及网络等),以及向 ResourceManager/Scheduler提供这些资源使用报告。
注:原文请查看:http://www.cnblogs.com/edisonchou/p/4470682.html

本文转载自:http://www.cnblogs.com/edisonchou/p/4470682.html

共有 人打赏支持
Vegetable
粉丝 15
博文 41
码字总数 45932
作品 0
杭州
Hadoop1.x和2.X的HDFS fsimage和edits文件运行机制对比

一、概述 之前写过一篇非常详细的,利用QJM在HDFS2.0部署HA策略的文章,主要说了利用QJM进行HA部署以及其原理(http://zengzhaozheng.blog.51cto.com/8219051/1441170 )。但是,其中没有详细...

zengzhaozheng ⋅ 2014/10/09 ⋅ 0

Datax与hadoop2.x兼容部署与实际项目应用工作记录分享

一、概述 Hadoop的版本更新挺快的,已经到了2.4,但是其周边工具的更新速度还是比较慢的,一些旧的周边工具版本对hadoop2.x的兼容性做得还不完善,特别是sqoop。最近,在为hadoop2.2.0找适合...

zengzhaozheng ⋅ 2014/08/15 ⋅ 0

Hadoop技术体系解读

在一个张口闭口都是大数据云计算的今天,我们有必要思考一下,在目前主流的技术体系层面它所代表的意义是什么,期望我的博文能够给后来人一些启示,少绕一些弯路。 我们还是从Hadoop生态系统...

牧师-Panda ⋅ 2016/10/16 ⋅ 0

hadoop2.x常用端口、定义方法及默认端口

以hadoop2.2为例完全分布式最新高可靠安装文档 http://www.aboutyun.com/thread-7684-1-1.html hadoop2.x常用端口、定义方法及默认端口、hadoop1.X端口对比 http://www.aboutyun.com/thread...

aibati2008 ⋅ 2016/04/13 ⋅ 0

视频jourk--hadoop2.2.0(第一个2.x的正式版本)框架介绍:笔记

hadoop2.x包括4个模块: common: hadoop的公共模块,以前叫core。包括通信模块等等。。。 HDFS: 分布式文件系统。 YARN: 任务调度和集群管理框架;是一个云操作系统/平台/框架(上面可以放很...

一枚Sir ⋅ 2014/08/08 ⋅ 0

编译hadoop2.x的hadoop-eclipse-plugin和配置

一、编译 1.安装jdk,并且配置好环境变量。 2.eclipse已经下载并且配置好了。 3.安装ant,并且配置好了环境变量。 4.hadoop包在windows本地已经有了,要和hadoop集群上的hadoop包一样,eclip...

cjun1990 ⋅ 2015/07/06 ⋅ 0

CentOS 64位系统进行Hadoop2.3.0本地编译及完全分布式集群的部署

本文是在小编的博文《 基于Hadoop1.2.1完全分布式集群的部署 》的基础上写作的,所有硬件环境跟之前博文的硬件环境一模一样,因此本文不想再这方面费过多的口舌,关于hosts配置、JDK的安装和...

灯下黑鬼吹灯 ⋅ 2016/11/28 ⋅ 0

hadoop2.x和hadoop1.x的区别

hadoop2.0解决了hadoop1.x版本的一些问题如:1.解决了namenode单点故障问题。 2.解决namenode内存压力过大难以扩展问题。 3.解决JobTracker单点故障问题。 4.解决JobTracker访问压力过大问题...

蓝狐乐队 ⋅ 2014/04/11 ⋅ 0

hadoop 1.x升级至hadoop-2.2.0记录

一、概述 公司hadoop集群从1.2.1升级到2.2.0已经有一段时间,这篇blog将总结一下我前段时间在升级至hadoop2.2.0版本过程中遇到的一些问题,以及具体的升级步骤。 二、升级过程 (1)停掉hadoo...

zengzhaozheng ⋅ 2014/06/18 ⋅ 0

[MapReduce] Hadoop1.x和Hadoop2.x的MapReduce架构区别

前言 hadoop2.x对于计算框架进行改变,这里做一个对比,方便深入的了解mapreduce的运行机制,从而为后面的计算优化做好铺垫。 架构图 架构总结 优势 Yarn 框架相对于老的 MapReduce 框架什么...

zemel ⋅ 2016/09/08 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

收集自网络的wordpress 分页导航的代码教程(全网最全版)

wordpress 分页导航是用来切换文章的一个功能,添加了 wordpress 分页导航后,用户即可自由到达指定的页面数浏览分类文章,而这样的一个很简单功能却有很多朋友在用插件:WP-PageNavi,插件的...

Rhymo-Wu ⋅ 26分钟前 ⋅ 0

微服务 WildFly Swarm 入门

Hello World 就像前面章节中的其他框架一样,我们希望添加一些基本的 Hello-world 功能,然后在其上逐步添加更多的功能。让我们从在我们的项目中创建一个 HolaResources 开始。您可以使用您的...

woshixin ⋅ 33分钟前 ⋅ 0

Maven的安装和Eclipse的配置

1. 下载Maven 下载地址 2. 解压压缩包,放到自己习惯的硬盘中 此处我将其放到了 D:\Tools 目录下。 3. 配置环境变量 右键此电脑 -> 属性 -> 高级系统设置 -> 环境变量。 在系统变量中新建,变...

影狼 ⋅ 40分钟前 ⋅ 0

python pip使用国内镜像的方法

国内源 清华:https://pypi.tuna.tsinghua.edu.cn/simple 阿里云:http://mirrors.aliyun.com/pypi/simple/ 中国科技大学 https://pypi.mirrors.ustc.edu.cn/simple/ 华中理工大学:http://......

良言 ⋅ 41分钟前 ⋅ 0

对于url变化的spa应该如何使用微信jssdk

使用vue单页面碰上微信jssdk config验证失败的坑。第一次成功 之后切换页面全部失败,找到了解决方法,第一次验证成功后保存验证信息 切换页面时验证信息直接拿来用,加一个wx.error() 失败时...

孙冠峰 ⋅ 45分钟前 ⋅ 0

Spring Cloud Gateway 一般集成

SCF发布,带来很多新东西,不过少了点教程,打开方式又和以前的不一样,比如这个SCG,压根就没有入门指导,所以这里写一个,以备后用。 一、集成 pom.xml <dependency> <groupI...

kut ⋅ 49分钟前 ⋅ 0

建造模式

《JAVA与模式》之建造模式

Cobbage ⋅ 今天 ⋅ 0

WePY框架开发的小程序如何在微信web开发者工具中运行起来

一、首先需要安装node.js,安装步骤如下: 首先下载安装包 https://nodejs.org/en/download/ 点击下载相应的zip版本 然后将文件夹解压到任意目录 比如我这里解压到了:C:\Program Files\node...

Helios51 ⋅ 今天 ⋅ 0

使用EnumSet 代替位域(32)

1、位域(Bit field):使用or 运算将几个常量合并到一个集合中 位操作,可以有效地执行 AND 、OR 这样的位操作 但是 位域比int 常量枚举缺点更多 2、java.util 包里面的EnumSet 类是有效的替...

职业搬砖20年 ⋅ 今天 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部