Hadoop1.0,2.0,3.0区别

Hadoop1.x

  • 组成
    由Common(公共模块辅助工具)、HDFS(分布式数据存储)、MapReduce(分布式计算+资源调度)组成
  • 简介
    其中HDFS由一个NN和多个DN组成，MapReduce有一个JobTracker和多个TaskTracker组成。
    在Hadoop1.0中容易造成单点故障，拓展性差，性能低，支持编程模型单一的问题。
  • 困境
    (1) 单点故障
    · 每个集群只有一个NN，NN存在单点故障
    · 如果该计算机或进程不可用，那么整个集群在整个NN重新启动或另一台计算机启动之前将不可用
    · 如果发生意外，如机器崩溃，则在操作员重新启动NN之前，集群将不可用
    · 计划之内的维护事件，例如NN计算机上的硬件或软件升级，将导致集群停机时间延长
    (2) 水平扩展
    · NN内存占满，将无法提供服务
    · NN随着业务的增多，内存占用也会越来越多
    · 将来服务器启动的时候，启动速度慢
    (3) 业务隔离性差
    · 存储：存储不同部门的数据；
    · 计算：有可能存在不同业务的计算流程
    · 项目后期NN的吞吐量将会是集群的瓶颈，客户端所有的请求都会访问NN

Hadoop2.x

  • 组成
    由Common(公共模块辅助工具)、HDFS(分布式数据存储)、MapReduce(分布式数据计算)、YARN(统一资源调度)组成
  • 改进
    · Yarn是Hadoop2.0引入的一个全新的通用资源管理系统，完全代替了Hadoop1.0中的JobTracker. 在MR中的JobTracker
    资源管理器和作业跟踪的功能被抽象为ResourceManager和AppMaster两个组件。Yarn还支持多种应用程序和框架，提供了
    统一的资源调度和管理功能。
    · NN单点故障得以解决：Hadoop2.x同时解决了NN单点故障问题和内存受限问题(1.ResourceManager和AppMaster,2.NameNode一个Active一个Standby)，
    并提供了NFS、QJM、Zookeeper三种可选的共享存储系统。QJM是采用journalnode来共享edits文件，而NFS方式是采用NFS远程共享目录来共享edits文件。
    · HDFS快照
    · 支持Windows操作系统
    · Append引入了对文件的追加操作

Hadoop2.x补充

1. NN结点的高可用(HA)

设计思想：
hadoop2.x启用了主备节点切换模式(1主1备)
当主节点出现异常的时候，集群直接将备用结点切换成主节点。
1.要求备用结点马上就要工作。2.主备结点内存几乎同步。
3.有独立的线程对主备节点进行监控健康状态。
4.需要有一定的选举机制，帮助我们确定主从关系。
5.我们需要实时存储日志的中间件。

2. 合并日志文件和镜像

当搭建好集群的时候，格式化主备结点的时候，ANN和SNN都会默认创建fsimage_00000000000000文件，
当我们操作HDFS的时候，ANN会产生日志信息edits_inprogress_0000000000001,
主节点会将日志文件中新增的数据同步到JournalNode集群上，
所以只要snn有操作的日志信息，就可以合并fsimage与edits信息，理论上是一直合并数据
fsimage->初始化创建
edits->从JournalNode集群上定时同步
只要同步到edits文件，就开始与fsimage合并
当达到阈值的时候，直接拍摄快照即可，SNN将合并好的Fsimage发送给ANN，ANN验证无误后，存放到自己的目录中。

3. 高可用(Quorum JournalNode Manager)

(journal集群)JournalNode    JournalNode    JournalNode.....JournalNode    
    👆提交EditLog                    👆定时同步EditLog
    Active NameNode            Standby NameNode

(1)NN通过共享存储系统实现日志数据同步。
JournalNode是一个独立的小集群，它的实现原理同Zookeeper(Paxos)
(2)ANN产生日志文件的时候，就会同时发送到JournalNode的集群中每个结点上，JournalNode不要求所有的JournalNode结点都接受到日志，
只要有半数以上的(n/2+1)结点接收到日志，那么本条日志就生效。
(3)SNN每间隔一段时间就去QJM上面取回最新的日志
SNN上的日志有可能不是最新的。
(4)HA集群的状态正确至关重要，一次只能有一个NN处于活动状态，JournalNode只允许单个NN成为作者。
在故障转移期间，将变为活动状态的NN将承担写入JournalNode的角色。这将有效地防止另一个NN继续处于活动状态，
从而使新的Active结点可以安全的进行故障转移。

4. ZKFC

Failover Controller(故障转移控制器)
(1)对于NN的主备切换进行总体控制，能及时检测到NN的健康情况
(2)在主NN故障时借助Zookeeper实现自动的主备选举和切换
(3)为了防止因为NN的GC(垃圾回收)失败导致心跳受影响，ZKFC作为一个deamon进程从NN分离出来。

5. Zookeeper

(1)为主备切换控制器提供主备选举支持
(2)辅助投票
(3)和ZKFC保持心跳机制，确定ZKFC的存活

6. 脑裂

(1)定义：脑裂是Hadoop2.x版本后出现的全新问题，实际运行过程中很有可能出现两个NN同时服务于整个集群的情况，
这种情况称之为脑裂
(2)原因：脑裂通常发生于主从NN切换时，由于ActiveNameNode的网络延迟、设备故障等问题，另一个NN会认为活跃的
NN成为失效状态，此时StandbyNameNode会转换成活跃状态，此时集群中将会出现两个活跃的NN。因此，可能出现的因素
有网络延迟、心跳故障、设备故障等。
(3)脑裂场景
· NN可能会出现这种场景，NN在垃圾回收(GC)时，可能会在长时间内整个系统无响应
· zkfc客户端也就无法向zk写入心跳信息,这样的话可能导致临时节点掉线，备NN会切换到Active状态
· 这种情况可能会导致整个集群会有同时两个Active NameNode
(4)脑裂问题的解决方案是隔离
· 第三方共享存储：任一时刻，只有一个NN可以写入
· DataNode：需要保证只有一个NN发出于管理数据副本有关的命令
· Client需要保证同一时刻只有一个NN能够对Client的请求发出正确的响应
a.每个NN改变状态的时候，向DN发送自己的状态和一个序列化
b.DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。
DN接受到这个返回是认为该NN是新的active.
(5)解决方案
· ActiveStandbyElector在异常的状态下关闭，那么由于/hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb是持久节点，会一直保留下来，
后面当另一个NN选举陈工后，会注意到上一个Active NameNode遗留下来的这个节点，从而会回调ZKFailoverController的方法对旧的ActiveNameNode
进程fencing
{
1.首先尝试调用这个旧Active NameNode的HAService Protocol RPC接口的transitionToStandby方法，看能不能把它转换为Standby状态
2.如果transitionToStandby方法调用失败，那么就执行Hadoop配置文件之中预定义的隔离措施
{
· sshfence:通过SSH登录到目标机器上，执行命令fuser将对应的进程杀死
· shellfence:执行一个用户自定义的shell脚本来将对应的进程杀死
}
}
· 在成功地执行完成fencing之后，选主成功的ActiveStandbyElector才会回调ZKFailoverController的becomeActive方法将对应的NN转换为Active状态，
开始对外提供服务

7.Hadoop-Federation Hadoop水平扩展联邦机制

作用：

HDFS Federation就是使得HDFS支持多个命名空间，并且允许在HDFS中同时存在多个NN

单个NN局限性

(1)NameSpace(命名空间)的限制
NN所能存储的对象(文件+块)数目受到NameNode所在JVM的heap size的限制。
50G的heap能够存储20亿(200million)个对象，这20亿个对象支持4000个DN，12PB的存储。
DN从4T增长到36T，集群的尺寸增长到8000个DN。存储的需求从12PB增长到大于100PB。
(2)性能的瓶颈
整个HDFS文件系统的吞吐量受限于单个NN的吞吐量
(3)隔离问题
HDFS上的一个实验程序有可能影响整个HDFS上运行的程序
(4)集群的可用性
NameNode的宕机会导致整个集群不可用
(5)NameSpace和Block Managerment的紧密集合
将NameNode的Heap空间扩大到512GB启动花费的时间太长
NameNode在Full GC(垃圾回收)时，如果发生错误将会导致整个集群宕机

Hadoop-Federation水平扩展联邦机制的解决方案

块池Block Pool
Block Pool就是属于单个命名空间的一组block(块)管理区域
(namespace1) (block pool) (NN NN NN ...)
(namespace2) (block pool) (NN NN NN ...)
(namespace3) (block pool) (NN NN NN ...)
(1)一个NameSpace和它的Block Pool合在一起称作Name Space Volume(一个独立完整的管理单元)
(2)当一个NameNode/NameSpace被删除，与之相对应的Block Pool也被删除
(3)通过多个NameNode/NameSpace把元数据的存储和管理分散到多个节点中，降低单个节点数据压力，及计算压力
(4)NameNode/NameSpace可以通过增加机器来进行水平扩展，可以让更多的节点参与到运算
(5)NameSpace命名空间，通过这种方式确定要处理数据的路径
(6)我们可以通过NameNode和NameSpace组合使用，所有的NameNode共享DataNode,但是每一个NameSpace会单独管理自己的块，
会创建一个管理块的机制：blocks pool

Hadoop3.x

  • 比较
    相比于Hadoop2.x,他是直接基于JDK1.8发布的一个新版本，同时Hadoop3.0引入了一些重要的功能和特性：
  1. HDFS可擦除编码：使HDFS在不降低可靠性的前提下节省了很大一部分存储空间
  2. 多NameNode支持。从Hadoop3.0开始，在同一个集群中支持一个ActiveNameNode和多个StandByNameNode的部署方式
  3. MR Native Task优化
  4. Yarn 基于cgroup的内存和磁盘I/O隔离
  5. Yarn contatiner resizing

Hadoop3.x补充

1.EC(擦除编码)


2.NameNode(增加了容错性)

在Hadoop3中允许用户使用多个备用的NameNode
例如：
通过配置三个NameNode(1个Active NameNode和2个NameNode)和5个JournalNodes节点
集群可以容忍2个NameNode节点故障

3.服务器端口

早些时候，多个Hadoop服务的默认端口位于Linux端口范围以内
因此，具有临时范围冲突端口已经被移除范围

4.DataNode

单个数据节点配置多个数据磁盘，在正常写入操作期间，数据被均匀的划分，因此，磁盘被均匀填充。
在维护磁盘时，添加或者替换磁盘会导致DataNode节点存储出现偏移。（如：数据本该写在磁盘2上，结果写到了磁盘1上）
Hadoop3通过新的内部DataNode平衡功能来处理这种情况，这是通过hdfs diskbalancer CLI来进行调用的。
执行之后，DataNode会进行均衡处理

5.JDK

Hadoop3中，最低版本要求是JDK8，所以低于JDK8的版本需要对JDK 进行升级，方可安装使用Hadoop3

6.Yarn

提供YARN的时间轴服务V.2，以便用户和开发人员可以对其进行测试，并提供反馈意见

7.优化Hadoop Shell脚本

8.重构Hadoop Client Jar包

9.支持随机Container

10.MapReduce任务级本地优化

11.支持文件系统连接器

posted @ 2022-03-04 21:34  jsqup  阅读(658)  评论(0)  编辑  收藏  举报