Hadoop分布式文件系统(三)

目录

一、Hadoop

1、MapReduce

1.1、理解MapReduce思想

1.2、分布式计算概念

1.3、MapReduce介绍

1.4、MapReduce特点

1.5、MapReduce局限性

1.6、MapReduce实例进程

1.7、MapReduce阶段组成

1.8、MapReduce数据类型

1.9、MapReduce官方示例

1.9.1、示例说明--圆周率PI评估

1.9.2、官方示例--WordCount单词统计

1.10、Map阶段执行过程

1.11、Reduce阶段执行过程

1.12、MapReduce--shuffle机制

2、YARN

2.1、YARN简介

2.2、YARN架构

2.3、YARN集群交互流程

2.4、YARN资源调度器Scheduler

2.4.1、FIFO Scheduler概述

2.4.2、Capacity Scheduler概述

2.4.3、Fair Scheduler概述


一、Hadoop

1、MapReduce

1.1、理解MapReduce思想

    MapReduce的思想核心是"先分再合,分而治之"。

    所谓"分而治之"就是把一个复杂的问题,按照一定的“分解”方法分为等价的规模较小的若干部分,然后逐个解决,分别找出各部分的结果,然后把各部分的结果组成整个问题的最终结果

    这种思想来源于日常生活与工作时的经验。即使是发布过论文实现分布式计算的谷歌也只是实现了这种思想,而不是自己原创。

Hadoop分布式文件系统(三)_第1张图片

    Map表示第一阶段,负责“拆分”:即把复杂的任务分解为若干个“简单的子任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算,彼此间几乎没有依赖关系。

    Reduce表示第二阶段,负责“合并”:即对map阶段的结果进行全局汇总。

    这两个阶段合起来正是MapReduce思想的体现。

    MapReduce处理的数据类型是键值对

实例:全国人口普查、停车场一共停多少辆车。

1.2、分布式计算概念

    分布式计算是一种计算方法,和集中式计算是相对的。

    随着计算技术的发展,有些应用需要非常巨大的计算能力才能完成,如果采用集中式计算,需要耗费相当长的时间来完成。

    分布式计算将该应用分解成许多小的部分,分配给多台计算机进行处理。这样可以节约整体计算时间,大大提高计算效率。

1.3、MapReduce介绍

    Hadoop MapReduce是一个分布式计算框架,用于轻松编写分布式应用程序,这些应用程序以可靠,容错的方式并行处理大型硬件集群(数千个节点)上的大量数据(多TB数据集)。

    MapReduce是一种面向海量数据处理的一种指导思想,也是一种用于对大规模数据进行分布式计算的编程模型。

1.4、MapReduce特点

易于编程

    MapReduce框架提供了用于二次开发的接口;简单地实现一些接口,就可以完成一个分布式程序。任务计算交给计算框架去处理,将分布式程序部署到hadoop集群上运行,集群节点可以扩展到成百上千个等。

良好的扩展性

    当计算机资源不能得到满足的时候,可以通过增加机器来扩展它的计算能力。基于MapReduce的分布式计算的特点可以随节点数目增长保持近似于线性的增长,这个特点是MapReduce处理海量数据的关键,通过将计算节点增至几百或者几千可以很容易地处理数百TB甚至PB级别的离线数据。

高容错性

    Hadoop集群是分布式搭建和部署的,任何单一机器节点宕机了,它可以把上面的计算任务转移到另一个节点上运行,不影响整个作业任务的完成,过程完全是由Hadoop内部完成的。

适合海量数据的离线处理

    可以处理GB、TB和PB级别的数据量

1.5、MapReduce局限性

    MapReduce虽然有很多的优势,也有相对的局限性,局限性不代表不能做,而是在有些场景下实现的效果比较差,并不适合用MapReduce来处理,主要表现在以下方面:

    1、实时计算性能差:MapReduce主要应用于离线作业,无法做到秒级或者亚秒级的数据响应。

    2、不能进行流式计算:流式计算特点是数据是源源不断的计算,并且数据是动态的;而MapReduce作为一个离线计算框架,主要是针对静态数据集的,数据是不能动态变化的。

1.6、MapReduce实例进程

    一个完整的MapReduce程序在分布式运行时有三类

    1、MRAppMaster:负责整个MR程序的过程调度及状态协调

    2、MapTask:负责map阶段的整个数据处理流程

    3、ReduceTask:负责reduce阶段的整个数据处理流程

1.7、MapReduce阶段组成

    一个MapReduce编程模型中只能包含一个Map阶段和一个Reduce阶段,或者只有Map阶段。

    不能有诸如多个map阶段、多个reduce阶段的情景出现。

    如果用户的业务逻辑非常复杂,那就只能多个MapReduce程序串行运行。

Hadoop分布式文件系统(三)_第2张图片

1.8、MapReduce数据类型

    注意:整个MapReduce程序中,数据都是以KV键值对的形式流转的。

    在实际编程解决各种业务问题中,需要考虑每个阶段的输入输出KV分别是什么。

    MapReduce内置了很多默认属性,比如排序、分组等,都和数据的K有关,所以说KV的类型数据确定及其重要的。

1.9、MapReduce官方示例

    一个最终完整版本的MR程序需要用户编写的代码和Hadoop自己实现的代码整合在一起才可以。

    其中用户负责map、reduce两个阶段的业务问题,Hadoop负责底层所有的技术问题。

    由于MapReduce计算引擎天生的弊端(慢),当下企业中直接使用率已经日薄西山了,所以在企业中工作很少涉及到MapReduce直接编程,但是某些软件的背后还依赖MapReduce引擎。

    可以通过官方提供的示例来感受MapReduce及其内部执行流程,因为后续的新的计算引擎比如Spark,当中就有MapReduce深深的影子存在。

1.9.1、示例说明--圆周率PI评估

    示例程序路径:/export/server/hadoop-3.3.6/share/hadoop/mapreduce/

    示例程序:hadoop-mapreduce-examples-3.3.6.jar

    MapReduce程序提交命令:[hadoop jar | yarn jar]  hadoop-mapreduce-examples-3.3.6.jar args...

    提交到哪里去?提交到YARN集群上分布式执行。

评估圆周率PI的值

    Monte Carlo方法

    假设正方形边长为1,圆半径也为1,那么1/4圆的面积为:\frac{1}{4}\pi r^{2}=\frac{\pi }{4}

    在正方形内随机撒点,分布于1/4圆内的数量假设为a,分布于圆外的数量为b,N则是所产生的总数:N=a+b

    那么数量a与N的比值应与1/4圆面积及正方形面积成正比,于是:\frac{\pi }{4}:1=a:N \Rightarrow \Rightarrow \pi =\frac{4a}{N}

Hadoop分布式文件系统(三)_第3张图片

    运行MapReduce程序评估一下圆周率的值,执行中可以去YARN页面上观察程序的执行的情况。

    第一个参数:pi表示MapReduce程序执行圆周率计算任务

    第二个参数:用于指定map阶段运行的任务task次数,并发度,这里是2。

    第三个参数:用于指定每个map任务取样的个数,这里是4。

hadoop jar hadoop-mapreduce-examples-3.3.6.jar pi 2 4

示例1:执行Hadoop官方自带的MapReduce案例,评估圆周率π的值

[root@node1 ~]# cd /export/server/hadoop-3.3.6/share/hadoop/mapreduce/
[root@node1 mapreduce]# ls
hadoop-mapreduce-client-app-3.3.6.jar         hadoop-mapreduce-client-jobclient-3.3.6.jar        hadoop-mapreduce-examples-3.3.6.jar
hadoop-mapreduce-client-common-3.3.6.jar      hadoop-mapreduce-client-jobclient-3.3.6-tests.jar  jdiff
hadoop-mapreduce-client-core-3.3.6.jar        hadoop-mapreduce-client-nativetask-3.3.6.jar       lib-examples
hadoop-mapreduce-client-hs-3.3.6.jar          hadoop-mapreduce-client-shuffle-3.3.6.jar          sources
hadoop-mapreduce-client-hs-plugins-3.3.6.jar  hadoop-mapreduce-client-uploader-3.3.6.jar
[root@node1 mapreduce]# hadoop jar hadoop-mapreduce-examples-3.3.6.jar pi 2 4
Number of Maps  = 2
Samples per Map = 4
Wrote input for Map #0
Wrote input for Map #1
Starting Job
2024-01-03 00:05:35,990 INFO client.DefaultNoHARMFailoverProxyProvider: Connecting to ResourceManager at node1/192.168.18.81:8032
2024-01-03 00:05:36,427 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding for path: /tmp/hadoop-yarn/staging/root/.staging/job_17042071157                                                                                        02_0001
2024-01-03 00:05:36,633 INFO input.FileInputFormat: Total input files to process : 2
2024-01-03 00:05:36,739 INFO mapreduce.JobSubmitter: number of splits:2
2024-01-03 00:05:36,889 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1704207115702_0001
2024-01-03 00:05:36,889 INFO mapreduce.JobSubmitter: Executing with tokens: []
2024-01-03 00:05:37,048 INFO conf.Configuration: resource-types.xml not found
2024-01-03 00:05:37,048 INFO resource.ResourceUtils: Unable to find 'resource-types.xml'.
2024-01-03 00:05:37,469 INFO impl.YarnClientImpl: Submitted application application_1704207115702_0001
2024-01-03 00:05:37,517 INFO mapreduce.Job: The url to track the job: http://node1:8088/proxy/application_1704207115702_0001/
2024-01-03 00:05:37,518 INFO mapreduce.Job: Running job: job_1704207115702_0001
2024-01-03 00:05:44,645 INFO mapreduce.Job: Job job_1704207115702_0001 running in uber mode : false
2024-01-03 00:05:44,647 INFO mapreduce.Job:  map 0% reduce 0%
2024-01-03 00:05:49,790 INFO mapreduce.Job:  map 100% reduce 0%
2024-01-03 00:05:56,882 INFO mapreduce.Job:  map 100% reduce 100%
2024-01-03 00:05:57,937 INFO mapreduce.Job: Job job_1704207115702_0001 completed successfully
2024-01-03 00:05:58,074 INFO mapreduce.Job: Counters: 54
        File System Counters
                FILE: Number of bytes read=50
                FILE: Number of bytes written=831342
                FILE: Number of read operations=0
                FILE: Number of large read operations=0
                FILE: Number of write operations=0
                HDFS: Number of bytes read=520
                HDFS: Number of bytes written=215
                HDFS: Number of read operations=13
                HDFS: Number of large read operations=0
                HDFS: Number of write operations=3
                HDFS: Number of bytes read erasure-coded=0
        Job Counters
                Launched map tasks=2
                Launched reduce tasks=1
                Data-local map tasks=2
                Total time spent by all maps in occupied slots (ms)=5594
                Total time spent by all reduces in occupied slots (ms)=3894
                Total time spent by all map tasks (ms)=5594
                Total time spent by all reduce tasks (ms)=3894
                Total vcore-milliseconds taken by all map tasks=5594
                Total vcore-milliseconds taken by all reduce tasks=3894
                Total megabyte-milliseconds taken by all map tasks=5728256
                Total megabyte-milliseconds taken by all reduce tasks=3987456
        Map-Reduce Framework
                Map input records=2
                Map output records=4
                Map output bytes=36
                Map output materialized bytes=56
                Input split bytes=284
                Combine input records=0
                Combine output records=0
                Reduce input groups=2
                Reduce shuffle bytes=56
                Reduce input records=4
                Reduce output records=0
                Spilled Records=8
                Shuffled Maps =2
                Failed Shuffles=0
                Merged Map outputs=2
                GC time elapsed (ms)=226
                CPU time spent (ms)=1710
                Physical memory (bytes) snapshot=887963648
                Virtual memory (bytes) snapshot=8386064384
                Total committed heap usage (bytes)=736624640
                Peak Map Physical memory (bytes)=314757120
                Peak Map Virtual memory (bytes)=2793766912
                Peak Reduce Physical memory (bytes)=260431872
                Peak Reduce Virtual memory (bytes)=2799820800
        Shuffle Errors
                BAD_ID=0
                CONNECTION=0
                IO_ERROR=0
                WRONG_LENGTH=0
                WRONG_MAP=0
                WRONG_REDUCE=0
        File Input Format Counters
                Bytes Read=236
        File Output Format Counters
                Bytes Written=97
Job Finished in 22.166 seconds
Estimated value of Pi is 3.50000000000000000000
[root@node1 mapreduce]#
1.9.2、官方示例--WordCount单词统计

    WordCount算是大数据计算领域经典的入门案例,相当于Hello World。

    虽然WordCount业务及其简单,但是希望能够通过案例感受背后MapReduce的执行流程和默认的行为机制,这才是关键。

Hadoop分布式文件系统(三)_第4张图片

WordCount编程实现思路

    map阶段的核心:把输入的数据经过切割,全部标记1,因此输出就是<单词,1>。

    shuffle阶段核心:经过MR程序内部自带默认的排序分组等功能,把key相同的单词会作为一组数据构成新的KV对。

    reduce阶段核心:处理shuffle完的一组数据,改组数据就是该单词所有的键值对。对所有的1进行累加求和,就是单词的总次数。

Hadoop分布式文件系统(三)_第5张图片

测试WordCount程序

    创建一个单词文件,对这个单词文件进行统计。

    第一个参数:wordcount表示执行单词统计任务。

    第二个参数:指定输入文件的路径。

    第三个参数:指定输出结果的路径(该路径不能已存在)。

示例2:文件单词统计案例

[root@node1 mapreduce]# hadoop fs -mkdir -p /wordcount/input
[root@node1 mapreduce]# echo hi lwz i m ok > hi.txt
[root@node1 mapreduce]# hadoop fs -put hi.txt /wordcount/input
[root@node1 mapreduce]# hadoop jar hadoop-mapreduce-examples-3.3.6.jar wordcount /wordcount/input /wordcount/output
2024-01-03 00:19:26,657 INFO client.DefaultNoHARMFailoverProxyProvider: Connecting to ResourceManager at node1/192.168.18.81:8032
2024-01-03 00:19:27,210 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding for path: /tmp/hadoop-yarn/staging/root/.staging/job_1704207115702_0002
2024-01-03 00:19:27,547 INFO input.FileInputFormat: Total input files to process : 1
2024-01-03 00:19:27,680 INFO mapreduce.JobSubmitter: number of splits:1
2024-01-03 00:19:27,852 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1704207115702_0002
2024-01-03 00:19:27,852 INFO mapreduce.JobSubmitter: Executing with tokens: []
2024-01-03 00:19:28,010 INFO conf.Configuration: resource-types.xml not found
2024-01-03 00:19:28,010 INFO resource.ResourceUtils: Unable to find 'resource-types.xml'.
2024-01-03 00:19:28,072 INFO impl.YarnClientImpl: Submitted application application_1704207115702_0002
2024-01-03 00:19:28,106 INFO mapreduce.Job: The url to track the job: http://node1:8088/proxy/application_1704207115702_0002/
2024-01-03 00:19:28,107 INFO mapreduce.Job: Running job: job_1704207115702_0002
2024-01-03 00:19:35,223 INFO mapreduce.Job: Job job_1704207115702_0002 running in uber mode : false
2024-01-03 00:19:35,225 INFO mapreduce.Job:  map 0% reduce 0%
2024-01-03 00:19:40,342 INFO mapreduce.Job:  map 100% reduce 0%
2024-01-03 00:19:45,397 INFO mapreduce.Job:  map 100% reduce 100%
2024-01-03 00:19:45,415 INFO mapreduce.Job: Job job_1704207115702_0002 completed successfully
2024-01-03 00:19:45,557 INFO mapreduce.Job: Counters: 54
        File System Counters
                FILE: Number of bytes read=50
                FILE: Number of bytes written=553581
                FILE: Number of read operations=0
                FILE: Number of large read operations=0
                FILE: Number of write operations=0
                HDFS: Number of bytes read=119
                HDFS: Number of bytes written=24
                HDFS: Number of read operations=8
                HDFS: Number of large read operations=0
                HDFS: Number of write operations=2
                HDFS: Number of bytes read erasure-coded=0
        Job Counters
                Launched map tasks=1
                Launched reduce tasks=1
                Data-local map tasks=1
                Total time spent by all maps in occupied slots (ms)=2563
                Total time spent by all reduces in occupied slots (ms)=2582
                Total time spent by all map tasks (ms)=2563
                Total time spent by all reduce tasks (ms)=2582
                Total vcore-milliseconds taken by all map tasks=2563
                Total vcore-milliseconds taken by all reduce tasks=2582
                Total megabyte-milliseconds taken by all map tasks=2624512
                Total megabyte-milliseconds taken by all reduce tasks=2643968
        Map-Reduce Framework
                Map input records=1
                Map output records=5
                Map output bytes=34
                Map output materialized bytes=50
                Input split bytes=105
                Combine input records=5
                Combine output records=5
                Reduce input groups=5
                Reduce shuffle bytes=50
                Reduce input records=5
                Reduce output records=5
                Spilled Records=10
                Shuffled Maps =1
                Failed Shuffles=0
                Merged Map outputs=1
                GC time elapsed (ms)=118
                CPU time spent (ms)=1350
                Physical memory (bytes) snapshot=532602880
                Virtual memory (bytes) snapshot=5595779072
                Total committed heap usage (bytes)=392167424
                Peak Map Physical memory (bytes)=266100736
                Peak Map Virtual memory (bytes)=2794917888
                Peak Reduce Physical memory (bytes)=266502144
                Peak Reduce Virtual memory (bytes)=2800861184
        Shuffle Errors
                BAD_ID=0
                CONNECTION=0
                IO_ERROR=0
                WRONG_LENGTH=0
                WRONG_MAP=0
                WRONG_REDUCE=0
        File Input Format Counters
                Bytes Read=14
        File Output Format Counters
                Bytes Written=24
[root@node1 mapreduce]#

1.10、Map阶段执行过程

MapReduce整体执行流程图

Hadoop分布式文件系统(三)_第6张图片

Map阶段执行过程

    第一阶段:把输入目录下文件按照一定的标准逐个进行逻辑切片,形成切片规划。

默认Split size =Block size(128M),每一个切片由一个MapTask处理。(getSplits)

    第二阶段:对切片中的数据按照一定的规则读取解析返回对。

默认是按行读取数据。key是每一行的起始位置偏移量,value是本行的文本内容。(TextInputFormat)

    第三阶段:调用Mapper类中的map方法处理数据

每读取解析出来的一个,调用一次map方法。

    第四阶段:按照一定的规则对Map输出的键值对进行分区partition。默认不分区,因为只有一个reducetask。分区的数量就是reducetask进行的数量。

    第五阶段:Map输出数据写入内存缓冲区,达到比例溢出到磁盘上。溢出spill的时候根据key进行排序sort。默认根据key字典序排序。

    第六阶段:对所有溢出文件进行最终的merge合并,成为一个文件。

Hadoop分布式文件系统(三)_第7张图片

1.11、Reduce阶段执行过程

    第一阶段:ReduceTask会主动从MapTask复制拉取属于需要自己处理的数据。

    第二阶段:把拉取来数据,全部进行合并merge,即把分散的数据合并成一个大的数据。再对合并后的数据排序

    第三阶段:是对排序后的键值对调用reduce方法键相等的键值对调用一次reduce方法。最后把这些输出的键值对写入到HDFS文件中。

Hadoop分布式文件系统(三)_第8张图片

1.12、MapReduce--shuffle机制

shuffle概念

    Shuffle的本意是洗牌、混洗的意思,把一组有规则的数据尽量打乱成无规则的数据。

    而在MapReduce中,Shuffle更像是洗牌的逆过程,指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据,以便reduce端接收处理。

    一般把从Map产生输出开始到Reduce取得数据作为输入之前的过程称作Shuffle。

Hadoop分布式文件系统(三)_第9张图片

Map端Shuffle

    Collect阶段:将MapTask的结果手机输出到默认大小为100M的环形缓冲区,保存之前会对key进行分区的计算,默认Hash分区。

    Spill阶段:当内存中的数据量达到一定的阈值的时候就会将数据写入本地磁盘,在将数据写入磁盘之前需要对数据进行一次排序的操作,如果配置了combiner,还会将有相同分区号和key的数据进行排序。

    Merge阶段:把所有溢出的临时文件进行一次合并操作,以确保一个MapTask最终只产生一个中间数据文件。

Reduce端Shuffle

    Copy阶段:ReduceTask启动Fetcher线程到已经完成MapTask的节点上复制一份属于自己的数据。

    Merge阶段:在ReduceTask远程复制数据的同时,会在后台开启两个线程对内存到本地的数据文件进行合并操作。

    Sort阶段:在对数据进行合并的同时,会进行排序操作,由于MapTask阶段已经对数据进行了局部的排序,ReduceTask只需保证Copy的数据的最终整体有效性即可。

Shuffle机制弊端

    Shuffle是MapReduce程序的核心与精髓,是MapReduce的灵魂所在。

    Shuffle也是MapReduce被诟病最多的地方所在。MapReduce相比较于Spark、Flink计算引擎慢的原因,跟Shuffle机制有很大的关系。

    Shuffle中频繁涉及到数据在内存、磁盘之间的多次往复。

2、YARN

2.1、YARN简介

    Apache Hadoop YARN(Yet Another Resource Negotiator,另一种资源协调者)是一种新的Hadoop资源管理器。

    YARN是一个通用资源管理系统调度平台,可为上层应用提供统一的资源管理和调度,

    它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

Hadoop分布式文件系统(三)_第10张图片

    资源管理系统:集群的硬件资源,和程序运行相关,比如内存、CPU等。

    调度平台:多个程序同时申请计算资源如何分配,调度的规则(算法)。

    通用:不仅仅支持MapReduce程序,理论上支持各种计算程序。YARN不关心你干什么,只关心你要资源,在有的情况下给你,用完之后还我。

    可以把Hadoop YARN理解为相当于一个分布式的操作系统平台,而MapReduce等计算程序则相当于操作系统之上的应用程序,YARN为这些程序提供运算所需的资源(内存、CPU等)

    Hadoop能有今天这个地位,YARN可以说是功不可没的。因为有了YARN,更多计算框架可以接入到HDFS中,而不单单是MapReduce,正是因为YARN的包容,使得其他计算框架能专注于计算性能的提升

    HDFS可能不是最优秀的大数据存储系统,但却是应用最广泛的大数据存储系统,YARN功不可没。

2.2、YARN架构

YARN官方架构图

Hadoop分布式文件系统(三)_第11张图片

YARN三大组件

1、ResourceManager(RM):集群物理层面

    YARN集群中的主角色,决定系统中所有应用程序之间资源分配的最终权限,即最终仲裁者。接收用户的作业提交,并通过NM分配、管理各个机器上的计算资源。

2、NodeManager(NM):集群物理层面

    YARN中的从角色,一台机器上一个,负责管理本机器上的计算资源。根据RM命令,启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况。

3、ApplicationMaster(APP Mstr)(AM):APP层面

    用户提交的每个应用程序均包含一个AM。应用程序内的“老大”,负责程序内部各阶段的资源申请,监督程序的执行情况。

Client

Container容器(资源抽象)

2.3、YARN集群交互流程

核心交互流程

1、MR作业提交:Client-->RM

2、资源的申请:MRAppMaster-->RM

3、MR作业状态汇报:Container(Map|Reduce Task)-->Container(MRAppMaster)

4、节点的状态汇报:NM-->RM

整体概述

    当用户向YARN中提交一个应用程序后,YARN将分两个阶段运行该应用程序。

        第一个阶段是客户端申请资源启动运行本次程序的ApplicationMaster。

        第二个阶段是由ApplicationMaster根据本次程序内部具体情况,为它申请资源,并监控它的整个运行过程,直到运行完成。

Hadoop分布式文件系统(三)_第12张图片

MR提交YARN交互流程

    第1步、用户通过客户端向YARN中ResourceManager提交应用程序(比如hadoop jar提交MR程序)。

    第2步、ResourceManager为该应用程序分布第一个Container(容器),并与对应的NodeManager通信,要求它在这个Container中启动这个应用程序的ApplicationMaster。

    第3步、ApplicationMaster启动成功之后,首先向ResourceManager注册并保持通信,这样用户可以直接通过ResourceManager查看应用程序的运行状态(处理了百分之几)。

    第4步、AM为本次程序内部的各个Task任务向RM申请资源,并监控它的运行状态。

    第5步、一旦ApplicationMaster申请到资源后,便与对应的NodeManager通信,要求它启动任务。

    第6步、NodeManager为任务设置好运行环境后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。

    第7步、各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度,以让ApplicationMaster随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。在应用程序运行过程中,用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

    第8步、应用程序运行完成后,ApplicationMaster向ResourceManager注销并关闭自己

2.4、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进行配置。

Hadoop分布式文件系统(三)_第13张图片

2.4.1、FIFO Scheduler概述

    FIFO Scheduler是Hadoop1.x中JobTracker原有的调度器实现,此调度器在YARN中保留了下来。

    FIFO Scheduler是一个先进先出的思想,即先提交的应用先运行。调度工作不考虑优先级和范围,适用于负载较低的小规模集群。当使用大型共享集群时,它的效率较低且会导致一些问题。

    FIFO Scheduler拥有一个控制全局的队列queue,默认queue名称为default,该调度器会获取当前集群上所有资源信息作用这个全局的queue。

FIFO Scheduler优缺点:

    优点:无需配置,先到先得,易于执行

    缺点:任务的优先级不会变高,因此高优先级的作业需要等待,不适合共享集群

2.4.2、Capacity Scheduler概述

    Capacity Scheduler容量调度是Apache Hadoop3.x默认调度策略。该策略允许多个组织共享整个集群资源,每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列,然后再为每个队列分配一定的集群资源,这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。

    Capacity可以理解成一个个的资源队列,这个资源队列是用户自己去分配的。队列内部又可以垂直划分,这样一个组织的多个成员就可以共享这个队列资源了,在一个队列内部,资源的调度采用的是先进先出(FIFO)策略。

Capacity Scheduler资源队列划分

    Capacity Scheduler调度器以队列为单位划分资源。简单通俗点来说,就是一个个队列有独立的资源,队列的结构和资源是可以进行配置的。

Capacity Scheduler特性优势

1、层次化的队列设计(Hierarchical Queues)

    层次化的管理,可以更容易、更合理分配和限制资源的使用。

2、容量保证(Capacity Guarantees)

    每个队列上都可以设置一个资源的占比,保证每个队列都不会占用整个集群的资源。

3、安全(Security)

    每个队列有严格的访问控制。用户只能向自己的队列里面提交任务,而且不能修改或者访问其他队列的任务。

4、弹性分配(Elasticity)

    空闲的资源可以被分配给任何队列。

    当多个队列出现争用的时候,则会按照权重比例进行平衡。

2.4.3、Fair Scheduler概述

    Fair Scheduler叫做公平调度,提供了YARN应用程序公平地共享大型集群中资源的另一种方式。使所有应用在平均情况下随着时间的流逝可以获得相等的资源份额。

    Fair Scheduler设计目标是为所有的应用分配公平的资源(对公平的定义通过参数来设置)。

    公平调度可以在多个队列间工作,允许资源共享和抢占。

Fair Scheduler特性优势

    分层队列:队列可以按层次结构排列以划分资源,并可以配置权重以按特定比例共享集群。

    基于用户或组的队列映射:可以根据提交任务的用户名或组来分配队列。如果任务指定了一个队列,则在该队列中提交任务。

    资源抢占:根据应用的配置,抢占和分配资源可以是友好的或是强制的。默认不启用资源抢占。

    保证最小配额:可以设置队列最小资源,允许将保证的最小份额分配给队列,保证用户可以启动任务。当队列不能满足最小资源时,可以从其它队列抢占。当队列资源使用不完时,可以给其它队列使用。这对于确保某些用户、组或生产应用始终获得足够的资源。

    允许资源共享:即当一个应用运行时,如果其它队列没有任务执行,则可以使用其它队列,当其它队列有应用需要资源时再将占用的队列释放出来。所有的应用都从资源队列中分配资源。

    默认不限制每个队列和用户可以同时运行应用的数量。可以配置来限制队列和用户并行执行的应用数量。限制并行执行应用数量不会导致任务提交失败,超出的应用会在队列中等待。

Hadoop分布式文件系统(二)

再小的努力,乘以365都很明显!
一个程序员最重要的能力是:写出高质量的代码!!
有道无术,术尚可求也,有术无道,止于术。
无论你是年轻还是年长,所有程序员都需要记住:时刻努力学习新技术,否则就会被时代抛弃!

你可能感兴趣的:(大数据,hadoop,大数据,分布式)