上一节:
Hadoop MapReduce
MapReduce的思想核心是“先分再合,分而治之 ”。 所谓“分而治之”就是把一个复杂的问题,按照一定的“分解”方法分为等价的规模较小的若干部分,然后逐个解决,分别找出各部分的结果,然后把各部分的结果组成整个问题的最终结果。 Map表示第一阶段,负责“拆分”:即把复杂的任务分解为若干个“简单的子任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算,彼此间几乎没有依赖关系。 Reduce表示第二阶段,负责“合并”:即对map阶段的结果进行全局汇总。
Hadoop MapReduce设计构思
如何对付大数据处理场景? 对相互间不具有计算依赖关系的大数据计算任务,实现并行最自然的办法就是采取MapReduce分而治之的策略。 首先Map阶段进行拆分,把大数据拆分成若干份小数据,多个程序同时并行计算产生中间结果;然后是Reduce聚合阶段,通过程序对并行的结果进行最终的汇总计算,得出最终的结果。 注意 :不可拆分的计算任务或相互间有依赖关系的数据无法进行并行计算。
构建抽象编程模型
MapReduce借鉴了函数式语言中的思想,用Map和Reduce两个函数提供了高层的并行编程抽象模型。 map: 对一组数据元素进行某种重复式的处理; reduce: 对Map的中间结果进行某种进一步的结果整理。 MapReduce中定义了如下的Map和Reduce两个抽象的编程接口,由用户去编程实现: map: (k1; v1) → (k2; v2) reduce: (k2; [v2]) → (k3; v3) 通过以上两个编程接口,可以看出MapReduce处理的数据类型是键值对。 统一架构、隐藏底层细节 MapReduce最大的亮点在于通过抽象模型和计算框架把需要做什么(what need to do)与具体怎么做(how to do)分开了,为程序员提供一个抽象和高层的编程接口和框架。 程序员仅需要关心其应用层的具体计算问题,仅需编写少量的处理应用本身计算问题的业务程序代码。至于如何具体完成这个并行计算任务所相关的诸多系统层细节被隐藏起来,交给计算框架去处理:从分布代码的执行,到大到数千小到单个节点集群的自动调度使用。
Hadoop MapReduce介绍
分布式计算概念
分布式计算是一种计算方法,和集中式计算是相对的。 随着计算技术的发展,有些应用需要非常巨大的计算能力才能完成,如果采用集中式计算,需要耗费相当长的时间来完成。 分布式计算将该应用分解成许多小的部分,分配给多台计算机进行处理。这样可以节约整体计算时间,大大提高计算效率。
Hadoop MapReduce是一个分布式计算框架 ,用于轻松编写分布式应用程序,这些应用程序以可靠,容错的方式并行处理大型硬件集群(数千个节点)上的大量数据(多TB数据集)。 MapReduce是一种面向海量数据处理的一种指导思想,也是一种用于对大规模数据进行分布式计算的编程模型。
MapReduce实例进程
一个完整的MapReduce程序在分布式运行时有三类
MRAppMaster:负责整个MR程序的过程调度及状态协调(只有一个) MapTask:负责map阶段的整个数据处理流程 ReduceTask:负责reduce阶段的整个数据处理流程
阶段组成
一个MapReduce编程模型中只能包含一个Map阶段和一个Reduce阶段,或者只有Map阶段; 不能有诸如多个map阶段、多个reduce阶段的情景出现; 如果用户的业务逻辑非常复杂,那就只能多个MapReduce程序串行运行。
MapReduce数据类型
整个MapReduce程序中,数据都是以key-value键值对的形式流转的; 在实际编程解决各种业务问题中,需要考虑每个阶段的输入输出key-value分别是什么; MapReduce内置了很多默认属性,比如排序、分组等,都和数据的key有关,所以说key-value的类型数据确定及其重要的
MapReduce特点
易于编程 良好的拓展性 高容错性 适合海量数据的离线处理
易于编程 Mapreduce框架提供了用于二次开发的接口;简单地实现一些接口,就可以完成一个分布式程序。任务计算交给计算框架去处理,将分布式程序部署到hadoop集群上运行,集群节点可以扩展到成百上千个等。 良好的扩展性 当计算机资源不能得到满足的时候,可以通过增加机器来扩展它的计算能力。基于MapReduce的分布式计算得特点可以随节点数目增长保持近似于线性的增长,这个特点是MapReduce处理海量数据的关键,通过将计算节点增至几百或者几千可以很容易地处理数百TB甚至PB级别的离线数据。 高容错性 Hadoop集群是分布式搭建和部署得,任何单一机器节点宕机了,它可以把上面的计算任务转移到另一个节点上运行,不影响整个作业任务得完成,过程完全是由Hadoop内部完成的。 适合海量数据的离线 处理 可以处理GB、TB和PB级别得数据量
MapReduce局限性
实时计算性能差 MapReduce主要应用于离线作业,无法作到秒级或者是亚秒级得数据响应。 不能进行流式计算 流式计算特点是数据是源源不断得计算,并且数据是动态的;而MapReduce作为一个离线计算框架,主要是针对静态数据集得,数据是不能动态变化得。
Hadoop MapReduce官方示例
MR程序内部执行繁琐,执行速度慢,效率很低,所以很少直接使用MR进行编程计算 但是,现在仍然有不少软件依赖于MR程序执行,所以了解并学习MR 内部的执行流程对于学习其他的计算引擎有非常大的支称作用 一个MR程序包括两部分:用户编写的代码(即map阶段和reduce阶段要做什么)+Hadoop自己实现的代码
官方示例 :
示例路径:/export/server/hadoop-3.3.0/share/hadoop/mapreduce/ 示例程序:hadoop-mapreduce-examples-3.3.0.jar MapReduce程序提交命令:hadoop jar hadoop-mapreduce-examples-3.3.0.jar 或者 yarn jar hadoop-mapreduce-examples-3.3.0.jar 最后程序会被提交到yarn集群上分布式执行
评估圆周率Π的值
Monte Carlo方法计算圆周率。
提交运行的三个参数说明 第一个参数:pi表示MapReduce程序执行圆周率计算任务; 第二个参数:用于指定map阶段运行的任务task次数,并发度; 第三个参数:用于指定每个map任务取样的个数。
jps
start-all . sh
cd / export/server/hadoop-3. 3. 0/share/hadoop/mapreduce/
ll
hadoop jar hadoop-mapreduce-examples-3. 3. 0. jar pi 2 50
需要关注的地方
wordcount单词词频统计
map阶段的核心:把输入的数据经过切割,全部标记1,因此输出就是<单词,1>。 shuffle阶段核心:经过MR程序内部自带默认的排序分组等功能,把key相同的单词会作为一组数据构成新的kv对 。 reduce阶段核心:处理shuffle完的一组数据,该组数据就是该单词所有的键值对。对所有的1进行累加求和,就是单词的总次数 提交运行的参数说明: 第一个参数:wordcount表示执行单词统计任务; 第二个参数:指定输入文件的路径; 第三个参数:指定输出结果的路径(该路径不能已存在);
出现错误后的参考链接
MapReduce整体执行流程图
Map阶段执行流程
第一阶段:把输入目录下文件按照一定的标准逐个进行逻辑切片,形成切片规划。 默认Split size = Block size(128M),每一个切片由一个MapTask处理。(getSplits) 第二阶段:对切片中的数据按照一定的规则读取解析返回对。 默认是按行读取数据。key是每一行的起始位置偏移量,value是本行的文本内容。(TextInputFormat) 第三阶段:调用Mapper类中的map方法处理数据。每读取解析出来的一个 ,调用一次map方法。 第四阶段:按照一定的规则对Map输出的键值对进行分区partition。 默认不分区,因为只有一个reducetask。分区的数量就是reducetask运行的数量。 第五阶段:Map输出数据写入内存缓冲区,达到比例溢出到磁盘上。溢出spill的时候根据key进行排序sort。 默认根据key字典序排序。 第六阶段:对所有溢出文件进行最终的merge合并,成为一个文件。
Reduce阶段执行流程
第一阶段:ReduceTask会主动从MapTask复制拉取属于需要自己处理的数据。 第二阶段:把拉取来数据,全部进行合并merge,即把分散的数据合并成一个大的数据。再对合并后的数据排序。 第三阶段是对排序后的键值对调用reduce方法。键相等的键值对调用一次reduce方法。最后把这些输出的键值对写入到HDFS文件中。
Shuffle机制
shuffle概念
Shuffle的本意是洗牌、混洗的意思,把一组有规则的数据尽量打乱成无规则的数据 。 而在MapReduce中,Shuffle更像是洗牌的逆过程,指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据 ,以便reduce端接收处理 。 一般把从Map产生输出开始到Reduce取得数据作为输入之前的过程称作shuffle。
Map端Shuffle
Collect阶段:将MapTask的结果收集输出到默认大小为100M的环形缓冲区,保存之前会对key进行分区的计算,默认Hash分区。 Spill阶段:当内存中的数据量达到一定的阀值的时候,就会将数据写入本地磁盘,在将数据写入磁盘之前需要对数据进行一次排序的操作,如果配置了combiner,还会将有相同分区号和key的数据进行排序。 Merge阶段:把所有溢出的临时文件进行一次合并操作,以确保一个MapTask最终只产生一个中间数据文件。
Reducer端shuffle
Copy阶段: ReduceTask启动Fetcher线程到已经完成MapTask的节点上复制一份属于自己的数据。 Merge阶段:在ReduceTask远程复制数据的同时,会在后台开启两个线程对内存到本地的数据文件进行合并操作。 Sort阶段:在对数据进行合并的同时,会进行排序操作,由于MapTask阶段已经对数据进行了局部的排序,ReduceTask只需保证Copy的数据的最终整体有效性即可。 shuffle机制弊端 Shuffle是MapReduce程序的核心与精髓,是MapReduce的灵魂所在。 Shuffle也是MapReduce被诟病最多的地方所在。MapReduce相比较于Spark、Flink计算引擎慢的原因,跟Shuffle机制有很大的关系。 Shuffle中频繁涉及到数据在内存、磁盘之间的多次往复。
Hadoop YARN
Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的Hadoop资源管理器。 YARN是一个通用资源管理系统和调度平台,可为上层应用提供统一的资源管理和调度。 它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
理解YARN是一个通用资源管理系统和调度平台
资源管理系统:集群的硬件资源,和程序运行相关,比如内存、CPU等。 调度平台:多个程序同时申请计算资源如何分配,调度的规则(算法)。 通用:不仅仅支持MapReduce程序,理论上支持各种计算程序。YARN不关心你干什么,只关心你要资源,在有的情况下给你,用完之后还我。
YARN概述
可以把Hadoop YARN理解为相当于一个分布式的操作系统平台,而MapReduce等计算程序则相当于运行于操作系统之上的应用程序,YARN为这些程序提供运算所需的资源(内存、CPU等)。 Hadoop能有今天这个地位,YARN可以说是功不可没。因为有了YARN ,更多计算框架可以接入到 HDFS中,而不单单是 MapReduce,正是因为YARN的包容,使得其他计算框架能专注于计算性能的提升。 HDFS可能不是最优秀的大数据存储系统,但却是应用最广泛的大数据存储系统, YARN功不可没。
Hadoop YARN架构、组件
YARN官方架构图
官方架构图中出现的概念
ResourceManager NodeManager ApplicationMaster(App Mstr) Client Container容器(资源的抽象)
YARN3大组件
ResourceManager(RM) YARN集群中的主角色,决定系统中所有应用程序之间资源分配的最终权限,即最终仲裁者。 接收用户的作业提交,并通过NM分配、管理各个机器上的计算资源。 NodeManager(NM) YARN中的从角色,一台机器上一个,负责管理本机器上的计算资源。 根据RM命令,启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况。 ApplicationMaster(AM) 用户提交的每个应用程序均包含一个AM。 应用程序内的“老大”,负责程序内部各阶段的资源申请,监督程序的执行情况。
程序提交YARN交互流程
核心交互流程
MR作业提交 Client–>RM 资源的申请 MrAppMaster–>RM MR作业状态汇报 Container(Map|Reduce Task)–>Container(MrAppMaster) 节点的状态汇报 NM–>RM
整体概述
当用户向 YARN 中提交一个应用程序后, YARN将分两个阶段运行该应用程序 。 第一个阶段是客户端申请资源启动运行本次程序的ApplicationMaster; 第二个阶段是由ApplicationMaster根据本次程序内部具体情况,为它申请资源,并监控它的整个运行过程,直到运行完成。
MR提交YARN交互流程
第1步、用户通过客户端向YARN中ResourceManager提交应用程序(比如hadoop jar提交MR程序); 第2步、ResourceManager为该应用程序分配第一个Container(容器),并与对应NodeManager通信,要求它在这个Container中启动这个应用程序的ApplicationMaster。 第3步、ApplicationMaster启动成功之后,首先向ResourceManager注册并保持通信,这样用户可以直接通过ResourceManage查看应用程序的运行状态(处理了百分之几); 第4步、AM为本次程序内部的各个Task任务向RM申请资源,并监控它的运行状态; 第5步、一旦 ApplicationMaster 申请到资源后,便与对应的 NodeManager 通信,要求它启动任务。 第6步、NodeManager 为任务设置好运行环境后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。 第7步、各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度,以让ApplicationMaster 随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。在应用程序运行过程中,用户可随时通过RPC 向 ApplicationMaster 查询应用程序的当前运行状态。 第8步、应用程序运行完成后,ApplicationMaster 向 ResourceManager 注销并关闭自己。
YARN资源调度器Scheduler
如何理解资源调度
在理想情况下,应用程序提出的请求将立即得到YARN批准。但是实际中,资源是有限的,并且在繁忙的群集上,应用程序通常将需要等待其某些请求得到满足。YARN调度程序的工作是根据一些定义的策略为应用程序分配资源。 在YARN中,负责给应用分配资源的就是Scheduler,它是ResourceManager的核心组件之一。Scheduler完全专用于调度作业,它无法跟踪应用程序的状态。 一般而言,调度是一个难题,并且没有一个“最佳”策略,为此,YARN提供了多种调度器和可配置的策略供选择
调度器策略
三种调度器 FIFO Scheduler(先进先出调度器)、Capacity Scheduler(容量调度器)、Fair Scheduler(公平调度器)。 Apache版本YARN默认使用Capacity Scheduler。 如果需要使用其他的调度器,可以在yarn-site.xml中的yarn.resourcemanager.scheduler.class进行配置。 FIFO Scheduler概述 FIFO Scheduler是Hadoop1.x中JobTracker原有的调度器实现,此调度器在YARN中保留了下来。 FIFO Scheduler是一个先进先出的思想,即先提交的应用先运行。调度工作不考虑优先级和范围,适用于负载较低的小规模集群。当使用大型共享集群时,它的效率较低且会导致一些问题。 FIFO Scheduler拥有一个控制全局的队列queue,默认queue名称为default,该调度器会获取当前集群上所有的资源信息作用于这个全局的queue。
优势: 无需配置、先到先得、易于执行 坏处: 任务的优先级不会变高,因此高优先级的作业需要等待 不适合共享集群
Capacity Scheduler概述
Capacity Scheduler容量调度是Apache Hadoop3.x默认调度策略。该策略允许多个组织共享整个集群资源,每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列,然后再为每个队列分配一定的集群资源,这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。 Capacity可以理解成一个个的资源队列,这个资源队列是用户自己去分配的。队列内部又可以垂直划分,这样一个组织内部的多个成员就可以共享这个队列资源了,在一个队列内部,资源的调度是采用的是先进先出(FIFO)策略。
Capacity Scheduler资源队列划分
Capacity Scheduler调度器以队列为单位划分资源。简单通俗点来说,就是一个个队列有独立的资源,队列的结构和资源是可以进行配置的。
Capacity Scheduler特性优势
层次化的队列设计(Hierarchical Queues) 层次化的管理,可以更容易、更合理分配和限制资源的使用。 容量保证(Capacity Guarantees) 每个队列上都可以设置一个资源的占比,保证每个队列都不会占用整个集群的资源。 安全(Security) 每个队列有严格的访问控制。用户只能向自己的队列里面提交任务,而且不能修改或者访问其他队列的任务。 弹性分配(Elasticity) 空闲的资源可以被分配给任何队列。 当多个队列出现争用的时候,则会按照权重比例进行平衡。
Fair Scheduler概述
Fair Scheduler叫做公平调度,提供了YARN应用程序公平地共享大型集群中资源的另一种方式。使所有应用在平均情况下随着时间的流逝可以获得相等的资源份额。 Fair Scheduler设计目标是为所有的应用分配公平的资源(对公平的定义通过参数来设置)。 公平调度可以在多个队列间工作,允许资源共享和抢占。
如何理解公平共享
有两个用户A和B,每个用户都有自己的队列。 A启动一个作业,由于没有B的需求,它分配了集群所有可用的资源。 然后B在A的作业仍在运行时启动了一个作业,经过一段时间,A,B各自作业都使用了一半的资源。 现在,如果B用户在其他作业仍在运行时开始第二个作业,它将与B的另一个作业共享其资源,因此B的每个作业将拥有资源的四分之一,而A的继续将拥有一半的资源。结果是资源在用户之间公平地共享。
Fair Scheduler特性优势
分层队列:队列可以按层次结构排列以划分资源,并可以配置权重以按特定比例共享集群。 基于用户或组的队列映射:可以根据提交任务的用户名或组来分配队列。如果任务指定了一个队列,则在该队列中 提交任务。 资源抢占:根据应用的配置,抢占和分配资源可以是友好的或是强制的。默认不启用资源抢占。