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

关注

转载最新推荐文章于 2022-10-06 16:10:44 发布 3.7k 阅读 AI 写同款· GEO 优化 ›

Hadoop2.x与Hadoop3.x的默认端口变化最近配置Hadoop3.x集群的时候发现了一些端口变动，导致web访问UI界面失败，查阅资料写个帖子记录分析一下。 Namenode 端口: 2.x端口 3.x端口 name desc 50470 9871 dfs.namenode.https-address The namenode secure http server address and port. 50070 987... 阅读详情

Hadoop2相比较于Hadoop1.x来说，HDFS的架构与MapReduce的都有较大的变化，且速度上和可用性上都有了很大的提高，Hadoop2中有两个重要的变更：
（1）HDFS的NameNode可以以集群的方式布署，增强了NameNodes的水平扩展能力和高可用性，分别是:HDFSFederation与HA；
（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

收录于