zoukankan      html  css  js  c++  java
  • Hadoop入门进阶步步高(六)-Hadoop1.x与Hadoop2的差别

    六、Hadoop1.xHadoop2的差别

    1、变更介绍

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

    l HDFSNameNodes能够以集群的方式布署,增强了NameNodes水平扩展能力和可用性;

    l MapReduceJobTracker中的资源管理及任务生命周期管理(包括定时触发及监控),拆分成两个独立的组件,并更名为YARNYet Another Resource Negotiator)。

    1.1HDFS的变化 增强了NameNode的水平扩展及可用性

    1.1.1Hadoop1.X架构的介绍

    而在1.x中的NameNodes仅仅可能有一个,尽管能够通过SecondaryNameNodeNameNode进行数据同步备份,可是总会存在一定的时延,假设NameNode挂掉,可是假设有部份数据还没有同步到SecondaryNameNode上,还是可能会存在着数据丢失的问题。

    架构例如以下:

    包括两层:

    Namespace

    l 包括文件夹、文件以及块的信息

    l 支持对Namespace相关文件系统的操作,如添加、删除、改动以及文件和文件夹的展示

    Block Storage Service包括两部份

    l 块管理(在Namenode中实现的)

    提供数据节点群集成员的登记,并定期通过心跳进行检查。

    提供块报告以及块的存储位置的维护

    提供对块的操作,如对块进行增删改的操作及获取块的存储地址

    对块的复本的的复制以及存储位置的管理

    l 存储 - 提供Datanode进行数据的本地存储,并提供读写的操作

    1.1.1Hadoop2.X架构的介绍

    2.X中,HDFS的变化,主要体如今增强了NameNode的水平扩展及可用性,能够同一时候部署多个NameNode,这些NameNodes之间是相互独立,也就是说他们不须要相互协调,DataNode同一时候在全部NameNodes注冊,做为他们共同拥有的存储节点,并向定时向全部的这些NameNodes发送心跳块使用情况的报告,并处理全部NameNodes向其发送的指令。

    架构例如以下:

     

    存储块池(Block Pool)

    一个存储块池是由一组存储块组成,它属于一个单独的Namespace(Namenode),集群中全部存储块池的存储块都是存放在Datanodes中的。每一个存储块池与其他的存储块池都是独立管理的,因而其在为新的块生成Block IDs时,就不须要与其他Namespace(Namenode)中的存储块池进行协作,即使一个Namespace(Namenode)挂掉了,也不会使得Datanodes中的块被訪问不到,由于其他Namespace(Namenode)中的存储块池也存放了Datanodes中全部存储块的信息。

    一个命名空间(Namespace)和它的块池一起被称为命名空间向量。它是一个自包括的管理单元。当一个Namenode/namespace被删除,存储于Datanodes中的相应的存储块池也会被删除掉,在集群的更新过程中,每一个命名空间向量都是以一个总体进行升级的。

    集群ID(ClusterID)

    集群ID的添加,是用于确认集群中全部的节点,也能够在格式化其他Namenodes时指定集群ID,并使其添加到某个集群中。

    1.2MapReduce拆分JobTracker为资源管理及任务生命周期管理两个独立的组件

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

    架构图:

    当中ResourceManager包括两个基本的组件:定时调用器(Scheduler)以及应用管理器(ApplicationManager)。

    定时调用器(Scheduler):

    定时调度器负责向应用程序分配置资源,它不做监控以及应用程序的状 态跟踪,而且它不保证会重新启动由于应用程序本身或硬件出错而运行失败 的应用程序。

    应用管理器(ApplicationManager):

    应用程序管理器负责接收新任务,协调并提供在ApplicationMaster容 器失败时的重新启动功能。

    节点管理器(NodeManager):

    NodeManager是ResourceManager在每台机器的上代理,负责容器的管 理,并监控他们的资源使用情况(cpu,内存,磁盘及网络等),以及向 ResourceManager/Scheduler提供这些资源使用报告。

    应用总管(ApplicationMaster):

    每一个应用程序的ApplicationMaster负责从Scheduler申请资源,以及 跟踪这些资源的使用情况以及任务进度的监控。

    2、详细变化

    2.1、配置文件的路径

    1.x中,Hadoop的配置文件是放在$HADOOP_HOME/conf文件夹下的,关键的配置文件在src文件夹都有相应的存放着默认值的文件,例如以下:

    配置文件

    默认值配置文件

    $HADOOP_HOME/conf/core-site.xml

    $HADOOP_HOME/src/core/core-default.xml

    $HADOOP_HOME/conf/hdfs-site.xml

    $HADOOP_HOME/src/hdfs/hdfs-default.xml

    $HADOOP_HOME/conf/mapred-site.xml

    $HADOOP_HOME/src/mapred/mapred-default.xml

    我们在$HADOOP_HOME/conf以下配置的core-site.xml等的值,就是对默认值的一个覆盖,假设没有在conf以下的配置文件里设置,那么就使用src以下相应文件里的默认值,这个在使用过程中非常方便,也非常有助于我们理解。

    Hadoop能够说是云计算的代名词,其也有非常多衍生的产品,不少衍生的配置方式都遵从Hadoop的这样的配置方式,如HBase的配置文件也是$HBase/conf文件夹,核心配置的名称就是hbase-site.xml,假设学习了Hadoop再去学习HBase,从配置的理解上来说,就会有一种亲切的感觉。

    可是在2.x中,Hadoop的架构发生了变化,而配置文件的路径也发生了变化,放到了$HADOOP_HOME/etc/hadoop文件夹,这样改动的目的,应该是让其更接近于Linux的文件夹结构吧,让Linux用户理解起来更easy。Hadoop 2.x中配置文件的几个基本的变化:

    l 去除了原来1.x中包括的$HADOOP_HOME/src文件夹,该文件夹包括关键配置文件的默认值;

    l 默认不存在mapred-site.xml文件,须要将当前mapred-site.xml.template文件copy一份并重命名为mapred-site.xml,而且仅仅是一个具有configuration节点的空文件;

    l 默认不存在mapred-queues.xml文件,须要将当前mapred-queues.xml.template文件copy一份并重命名为mapred-queues.xml

    l 删除了master文件,如今master的配置在hdfs-site.xml通过属性dfs.namenode.secondary.http-address来设置,例如以下:

    <property>

            <name>dfs.namenode.secondary.http-address</name>

            <value>nginx1:9001</value>

    </property>

    l 添加了yarn-env.sh,用于设置ResourceManager须要的环境变量,主要须要改动JAVA_HOME

    l 添加yarn-site.xml配置文件,用于设置ResourceManager

    2.2、命令文件文件夹的变化

    1.x中,全部的命令文件,都是放在bin文件夹下,没有区分client和服务端命令,而且终于命令的运行都会调用hadoop去运行;而在2.x中将服务端使用的命令单独放到了sbin文件夹,当中有几个基本的变化:

    l 将./bin/hadoop的功能分离。在2.x./bin/hadoop命令仅仅保留了这些功能:client对文件系统的操作、运行Jar文件、远程拷贝、创建一个Hadoop压缩、为每一个守护进程设置优先级及运行类文件,另外添加了一个检查本地hadoop及压缩库是否可用的功能,详情能够通过命令“hadoop -help”查看。

    而在1.x中,./bin/hadoop命令还包括:NameNode的管理、DataNode的管理、 TaskTrackerJobTracker的管理、服务端对文件系统的管理、文件系统的检查、获取队列 信息等,详情能够通过命令“hadoop -help”查看。

    l 添加./bin/hdfs命令。./bin/hadoop命令的功能被剥离了,并非代表这些命令不须要了,而是将这些命令提到另外一个名为hdfs的命令中,通过hdfs命令能够对NameNode格式化及启动操作、启动datanode、启动集群平衡工具、从配置库中获取配置信息、获取用户所在组、运行DFS的管理client等,详细能够通过“hdfs -help”查看。

    l 添加./bin/yarn命令。原来1.x中对JobTrackerTaskTracker的管理,放到了新增的yarn命令中,该命令能够启动及管理ResourceManager、在每台slave上面都启一个NodeManager、运行一个JARCLASS文件、打印须要的classpath、打印应用程序报告或者杀死应用程序等、打印节点报告等,详情能够通过命令“yarn -help”查看。

    l 添加./bin/mapred命令。该命令能够用于运行一个基于管道的任务、计算MapReduce任务、获取队列的信息、独立启动任务历史服务、远程文件夹的递归拷贝、创建hadooop压缩包,详情能够通过“./mapred -help”。

  • 相关阅读:
    NO.6: 若不想编译器提供自动生成的函数,就应该明确拒绝
    NO.5: 了解C++编译器默认为你生成的构造/赋值/析构
    NO.4: 确定对象被使用前已被初始化
    NO.3: 尽量使用const
    NO.2: 尽量以const,enum,inline 替换 #define
    NO.1: 视C++为一个语言联邦
    C/C++ exception类
    C/C++ 类成员函数指针 类成员数据指针
    c++中的 Stl 算法(很乱别看)
    自定义类签发校验token-实现多方式登录-自定义反爬类-admin后台表管理字段自定义-群查接口-搜索-排序-分页
  • 原文地址:https://www.cnblogs.com/mfrbuaa/p/4003040.html
Copyright © 2011-2022 走看看