文章大纲:
在开始Hadoop的部署之前需要了解其基础知识及部分原理,由于本文以部署的介绍为主,篇幅有限,因此只会对这部分内容作简单的阐述,后面有机会会撰写专门的Hadoop原理及基础系列文章。
01Hadoop 简介
一、Hadoop是什么
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力,解决海量数据的存储及海量数据的分析计算问题。
广义上的Hadoop是指Hadoop的整个技术生态圈;狭义上的Hadoop指的是其核心三大组件,包括HDFS、YARN及MapReduce.
二、Hadoop的发展史
Hadoop起源于Lucene框架,后其创始人为解决对于海量数据存储困难、检索速度慢的问题,借鉴了Google的大数据神级三大思想,创建了Nutch,后被分离出来,纳入Apache的项目Hadoop中。因此说Google的大数据三大思想是Hadoop的思想之源也不为过。这三大思想分别对应三篇论文:
建议大家都去找这三篇论文进行阅读学习,这对大数据的理解大有裨益,而且最好看英文原版,资源可在网上搜索查找。
三、Hadoop发行版本
Hadoop目前发展得最好的有三大发行版本:Apache、Cloudera(CDH)、Hortonworks(HDP)。他们都有各自的特点:
我们的介绍基于Apache版本开展。
四、Hadoop的优势
五、Hadoop1.x与2.x的区别
在Hadoop1.x时代,Hadoop中的MapReduce同时处理业务逻辑运算和资源的调度,耦合性较大。 在Hadoop2.x时代,增加了Yarn。Yarn只负责资源的调度,MapReduce只负责分析运算。 Hadoop3.x在组成上没变化,但在功能和性能方面,对Hadoop内核进行了多项重大改进。由于本文基于2.x目前最新版本2.10.1进行介绍,3.x版本会在之后再作详细探讨。
图1-5-1:Hadoop1.x与2.x区别
02Hadoop 核心组件
Hadoop目前有很多组件,但狭义上的Hadoop是指其核心的三个组件:HDFS, YARN, MapReduce.
一、HDFS(Hadoop分布式文件系统)
HDFS(Hadoop Distributed File System) 负责海量数据的存储,是一个高度容错性系统,能检测和应对硬件故障。主要角色有NameNode, DataNode, SecondaryNameNode. HDFS采用 master/slave 架构,一个HDFS由一个NameNode和一定数目的DataNodes组成。
图2-1-1:HDFS架构图
图2-1-2:HDFS执行步骤
1. NameNode (NN)
NN是一个中心服务器,负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。其中存储了文件的元数据,包括文件名、文件目录结构、文件属性(生成时间、副本数、权限)等,以及每个文件的块列表和列表中的块与块所在的DataNode之间的地址映射关系。
NN的容错机制非常重要,因为如果运行NN的机器坏掉的话,系统中的文件将会完全丢失。Hadoop提供了两种机制:1)将持久化存储在本地硬盘的文件系统元数据备份;2)运行一个辅助的NN(SecondaryNameNode),定期将namespace镜像文件(fsimage)与操作日志文件(edit log)合并。
一般情况下,单NN集群的最大集群规模为4000台。
2. DataNode (DN)
DN一般是一个节点一个,负责管理它所在节点上的存储,真正用于在本地文件系统存放数据。DN的基本单位是块(block),默认128M。在HDFS上会保存数据的副本,默认是3个,即同一块数据会同时存储在3个不同的DN上进行备份,这个副本数量是可以设置的,后面进行配置的时候会介绍。
3. SecondaryNameNode (2NN)
2NN是辅助节点,用于同步元数据信息,辅助NN对fsimage和edit log进行合并(冷备份),以解决edit log过大及丢失改动信息的问题。
图2-1-3:SecondaryNameNode工作原理
二、YARN(资源调度管理框架)
YARN(Yet Another Resource Negotiator) 取代了Hadoop1.x中MapReduce的资源调度管理,为上层应用(Spark, Hive-MR任务等)提供统一的资源调度管理,Hadoop2.x以后MapReduce只是运行在YARN之上的一个纯粹的计算框架。
在整个YARN资源调度管理系统当中, ResourceManager作为Master ,各个节点的NodeManager作为Slave. ResorceManager组件和HDFS的NameNode部署在一个节点上,而YARN的NodeManager、ApplicationMaster及Container(代表计算资源)和HDFS的DataNode部署在一起。
图2-2-1:YARN架构图
1. ResourceManager (RM) —— 部门经理
RM是YARN的核心组件,或者说是YARN的master节点,一般分配在主节点上,并做HA部署。主要功能是负责处理client的job提交请求,监控NodeManager,并对集群所有资源(CPU和内存)进行管理、分配和调度,对系统中的资源有最高的支配权。可以理解为类似部门经理的角色。
RM作为资源的协调者有两个主要的组件:Scheduler和ApplicationsManager(AsM).
Scheduler负责分配最少但满足application运行所需的资源量给application. Scheduler只是基于资源的使用情况进行调度,并不负责监视或跟踪application的状态,当然也不会处理失败的task.
ApplicationsManager负责处理client提交的job以及协商第一个Container以供ApplicationMaster运行,并且在ApplicationMaster失败的时候会重新启动ApplicationMaster.
2. NodeManager (NM) —— 组长
NM是每个子节点上的资源和任务管理器,或者说是YARN的slave节点。一方面,它会定向通过心跳信息向RM汇报本节点上的资源使用情况和各个Container的运行情况;另一方面,它会接收并处理来自RM的命令和来自ApplicationMaster的Container启动和停止等各种请求。可以理解为类似部门组长的角色。
具体运作方式是,NM会启动RM分配给ApplicationMaster的Container以及代表ApplicationMaster的Container,并且会监视Container的运行情况。
在启动Container的时候,NM会设置一些必要的环境变量以及将Container运行所需的jar包、文件等从HDFS下载到本地,也就是所谓的资源本地化。当所有准备工作做好后,才会启动代表该Container的脚本将程序启动起来。启动起来后,NM会周期性的监视该Container运行占用的资源情况,若是超过了该Container所声明的资源量,则会kill掉该Container所代表的进程。
3. ApplicationMaster (AM) —— 项目经理
一个application对应一个AM,这个进程是在其中某一个节点运行的。主要为application本身向RM申请资源,对数据进行切分,与NM通信以启动或者停止任务,监控所有任务的运行情况,并在任务失败的情况下重新申请资源并重启任务(容错功能)。可以理解为类似组长管辖下的项目的项目经理角色。
由于NM执行和监控任务需要资源,而资源的申请需要通过AM与RM沟通,获取资源。换句话说,AM起着中间人的作用,这就是好比项目经理的其中一个职责,经常需要进行资源的申请。
以更专业的角度解释,AM负责向RM索要NM执行任务所需要的资源容器,更具体来讲是AM负责从Scheduler申请资源,以及跟踪这些资源的使用情况以及任务进度的监控。
4. Container —— 项目资源
Container是YARN对系统资源的抽象,同时它也是系统资源分配的基本单位,它封装了节点上的多维度资源,其中包括CPU、内存、磁盘、网络等。可以理解为类似项目所需要的资源,包括人员、资金、硬件等。
YARN会为每个任务分配一个Container,并且该任务只能使用该Container中描述的资源。注意,Contariner是一个动态的资源划分单位,资源是根据实际应用需求而变化的,比较类似Docker Container的概念。
三、MapReduce(分布式计算框架)
MapReduce是一种计算模型,用于处理大数据量的计算,其计算过程可以分为两个阶段(实质上是三个阶段),即Map和Reduce.
图2-3-1:MapReduce执行步骤
其中Map将输入的原始数据集转化为Key-Value(键-值对),拆分给不同节点并行进行指定的计算操作(例如排序、聚集),形成中间结果,这个计算操作的过程称为Map shuffle;Reduce则并行地对生成的中间结果中相同的Key的所有Value进行规约合并汇总处理后,输出新的Key-Value得到最终结果,这个处理相同Key的过程称为Reduce shuffle. 可以看出,在Map和Reduce中间,其实还有一个过程,就是对Map的输出进行整理并交给Reduce,这个过程就是shuffle. Map和Reduce操作需要我们自己定义相应的Map类和Reduce类,而shuffle则是系统自动帮我们实现的。
简单点理解,可以将Map看作是拆分数据集给不同的节点进行并行计算操作,将Reduce看作是整合每个节点的计算结果以汇总出最终结果(即Map负责分的计算,Reduce负责合的计算)。
图2-3-2:MapReduce工作原理
(1) JobTracker
JobTracker是master节点,一个集群中只有一个,负责管理所有作业、任务/作业的监控及错误处理等,并将任务分解成一系列任务,分派给TaskTracker.
(2) TaskTracker
TaskTracker是slave节点,负责运行Map Task和Reduce Task,并通过周期性的心跳与JobTracker交互,通知JobTracker其当前的健康状态,每一次心跳包含了可用的Map和Reduce任务数目、占用的数目以及运行中的任务详细信息。
TaskTracker和DataNode运行在一个机器上,从而使得每一台物理机器既是一个计算节点,同时也是一个存储节点,且每一个工作节点上只有一个TaskTracker.
2. Map Task和Reduce Task
在MapReduce计算框架中,一个application被划分成Map和Reduce两个计算阶段,它们分别由一个或者多个Map Task和Reduce Task组成。
(1) Map Task
每个Map Task处理输入数据集合中的一片数据(InputSplit),并将产生的若干个数据片段写到本地磁盘上。Map Task整体计算流程分为以下五个阶段(其中最后三个阶段就是上面提到的 Map shuffle):
图2-3-3:Map Task工作机制
(2) Reduce Task
Reduce Task从每个Map Task上远程拷贝相应的数据片段,经分组聚集和归约后,将结果写到HDFS上作为最终结果。Reduce Task整体计算流程也分为五个阶段(其中前面三个阶段就是上面提到的 Reduce shuffle):
图2-3-4:Reduce Task工作机制
03Hadoop 技术生态体系
广义上的Hadoop是指其整个技术生态体系,包括但不限于以下组件:
图3-1-1:Hadoop技术生态体系
这里选择几个比较重要的组件简单介绍一下,之后会作详细介绍:
一、HBase:分布式数据库
HBase是Hadoop的数据库,HBase是一个分布式的、面向列的开源非关系型数据库,它不同于一般的关系数据库,是一个适合非结构化数据存储的数据库。HBase利用Hadoop的HDFS作为其文件存储系统,利用ZooKeeper作为其协调工具,非常适合用来进行大数据的实时读写。
HBase表是一个稀疏多维表,表中的数据是未经解释的字符串,没有数据类型,每一行都有一个行键,表被分组成许多列族集合,列族支持动态扩展,可以很方便地添加一个列族或列,无须事先预定列的数量和类型,所有列都是以字符串的形式存储。
二、Hive:数据仓库工具
Hive是一个基于Hadoop的强大的数据仓库工具,它可以将结构化的数据文件映射为一张数据库表,并提供简单的SQL查询功能,可以将SQL语句转换为MapReduce任务进行运行。其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。
三、Kafka:分布式发布订阅消息系统
Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。对于像Hadoop一样的日志数据和离线分析系统,但又要求实时处理的限制,Kafka是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消息。
四、ZooKeeper:分布式协调服务
ZooKeeper作为一个高可用的分布式服务框架,主要用来解决分布式集群中应用系统的一致性问题,它可以减轻分布式应用程序所承担的协调任务,在Hadoop、HBase、Kafka等分布式系统中,ZooKeeper都是作为核心组件使用的。其典型应用场景有:实现HDFS的NameNode高可用HA;实现HBase的HMaster高可用HA. ZooKeeper的部署节点一般为奇数个。
五、Spark:内存分布式计算框架
Spark是一个可以将输出结果保存在内存中的微批处理分布式快速计算框架,可以批处理和交互式处理,支持多语言(Java, Python, Scala, R等),具有丰富的API. 其优势在于能同时实现离线和实时计算。
1. Spark SQL
Spark中处理结构化数据的一个模块,可以使用类SQL语句进行Spark编程。Spark SQL支持很多种结构化数据源,可以跳过复杂的读取过程,轻松从各种数据源读取到Row对象。这些数据源包括Hive表、JSON和Parquet文件等。
2. Spark Streaming
为数据流处理而生,类似的还有Storm(准实时). 其原理是把接收到的数据流分很多小的批次(batches),然后分批处理输出,称为微批处理(非真正的准实时),且其处理计算过程是在内存中完成的,比MapReduce需要利用HDFS磁盘空间的离线批处理效率提高很多:
图3-5-1:Spark Streaming
Spark Streaming的数据源可以是Kafka,Flume等,流处理过程中可以使用MLib库进行一些机器学习方面的建模等工作:
图3-5-2:Spark Streaming
3. Spark MLib
Spark中可以扩展的机器学习库,它由一系列的机器学习算法和实用程序组成。包括分类、回归、聚类、协同过滤等,还包含一些底层优化的方法。
4. Spark GraphX
Saprk的一个分布式图(属性图、社交图、有向图、无向图等)处理框架,主要用于进行以图为核心的计算和分布式计算。它是基于Spark平台提供对图计算和图挖掘简洁易用而丰富的接口,极大的方便了对分布式图处理的需求。
04Hadoop 部署模式
Hadoop的部署模式有四种:本地模式、伪分布式模式、完全分布式模式、HA完全分布式模式。
一、Hadoop各部署模式的特点
1. 本地模式(Local (Standalone) Mode)
又称独立模式、单机模式。在该模式下,无需运行任何守护进程,所有的程序都在一台机器的单个JVM上执行。本地模式下调试Hadoop集群的MapReduce程序非常方便,所以一般情况下,该模式适合在快速安装体验Hadoop、开发阶段进行本地调试使用。
2. 伪分布式模式(Pseudo-Distributed Mode)
伪分布式模式是在一台机器的各个进程上运行Hadoop的各个模块,各模块分开运行,但Hadoop程序的守护进程只运行在一台节点上,并不是真正的分布式。一般情况下,通常使用伪分布式模式来调试Hadoop分布式程序的代码,以及程序执行是否正确。伪分布式模式是完全分布式模式的一个特例。
3. 完全分布式模式(Fully-Distributed Mode)
在完全分布式模式下,Hadoop的守护进程分别运行在由多个主机节点搭建的服务器集群上,不同的节点担任不同的角色。一般情况下,在实际工作应用开发中,通常使用该模式部署构建企业级Hadoop系统。
4. 高可用完全分布式模式(Highly Available Fully-Distributed Mode)
HA高可用是Hadoop2.x才开始引入的机制,是为了解决Hadoop的单点故障问题。主要有两种部署方式,一种是NFS(Network File System)方式,另外一种是QJM(Quorum Journal Manager)方式。用得较多的是QJM方式,稳定性更好。实际操作中,生产环境的Hadoop集群搭建一般都会做HA部署。
二、Hadoop各部署模式的区别
Hadoop各种部署模式的区分依据主要是HDFS的NameNode、DataNode,YARN的ResourceManager、NodeManager、AppMaster等模块运行在几个JVM进程以及几个机器节点上:
部署模式 | 各个模块占用JVM进程数 | 各个模块运行机器节点数 |
---|---|---|
本地模式 | 1个 | 1个 |
伪分布式模式 | N个 | 1个 |
完全分布式模式 | N个 | N个 |
HA完全分布式模式 | N个 | N个 |
上一篇:Hadoop环境搭建及安装
下一篇:Hadoop部署配置及运行调试,敬请期待!