HADOOP2.0较1.0版本的进步
1.1从Hadoop整体框架来说，Hadoop1.0即第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中HDFS由一个NameNode和多个DateNode组成，MapReduce由一个JobTracker 和多个TaskTracker组成。Hadoop
2.0即第二代Hadoop为克服Hadoop1.0中的不足：针对Hadoop1.0单NameNode制约HDFS的扩展性问题，提出HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时彻底解决了NameNode单点故障问题，单点故障是通过主备NameNode切换实现的，这是一种古老的解决服务单点故障的方案，主备NameNode之间通过一个共享存储同步元数据信息，因此共享存储系统的选择称为关键而Hadoop则提供了NFS、QJM和Bookeeper三种可选的共享存储系统，HDFS Federation实现的，它允许一个HDFS集群中存在多个NameNode，每个NameNode分管一部分目录，而不同NameNode之间彼此独立，共享所有DataNode的存储资源，注意，NameNode Federation中的每个NameNode仍存在单点问题，需为每个NameNode提供一个backup以解决单点故障问题；针对Hadoop1.0中的MapReduce在扩展性和多框架支持等方面的不足，它将JobTracker中的资源管理和作业控制分开，分别由ResourceManager（负责所有应用程序的资源分配）和ApplicationMaster（负责管理一个应用程序）实现，即引入了资源管理框架Yarn。
1.2从MapReduce计算框架来讲MapReduce1.0计算框架主要由三部分组成：编程模型、数据处理引擎和运行时环境。它的基本编程模型是将问题抽象成Map和Reduce两个阶段，其中Map阶段将输入的数据解析成key/value，迭代调用map()函数处理后，再以key/value 的形式输出到本地目录，Reduce阶段将key相同的value进行规约处理，并将最终结果写到HDFS上；它的数据处理引擎由MapTask和ReduceTask组成，分别负责Map阶段逻辑和Reduce阶段的逻辑处理；它的运行时环境由一个JobTracker和若干个TaskTracker两类服务组成，其中JobTracker负责资源管理和所有作业的控制，TaskTracker负责接收来自JobTracker的命令并执行它。MapReducer
2.0具有与MRv1相同的编程模型和数据处理引擎，唯一不同的是运行时环境。MRv2是在MRv1基础上经加工之后，运行于资源管理框架Yarn之上的计算框架MapReduce。它的运行时环境不再由JobTracker和TaskTracker等服务组成，而是变为通用资源管理系统Yarn和作业控制进程ApplicationMaster，其中Yarn负责资源管理的调度而ApplicationMaster负责作业的管理。
3. Hadoop 1.0中的资源管理方案
Hadoop 1.0指的是版本为Apache Hadoop 0.20.x、1.x或者CDH3系列的Hadoop，内核主要由HDFS和MapReduce两个系统组成，其中，MapReduce是一个离线处理框架，由编程模型（新旧API）、运行时环境（JobTracker和TaskTracker）和数据处理引擎（MapTask和ReduceTask）三部分组成。
Hadoop 1.0资源管理由两部分组成：资源表示模型和资源分配模型，其中，资源表示模型用于描述资源的组织方式，Hadoop 1.0采用“槽位”（slot）组织各节点上的资源，而资源分配模型则决定如何将资源分配给各个作业/任务，在Hadoop中，这一部分由一个插拔式的调度器完成。
Hadoop引入了“slot”概念表示各个节点上的计算资源。为了简化资源管理，Hadoop将各个节点上的资源（CPU、内存和磁盘等）等量切分成若干份，每一份用一个slot表示，同时规定一个task可根据实际需要占用多个slot 。通过引入“slot“这一概念，Hadoop 将多维度资源抽象简化成一种资源（即slot），从而大大简化了资源管理问题。更进一步说，slot相当于任务运行“许可证”，一个任务只有得到该“许可证”后，才能够获得运行的机会，这也意味着，每个节点上的slot数目决定了该节点上的最大允许的任务并发度。为了区分Map Task和Reduce Task所用资源量的差异，slot又被分为Map slot和Reduce slot两种，它们分别只能被Map Task和Reduce Task使用。Hadoop集群管理员可根据各个节点硬件配置和应用特点为它们分配不同的map slot数（由参数mapred.tasktracker.map.tasks.maximum指定）和reduce slot数（由参数mapred.tasktrackerreduce.tasks.maximum指定）。
3.1Hadoop 1.0中的资源管理存在以下几个缺点：
（1）静态资源配置。采用了静态资源设置策略，即每个节点实现配置好可用的slot总数，这些slot数目一旦启动后无法再动态修改。
（2）资源无法共享。Hadoop 1.0将slot分为Map slot和Reduce slot 两种，且不允许共享。对于一个作业，刚开始运行时，Map slot资源紧缺而Reduce slot空闲，当Map Task全部运行完成后，Reduce slot紧缺而Map slot空闲。很明显，这种区分slot类别的资源管理方案在一定程度上降低了slot的利用率。
（3）资源划分粒度过大。这种基于无类别slot的资源划分方法的划分粒度仍过于粗糙，往往会造成节点资源利用率过高或者过低，比如，管理员事先规划好一个slot代表2GB内存和1个CPU，如果一个应用程序的任务只需要1GB内存，则会产生“资源碎片”，从而降低集群资源的利用率，同样，如果一个应用程序的任务需要3GB内存，则会隐式地抢占其他任务的资源，从而产生资源抢占现象，可能导致集群利用率过高。
（4）没引入有效的资源隔离机制。Hadoop 1.0仅采用了基于jvm 的资源隔离机制，这种方式仍过于粗糙，很多资源，比如CPU，无法进行隔离，这会造成同一个节点上的任务之间干扰严重。
3.2 Hadoop 2.0中的资源管理方案
Hadoop 2.0指的是版本为Apache Hadoop 0.23.x、2.x或者CDH4系列的Hadoop，内核主要由HDFS、MapReduce和YARN三个系统组成，其中，YARN是一个资源管理系统，负责集群资源管理和调度，MapReduce则是运行在YARN上离线处理框架，它与Hadoop 1.0中的MapReduce在编程模型（新旧API）和数据处理引擎（MapTask和ReduceTask）两个方面是相同的。资源分配的本质，即根据任务资源
需求为其分配系统中的各类资源。在实际系统中，资源本身是多维度的，包括CPU、内存、网络I/O和磁盘I/O等，因此，如果想精确控制资源分配，不能再有slot的概念，最直接的方法是让任务直接向调度器申请自己需要的资源（比如某个任务可申请 1.5GB 内存和1个CPU），而调度器则按照任务实际需求为其精细地分配对应的资源量，不再简单的将一个Slot分配给它，Hadoop 2.0正式采用了这种基于真实资源量的资源分配方案。Hadoop 2.0（YARN）允许每个节点（NodeManager）配置可用的CPU和内存资源总量，而中央调度器则会根据这些资源总量分配给应用程序。
可分配的物理内存总量，默认是8*1024，即8GB。任务使用单位物理内存量对应最多可使用的虚拟内存量，默认值是2.1，表示每使用1MB的物理内存，最多可以使用2.1MB的虚拟内存总量。可分配的虚拟CPU个数，默认是8。为了更细粒度的划分CPU资源和考虑到CPU 性能异构性，YARN允许管理员根据实际需要和CPU性能将每个物理CPU划分成若干个虚拟CPU，而每管理员可为每个节点单独配置可用的虚拟CPU个数，且用户提交应用程序时，也可指定每个任务需要的虚拟CPU个数。比如node1节点上有8个CPU，node2上有16个CPU，且node1 CPU性能是node2的2倍，那么可为这两个节点配置相同数目的虚拟CPU个数，比如均为32，由于用户设置虚拟CPU个数必须是整数，每个任务至少使用node2 的半个CPU（不能更少了）。
此外，Hadoop 2.0还引入了基于cgroups的轻量级资源隔离方案，这大大降低了同节点上任务间的相互干扰，而Hadoop 1.0仅采
用了基于JVM的资源隔离，粒度非常粗糙。
尽管Hadoop 2.中的资源管理方案看似比较完美，但仍存在以下几个问题：
（1）资源总量仍是静态配置的，不可以动态修改。
（2）CPU是通过引入的“虚拟CPU”设置的，而虚拟CPU的概念是模糊的，有歧义的，而社区正在尝试借鉴amazon EC2中的ECU概念对其进行规整化，
（3）无法支持以组为单位的资源申请（4）调度语义不完善，比如目前应用程序只能申请的同一个节点上相同优先级的资源种类必须唯一，比如来自节点node1上优先级为3的资源大小是<1 vcore 2048 mb>，则不能再有自他大小，否则将会被覆盖掉。
（4）在资源管理方面，Hadoop 2.0比1.0先进的多，它摒弃了基于slot的资源管理方案，采用了基于真实资源的管理方案，这将在资源利用率、资源控制、资源隔离等方面有明显改善，随着Hadoop 2.0调度语义的丰富和完善，它必将发挥越来越大的作用。
4.YARN是“Yet Another Resource Negotiator”的简称，它是Hadoop 2.0引入的一个全新的通用资源管理系统，可在其之上运行各种应用程序和框架，比如MapReduce、Tez、Storm等，它的引入使得各种应用运行在一个集群中成为可能。YARN是在MRv1基础上衍化而来的，是MapReduce发展到一定程度的必然产物，它的出现使得Hadoop计算类应用进入平台化时代。随着YARN的成熟和稳定，必将形成一个以YARN为核心的生态系统，在该生态系统中，所有计算相
关的框架可运行在一个YARN集群中（由于YARN本身设计上的一些问题，目前还难以运行通用的服务，比如Web Server、HBase等，未来趋势肯定是各类系统或者服务可运行在一个集群中，进行统一资源管理和调度）。
4.1将框架运行在YARN上带来的好处
随着YARN的的成熟和稳定，各类应用程序可以运行在一个YARN 集群中进行统一资源管理和调度，这样带来的变化如下：
（1）应用程序部署变得更加简单
管理员只需部署YARN服务即可，各类应用程序框架不再自带服务，无需实现部署，它们已经变成了客户端编程库（library），由YARN 提供的分布式缓存机制分发到各个节点上；
（2）服务部署变得简单
用户可以通过运行一个应用程序的方式部署一套服务，比如Storm服务，至于jar包拷贝等工作，完全由YARN自动完成，部署完成后，用户像使用普通的Storm集群那样使用Storm-On-YARN
（3）多版本共享集群资源（简单的隔离）
由于YARN只负责资源管理和调度，至于其上运行什么应用或者服务，完全由用户自己决定，这使得用户可在YARN上运行多个同类服务实例，比如运行多个Storm实例供不同类型的应用，YARN本身可以为这些实例提供隔离机制（Cgroups）。有了YARN之后，用户开发新的框架或者应用程序时，可不必在考虑资源隔离问题。
（4）资源弹性管理
由于多类应用运行在一个YARN集群中，比如离线计算、实时计算、DAG计算等，YARN可根据不同类型的应用程序压力情况，调整对应的资源使用量，实现资源弹性管理。
4.2目前可运行在YARN上的计算框架
运行在YARN上的框架，包括MapReduce-On-YARN, Spark-On-YARN, Storm-On-YARN和Tez-On-YARN。
（1）MapReduce-On-YARN：YARN上的离线计算，YARN发行版中自带该实现，随着YARN的稳定，MRv1运行方式会被淘汰；
（2）Spark-On-YARN：YARN上的内存计算；
（3）Storm-On-YARN：YARN上的实时/流式计算；
（4）Tez-On-YARN：YARN上的DAG计算
5.在2.2.0版本之前，Hadoop仅支持Linux操作系统，而Windows 仅作为实验平台使用。从2.2.0开始，Hadoop开始支持Windows操作系统。
6.新版本对HDFS做了两个非常重要的增强：（1）、支持异构的存储层次；（2）、通过数据节点为存储在HDFS中的数据提供了内存缓存功能。借助于HDFS对异构存储层次的支持，我们将能够在同一个Hadoop集群上使用不同的存储类型。此外我们还可以使用不同的存储媒介——例如商业磁盘、企业级磁盘、SSD或者内存等——更好地权衡成本和收益。如果你想更详细地了解与该增强相关的信息，那么可以访问这里。类似地，在新版本中我们还能使用Hadoop集群中的可用内存集中地缓存并管理数据节点内存中的数据集。MapReduce、
Hive、Pig等类似的应用程序将能够申请内存进行缓存，然后直接从数据节点的地址空间中读取内容，通过完全避免磁盘操作极大地提高扫描效率。Hive现在正在为ORC文件实现一个非常有效的零复制读取路径，该功能就使用了这项新技术。
7.1总体来说，Hadoop1.0在HDFS和MapReduce在高可用方面、扩展性方面存在问题。HDFS存在的问题：NameNode单点故障，难以应用于在线场景；NameNode压力过大，且内存受限，影响系统扩展性。MapReduce存在的问题：JobTracker单点故障；JobTracker访问压力大，影响系统扩展性；难以支持除MapReduce之外的框架，如Spark、Storm等
7.2Hadoop2.0解决的HDFS问题：解决单点故障：通过主备NameNode 解决，如果主NameNode发生故障，则切换到备NameNode。HDFS HA：主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换；所有的DataNode同时想两个NameNode汇报数据块信息。切换方式：手动切换：通过命令实现主备之间的切换，可以用HDFS 升级等场合； Zookeeper自动切换（ZookeeperFailoverController （ZKFC）：监控NameNode健康状态，并向Zookeeper注册NameNode；NameNode挂掉后ZKFC为NameNode竞争锁，获得ZKFC竞争锁的NameNode变为主NameNode）
7.3解决内存受限问题：水平扩展，支持多个NameNode,每个NameNode 分管一部分目录，所有的NameNode共享所有DataNode存储资源
7.4为了解决MapReduce问题，2.0版本新引入Yean资源管理系统，
将JobTracker的资源管理和任务调度两个功能分开，分别由ResourceManager和ApplicationMaster进程实现。ResourceManager:负责整个集群的资源管理和调度，ApplicationMaster:负责应用程序的相关的事物,比如任务调度、任务监控和容错等。Yarn的引入使的多个计算框架可以运行在一个集群中，每一个应用程序对应一个ApplicationMaster。将MapReduce的作业直接运行在Yarn上，而不是运行在有JobTracker和TaskTRacker构建的MapReduce1.0系统上。