Hadoop1.0与Hadoop2.0的区别

1.Hadoop****概述

基于Google发表了三篇关于大数据的重要论文后, Cloudera公司在此基础上开发出了如今的Hadoop系统。然而,在其发展过程中并非一帆风顺,其1.0版本存在诸多不足之处。随后,在其不断实践中,出现了 Hadoop 2.0,并逐渐成为了大数据领域的主流技术。那么,HDFS是否存在哪些缺陷?当它升级至 Hadoop 2.0 时又做出了哪些改进?最终,HDFS 成为大数据的基础技术吗?

2.Hadoop1.0

我们首先深入探讨hadoop 1.0的核心架构。该系统主要由两个关键组件构成：一个是分布式文件系统HDFS(Hadoop Distributed File System) ，另一个是分布式计算框架MapReduce 。下面我们将逐一分析这两个核心组件的具体架构和功能。

2.1****HDFS1.0

在HDFS中基于主从模式构建了其主要运行架构即 master_slave 架构其中主从模式被称为 master_slave 模式具体而言 master 主节点称之为 NameNode 节点而 slave 从节点则被称为 DataNode 节点

这个NameNode的职责是什么呢？

１、NameNode管理着整个文件系统，负责接收用户的操作请求

NameNode负责维护整个文件系统中的文件和目录层级关系，在计算机领域中常用术语中将其比作Windows操作系统中的层次化架构

Name Node负责管理整个文件系统的元数据信息块。即元数据信息块是指除了单个文件之外还包含与文件相关的信息。

NameNode维护着文件与其相关的block块序列之间的对应联系，并且管理着block块与其相关联的DataNode节点之间的关联关系

在Hadoop 1.0版本中, name node仅有一个, 尽管可以通过 secondary name node与 name node 进行数据同步备份, 然而在这种机制下仍不可避免地存在一定的延迟。当name node出现故障时, 若有部分关键数据尚未同步至secondary name node之上, 这可能导致关键数据丢失的风险仍然存在。

值得注意的是，在Hadoop分布式文件系统（HDFS）中，实际存储的真实数据主要由DataNode进行管理并存储；而具体地记录在哪个DataNode节点上的元数据信息，则是由NameNode用来管理并记录这些元数据信息。

这种架构实现的好处的简单，但其局限同样明显：

单点故障问题 ：由于NameNode存储了我们用户存储文件的完整元数据信息，在NameNode无法从内存中加载完整元数据信息时，集群的生命就将终止。

拓展性问题：NameNode通过内存实现了对元数据信息的管理，并且仅有一台物理服务器可用。该物理服务器的资源必然会在某时刻达到饱和状态。

性能问题 ：当HDFS中存储大量的小文件时，会使NameNode的内存压力增加。

隔离性能问题：单一 namenode 无法充分保障隔离性能；具体表现为：当某个用户提交具有较大计算负荷的 job 时，该 job 的运行会显著影响其他用户的 job 运行效率。

2.2****MapReduce

对MapReduce而言也是一个主从结构由一个称为JobTracker的主节点和多个称为TaskTracker的从节点构成其中RoleManager协调各节点间的任务分配工作这体现了其既能管理又能执行的强大功能

１、负责接收client提交给的计算任务。

２、负责将接收的计算任务分配给各个的TaskTracker进行执行。

心跳机制被用来监控TaskTracker机器的工作状态，并且观察任务task的状态变化

这个架构的缺陷：

单一故障点仍是当前的问题核心。当JobTracker发生故障时，将导致MapReduce作业无法继续运行。

资源过度消耗：JobTracker承担了大量任务并导致了额外的资源消耗，在map-reduce作业数量极大的情况下会产生较大的内存占用，并增加了JobTracker出现失效的可能性。这也反映了行业内普遍认为旧版Hadoop（即老Hadoop）基于Map-Reduce架构的最大承载节点数限制在4,000台主机以内这一技术瓶颈。

仅限于简单的MapReduce程序设计框架 ：当采用Hadoop进行编程时，仅能采用基础型 MapReduce 程序设计框架，并非能够实现像 Spark 这样的分布式计算框架。此外，并不支持流处理系统或实时计算技术。

3.Hadoop2.0

相较于其前版本而言（即从 Hadoop 1.x 升级至 Hadoop 2.x），最显著的改进在于引入了 Yarn 资源调度框架。我们仍然将 HDFS 和 Yarn/MapReduce 两部分作为主要讲述内容。

3.1****HDFS2.0

针对此问题提出了分布式文件系统的联邦架构（HDFSFederation）及高可用性的HA方案。此时各个NameNode之间实现了相互独立，并无需进行任何协调操作。多个NameNode负责管理不同的目录区域，并通过访问隔离机制实现了访问隔离的同时也实现了横向扩展。

这样NameNode的扩展性容易增强功能，并且调研结果表明Hadoop 2.0最高支持1万节点同时运行，并且这种架构优化措施改善了 NameNode 的单点故障问题。

再来说说高可用(HA)，HA指的是可以让两个NameNode同时运行的状态。其中一台持续工作（Active），另一台随时待命（Standby）。当一台NameNode所在服务器出现故障时，在确保数据完整性的情况下，在手动操作或自动机制下切换到另一台NameNode继续服务。

3.2****Yarn/MapReduce2

为了弥补Hadoop 1.0 中 MapReduce（MR）功能的缺陷而引入了 Yarn 框架。在 Yarn 架构下设置了资源分配与作业调度分离机制，并划分出 ResourceManager（RM）和 Application Master（AM）两个主要组件。

而Yarn框架则充当了一个广泛应用于资源调度与管理的关键组件，在支持多种不同的编程范式方面表现尤为出色。例如，在其众多支持的平台中,最为著名的是Spark平台

Yarn的主要三个组件如下：

资源管理模块：该系统由两大核心组件构成：定时调度模块以及应用管理模块。

定时调度器(Scheduler)：该定时调度器（Scheduler）负责为应用程序分配资源。它不进行应用状态监控或跟踪，并未确保因软件故障或硬件故障导致的应用程序崩溃会被重新启动。

应用管理器(ApplicationManager)：处理新任务的应用程序管理器，在ApplicationMaster容器失效时为系统提供支持和协助。

２、Application Manager：每个应用程序的应用程序实例负责从Scheduler获取所需资源，并同时负责跟踪这些资源的使用情况以及监督任务执行进度。

**３、**Node Manager：NodeManager是一个代理实例，在每台主机上代理ResourceManager的功能。它负责管理容器并追踪它们的资源使用情况（如CPU、内存、存储以及网络资源等），并将这些数据传递给ResourceManager/Scheduler以便进行监控。

关于Hadoop1.0和2.0的一点点感悟

没有任何事物是完美无缺的，即使是当下最流行的Hadoop技术也一样。从这一点可以看出，Hadoop 1.0虽然显得较为简陋，但其主要目的就是实现简单易行。这种做法不仅与敏捷开发的理念相契合，同样等同于产品经理所说的最小功能产品（MVP），即先推出一个核心功能齐全但相对简单的版本出来，在市场中进行检验后再逐步进行升级优化。

在那种 era 下许多企业都面临着没有独立的大数据环境的挑战情况下,Hadoop 一马当先取得了成功。随后基于市场反馈以及开源社区的持续指导, 不断进行优化和完善, 最终巩固了大数据领域中的核心地位

我们在平时的产品开发中也应当学习Hadoop的方法，在初期制作出最小可行性版本，并逐步优化提升以适应后续需求的变化。当然这对那些追求完美的用户来说可能会让他们感受到一定的压力。

你看，在这个世界上万物之间往往存在联系，在某些情况下或思维层面我们可以将技术发展与产品设计之间有着深刻的关联。有时候我们在探讨问题时或许会跳出技术和业务的具体框架，在更高的层次上进行思考——在这样的背景下你认为这其中值得我们去深入探索的知识点有哪些？这些同样蕴含着丰富的借鉴意义……在此处

以上~