热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

Hadoop2.x与1.x架构对比说明

hadoop2,x,与,1,

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.1 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.2 NameNode的HA

Hadoop中的NameNode好比是人的心脏,非常重要,绝对不可以停止工作。在Hadoop1.x时代,只有一个NameNode。如果 该NameNode数据丢失或者不能工作,那么整个集群就不能恢复了。这是Hadoop1.x中的单点问题,也是Hadoop1.x不可靠的表现,如图1 所示。Hadoop2的出现解决了这个问题,也被称为HA。

Hadoop2中HDFS的HA主要指的是可以同时启动2个NameNode。 其中一个处于工作(Active)状态,另一个处于随时待命(Standby)状态。这样,当一个NameNode所在的服务器宕机时,可以在数据不丢失 的情况下,手工或者自动切换到另一个NameNode提供服务。如图3所示,它展示了一个在Hadoop2下实现HA的一种方式结构:

图3 Hadoop2.x时代实现HA的一种架构图

下面对上图做一下简单的介绍:

(1)这些NameNode之间通过共享存储同步edits信息,保证数据的状态一致。多个NameNode之间共享数据,可以通过 Network File System(NFS)或者Quorum Journal Node。前者是通过Linux共享的文件系统,属于操作系统层面的配置;后者是Hadoop自身的东西,属于软件层面的配置。

(2)DataNode同时向两个NameNode汇报块信息。这是让Standby NameNode保持集群最新状态的必需步骤。

(3)使用Zookeeper来进行心跳监测监控,在Active NameNode失效时自动切换Standby NameNode为Active状态。

二、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


推荐阅读
  • 作为140字符的开创者,Twitter看似简单却异常复杂。其简洁之处在于仅用140个字符就能实现信息的高效传播,甚至在多次全球性事件中超越传统媒体的速度。然而,为了支持2亿用户的高效使用,其背后的技术架构和系统设计则极为复杂,涉及高并发处理、数据存储和实时传输等多个技术挑战。 ... [详细]
  • 单片微机原理P3:80C51外部拓展系统
      外部拓展其实是个相对来说很好玩的章节,可以真正开始用单片机写程序了,比较重要的是外部存储器拓展,81C55拓展,矩阵键盘,动态显示,DAC和ADC。0.IO接口电路概念与存 ... [详细]
  • 本文是Java并发编程系列的开篇之作,将详细解析Java 1.5及以上版本中提供的并发工具。文章假设读者已经具备同步和易失性关键字的基本知识,重点介绍信号量机制的内部工作原理及其在实际开发中的应用。 ... [详细]
  • Web开发框架概览:Java与JavaScript技术及框架综述
    Web开发涉及服务器端和客户端的协同工作。在服务器端,Java是一种优秀的编程语言,适用于构建各种功能模块,如通过Servlet实现特定服务。客户端则主要依赖HTML进行内容展示,同时借助JavaScript增强交互性和动态效果。此外,现代Web开发还广泛使用各种框架和库,如Spring Boot、React和Vue.js,以提高开发效率和应用性能。 ... [详细]
  • Cosmos生态系统为何迅速崛起,波卡作为跨链巨头应如何应对挑战?
    Cosmos生态系统为何迅速崛起,波卡作为跨链巨头应如何应对挑战? ... [详细]
  • Kafka 是由 Apache 软件基金会开发的高性能分布式消息系统,支持高吞吐量的发布和订阅功能,主要使用 Scala 和 Java 编写。本文将深入解析 Kafka 的安装与配置过程,为程序员提供详尽的操作指南,涵盖从环境准备到集群搭建的每一个关键步骤。 ... [详细]
  • 第二章:Kafka基础入门与核心概念解析
    本章节主要介绍了Kafka的基本概念及其核心特性。Kafka是一种分布式消息发布和订阅系统,以其卓越的性能和高吞吐量而著称。最初,Kafka被设计用于LinkedIn的活动流和运营数据处理,旨在高效地管理和传输大规模的数据流。这些数据主要包括用户活动记录、系统日志和其他实时信息。通过深入解析Kafka的设计原理和应用场景,读者将能够更好地理解其在现代大数据架构中的重要地位。 ... [详细]
  • Python 实战:异步爬虫(协程技术)与分布式爬虫(多进程应用)深入解析
    本文将深入探讨 Python 异步爬虫和分布式爬虫的技术细节,重点介绍协程技术和多进程应用在爬虫开发中的实际应用。通过对比多进程和协程的工作原理,帮助读者理解两者在性能和资源利用上的差异,从而在实际项目中做出更合适的选择。文章还将结合具体案例,展示如何高效地实现异步和分布式爬虫,以提升数据抓取的效率和稳定性。 ... [详细]
  • Zookeeper作为Apache Hadoop生态系统中的一个重要组件,主要致力于解决分布式应用中的常见数据管理难题。它提供了统一的命名服务、状态同步服务以及集群管理功能,有效提升了分布式系统的可靠性和可维护性。此外,Zookeeper还支持配置管理和临时节点管理,进一步增强了其在复杂分布式环境中的应用价值。 ... [详细]
  • 揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节
    揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节 ... [详细]
  • HBase在金融大数据迁移中的应用与挑战
    随着最后一台设备的下线,标志着超过10PB的HBase数据迁移项目顺利完成。目前,新的集群已在新机房稳定运行超过两个月,监控数据显示,新集群的查询响应时间显著降低,系统稳定性大幅提升。此外,数据消费的波动也变得更加平滑,整体性能得到了显著优化。 ... [详细]
  • 本文介绍了并查集(Union-Find算法)的基本概念及其应用。通过一个具体的例子,解释了如何使用该算法来处理涉及多个集合的问题。题目要求输入两个整数 n 和 m,分别表示总人数和操作次数。算法通过高效的合并与查找操作,能够快速确定各个元素所属的集合,适用于大规模数据的动态管理。 ... [详细]
  • 在CentOS 7环境中安装配置Redis及使用Redis Desktop Manager连接时的注意事项与技巧
    在 CentOS 7 环境中安装和配置 Redis 时,需要注意一些关键步骤和最佳实践。本文详细介绍了从安装 Redis 到配置其基本参数的全过程,并提供了使用 Redis Desktop Manager 连接 Redis 服务器的技巧和注意事项。此外,还探讨了如何优化性能和确保数据安全,帮助用户在生产环境中高效地管理和使用 Redis。 ... [详细]
  • 本文详细介绍了如何安全地手动卸载Exchange Server 2003,以确保系统的稳定性和数据的完整性。根据微软官方支持文档(https://support.microsoft.com/kb833396/zh-cn),在进行卸载操作前,需要特别注意备份重要数据,并遵循一系列严格的步骤,以避免对现有网络环境造成不利影响。此外,文章还提供了详细的故障排除指南,帮助管理员在遇到问题时能够迅速解决,确保整个卸载过程顺利进行。 ... [详细]
  • 本文详细探讨了OpenCV中人脸检测算法的实现原理与代码结构。通过分析核心函数和关键步骤,揭示了OpenCV如何高效地进行人脸检测。文章不仅提供了代码示例,还深入解释了算法背后的数学模型和优化技巧,为开发者提供了全面的理解和实用的参考。 ... [详细]
author-avatar
小白
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有