我的架构梦：（五十九）ApacheHadoop架构与原理

一、Hadoop的重要组成

Hadoop&＃61;HDFS(分布式文件系统)&＃43;MapReduce(分布式计算框架)&＃43;Yarn(资源协调框架)&＃43;Common模块

1、Hadoop HDFS:(Hadoop Distribute File System )一个高可靠、高吞吐量的分布式文件系统

比如:100T数据存储&＃xff0c;“分而治之”

分:拆分–》数据切割&＃xff0c;100T数据拆分为10G一个数据块由一个电脑节点存储这个数据块。

数据切割、制作副本、分散储存

图中涉及到几个角色

NameNode(nn): 存储文件的元数据&＃xff0c;比如文件名、文件目录结构、文件属性(生成时间、副
本数、文件权限)&＃xff0c;以及每个文件的块列表和块所在的DataNode等。

SecondaryNameNode(2nn): 辅助NameNode更好的工作&＃xff0c;用来监控HDFS状态的辅助后台
程序&＃xff0c;每隔一段时间获取HDFS元数据快照。

DataNode(dn): 在本地文件系统存储文件块数据&＃xff0c;以及块数据的校验。

注意:NN,2NN,DN这些既是角色名称&＃xff0c;进程名称&＃xff0c;代指电脑节点名称&＃xff01;&＃xff01;&＃xff01;

2、Hadoop MapReduce:一个分布式的离线并行计算框架

拆解任务、分散处理、汇整结果

MapReduce计算 &＃61; Map阶段 &＃43; Reduce阶段

Map阶段就是“分”的阶段&＃xff0c;并行处理输入数据;

Reduce阶段就是“合”的阶段&＃xff0c;对Map阶段结果进行汇总;

3、Hadoop YARN:作业调度与集群资源管理的框架

计算资源协调

Yarn中有如下几个主要角色&＃xff0c;同样&＃xff0c;既是角色名、也是进程名&＃xff0c;也指代所在计算机节点名称。

ResourceManager(rm): 处理客户端请求、启动/监控ApplicationMaster、监控
NodeManager、资源分配与调度。

NodeManager(nm): 单个节点上的资源管理、处理来自ResourceManager的命令、处理来自
ApplicationMaster的命令。

ApplicationMaster(am): 数据切分、为应用程序申请资源&＃xff0c;并分配给内部任务、任务监控与容错。

Container: 对任务运行环境的抽象&＃xff0c;封装了CPU、内存等多维资源以及环境变量、启动命令等任务运行相关的信息。

ResourceManager是老大&＃xff0c;NodeManager是小弟&＃xff0c;ApplicationMaster是计算任务专员。

4、Hadoop Common:支持其他模块的工具模块(Configuration、RPC、序列化机制、日志操作)

二、HDFS分布式文件系统

1、HDFS 简介

HDFS (全称:Hadoop Distribute File System&＃xff0c;Hadoop 分布式文件系统)是 Hadoop 核心组成&＃xff0c;是分布式存储服务。

分布式文件系统横跨多台计算机&＃xff0c;在大数据时代有着广泛的应用前景&＃xff0c;它们为存储和处理超大规模数据提供所需的扩展能力。

HDFS是分布式文件系统中的一种。

2、HDFS的重要概念

HDFS 通过统一的命名空间目录树来定位文件; 另外&＃xff0c;它是分布式的&＃xff0c;由很多服务器联合起来实现其功能&＃xff0c;集群中的服务器有各自的角色(分布式本质是拆分&＃xff0c;各司其职)。

2.1 典型的 Master/Slave 架构

• HDFS 的架构是典型的 Master/Slave 结构。
• HDFS集群往往是一个NameNode(HA架构会有两个NameNode,联邦机制)&＃43;多个DataNode组成;
• NameNode是集群的主节点&＃xff0c;DataNode是集群的从节点。

2.2 分块存储(block机制)

• HDFS 中的文件在物理上是分块存储(block)的&＃xff0c;块的大小可以通过配置参数来规定;
• Hadoop2.x版本中默认的block大小是128M;

2.3 命名空间(NameSpace)

• HDFS 支持传统的层次型文件组织结构。用户或者应用程序可以创建目录&＃xff0c;然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动 或重命名文件。

• Namenode 负责维护文件系统的名字空间&＃xff0c;任何对文件系统名字空间或属性的修改都将被 Namenode 记录下来。

• HDFS提供给客户单一个抽象目录树&＃xff0c;访问形式:hdfs://namenode的hostname:port/test/inputhdfs://linux121:9000/test/input

2.4 NameNode元数据管理

• 我们把目录结构及文件分块位置信息叫做元数据。

• NameNode的元数据记录每一个文件所对应的block信息(block的id,以及所在的DataNode节点的信息)

2.5 DataNode数据存储

• 文件的各个 block 的具体存储管理由 DataNode 节点承担。

• 一个block会有多个DataNode来存储&＃xff0c;DataNode会定时向NameNode来汇报自己持有的block信息。

2.6 副本机制

• 为了容错&＃xff0c;文件的所有 block 都会有副本。每个文件的 block 大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定&＃xff0c;也可以在之后改变。 副本数量默认是3个。

2.7 一次写入&＃xff0c;多次读出

• HDFS 是设计成适应一次写入&＃xff0c;多次读出的场景&＃xff0c;且不支持文件的随机修改。 (支持追加写入&＃xff0c; 不只支持随机更新)

• 正因为如此&＃xff0c;HDFS 适合用来做大数据分析的底层存储服务&＃xff0c;并不适合用来做网盘等应用(修改不方便&＃xff0c;延迟大&＃xff0c;网络开销大&＃xff0c;成本太高)

3、HDFS 架构

3.1 NameNode(nn): Hdfs集群的管理者&＃xff0c;Master

• 维护管理Hdfs的名称空间(NameSpace)
• 维护副本策略
• 记录文件块(Block)的映射信息
• 负责处理客户端读写请求

3.2 DataNode:NameNode下达命令&＃xff0c;DataNode执行实际操作&＃xff0c;Slave节点。

• 保存实际的数据块
• 负责数据块的读写

3.3 Client:客户端

• 上传文件到HDFS的时候&＃xff0c;Client负责将文件切分成Block,然后进行上传
• 请求NameNode交互&＃xff0c;获取文件的位置信息
• 读取或写入文件&＃xff0c;与DataNode交互
• Client可以使用一些命令来管理HDFS或者访问HDFS

4、HDFS读写解析

4.1 HDFS读数据流程

• 客户端通过Distributed FileSystem向NameNode请求下载文件&＃xff0c;NameNode通过查询元数据&＃xff0c; 找到文件块所在的DataNode地址。
• 挑选一台DataNode(就近原则&＃xff0c;然后随机)服务器&＃xff0c;请求读取数据。
• DataNode开始传输数据给客户端(从磁盘里面读取数据输入流&＃xff0c;以Packet为单位来做校验)。
• 客户端以Packet为单位接收&＃xff0c;先在本地缓存&＃xff0c;然后写入目标文件。

4.2 HDFS写数据流程

• 客户端通过Distributed FileSystem模块向NameNode请求上传文件&＃xff0c;NameNode检查目标文件是否已存在&＃xff0c;父目录是否存在。
• NameNode返回是否可以上传。
• 客户端请求第一个 Block上传到哪几个DataNode服务器上。
• NameNode返回3个DataNode节点&＃xff0c;分别为dn1、dn2、dn3。
• 客户端通过FSDataOutputStream模块请求dn1上传数据&＃xff0c;dn1收到请求会继续调用dn2&＃xff0c;然后dn2调用dn3&＃xff0c;将这个通信管道建立完成。
• dn1、dn2、dn3逐级应答客户端。
• 客户端开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存)&＃xff0c;以Packet为单位&＃xff0c;dn1收到一个Packet就会传给dn2&＃xff0c;dn2传给dn3;dn1每传一个packet会放入一个确认队列等待确认。
• 当一个Block传输完成之后&＃xff0c;客户端再次请求NameNode上传第二个Block的服务器。(重复执行3-7步)。

4.3 验证Packet代码

&＃64;Test
public void testUploadPacket() throws IOException {// 1.准备读取本地文件的输入流final FileInputStream in &＃61; new FileInputStream(new File("d:/riemann.txt"));// 2.准备好写出数据到hdfs的输出流final FSDataOutputStream out &＃61; fs.create(new Path("/riemann.txt"), new Progressable() {public void progress() {// 这个progress方法就是每传输64KB(packet)就会执行一次&＃xff0c;System.out.println("&");}});// 3.实现流拷贝IOUtils.copyBytes(in, out, configuration); // 默认关闭流选项是true&＃xff0c;所以会自动关闭// 4.关流 可以再次关闭也可以不关了
}


5、HDFS元数据管理机制

问题1:NameNode如何管理和存储元数据?

计算机中存储数据两种:内存或者是磁盘

元数据存储磁盘:存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应&＃xff0c;但是安全性高。

元数据存储内存:元数据存放内存&＃xff0c;可以高效的查询以及快速响应客户端的查询请求&＃xff0c;数据保存在内 存&＃xff0c;如果断点&＃xff0c;内存中的数据全部丢失。

解决方案:内存&＃43;磁盘; NameNode内存&＃43;FsImage的文件(磁盘)

新问题:磁盘和内存中元数据如何划分?

两个数据一模一样&＃xff0c;还是两个数据合并到一起才是一份完整的数据呢?

一模一样:client如果对元数据进行增删改操作&＃xff0c;需要保证两个数据的一致性。FsImage文件操作起来 效率也不高。

两个合并&＃61;完整数据:NameNode引入了一个edits文件(日志文件:只能追加写入)edits文件记录的 是client的增删改操作&＃xff0c;

不再选择让NameNode把数据dump出来形成FsImage文件(这种操作是比较消耗资源)。

元数据管理流程图

5.1 第一阶段:NameNode启动

• 第一次启动NameNode格式化后&＃xff0c;创建Fsimage和Edits文件。如果不是第一次启动&＃xff0c;直接加 载编辑日志和镜像文件到内存。
• 客户端对元数据进行增删改的请求。
• NameNode记录操作日志&＃xff0c;更新滚动日志。
• NameNode在内存中对数据进行增删改。

5.2 第二阶段:Secondary NameNode工作

• Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否执 行检查点操作结果。
• Secondary NameNode请求执行CheckPoint。
• NameNode滚动正在写的Edits日志。
• 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
• Secondary NameNode加载编辑日志和镜像文件到内存&＃xff0c;并合并。
• 生成新的镜像文件fsimage.chkpoint。
• 拷贝fsimage.chkpoint到NameNode。
• NameNode将fsimage.chkpoint重新命名成fsimage。

三、MapReduce编程框架

1、MapReduce思想

MapReduce思想在生活中处处可见。我们或多或少都曾接触过这种思想。MapReduce的思想核心是分 而治之。

充分利用了并行处理的优势。

即使是发布过论文实现分布式计算的谷歌也只是实现了这种思想&＃xff0c;而不是自己原创。

MapReduce任务过程是分为两个处理阶段:

• Map阶段:Map阶段的主要作用是“分”&＃xff0c;即把复杂的任务分解为若干个“简单的任务”来并行处理。 Map阶段的这些任务可以并行计算&＃xff0c;彼此间没有依赖关系。
• Reduce阶段:Reduce阶段的主要作用是“合”&＃xff0c;即对map阶段的结果进行全局汇总。

再次理解MapReduce的思想

2、MapReduce原理分析

2.1 MapTask运行机制详解

MapTask流程

详细步骤:

• 首先&＃xff0c;读取数据组件InputFormat(默认TextInputFormat)会通过getSplits方法对输入目录中文 件进行逻辑切片规划得到splits&＃xff0c;有多少个split就对应启动多少个MapTask。split与block的对应关系默认是一对一。
• 将输入文件切分为splits之后&＃xff0c;由RecordReader对象(默认LineRecordReader)进行读取&＃xff0c;以\n 作为分隔符&＃xff0c;读取一行数据&＃xff0c;返回。Key表示每行首字符偏移值&＃xff0c;value表示这一行 文本内容。
• 读取split返回&＃xff0c;进入用户自己继承的Mapper类中&＃xff0c;执行用户重写的map函数。 RecordReader读取一行这里调用一次。
• map逻辑完之后&＃xff0c;将map的每条结果通过context.write进行collect数据收集。在collect中&＃xff0c;会先 对其进行分区处理&＃xff0c;默认使用HashPartitioner。
  MapReduce提供Partitioner接口&＃xff0c;它的作用就是根据key或value及reduce的数量来决定当前的这对 输出数据最终应该交由哪个reduce task处理。默认对key hash后再以reduce task数量取模。默认的 取模方式只是为了平均reduce的处理能力&＃xff0c;如果用户自己对Partitioner有需求&＃xff0c;可以订制并设置到 job上。
• 接下来&＃xff0c;会将数据写入内存&＃xff0c;内存中这片区域叫做环形缓冲区&＃xff0c;缓冲区的作用是批量收集map结 果&＃xff0c;减少磁盘IO的影响。我们的key/value对以及Partition的结果都会被写入缓冲区。当然写入之 前&＃xff0c;key与value值都会被序列化成字节数组。
  a. 环形缓冲区其实是一个数组&＃xff0c;数组中存放着key、value的序列化数据和key、value的元数据信 息&＃xff0c;包括partition、key的起始位置、value的起始位置以及value的长度。环形结构是一个抽象概念。
  b. 缓冲区是有大小限制&＃xff0c;默认是100MB。当map task的输出结果很多时&＃xff0c;就可能会撑爆内存&＃xff0c;所以 需要在一定条件下将缓冲区中的数据临时写入磁盘&＃xff0c;然后重新利用这块缓冲区。这个从内存往磁盘 写数据的过程被称为Spill&＃xff0c;中文可译为溢写。这个溢写是由单独线程来完成&＃xff0c;不影响往缓冲区写 map结果的线程。溢写线程启动时不应该阻止map的结果输出&＃xff0c;所以整个缓冲区有个溢写的比例 spill.percent。这个比例默认是0.8&＃xff0c;也就是当缓冲区的数据已经达到阈值(buffer size * spill percent &＃61; 100MB * 0.8 &＃61; 80MB)&＃xff0c;溢写线程启动&＃xff0c;锁定这80MB的内存&＃xff0c;执行溢写过程。Map task的输出结果还可以往剩下的20MB内存中写&＃xff0c;互不影响。
• 当溢写线程启动后&＃xff0c;需要对这80MB空间内的key做排序(Sort)。排序是MapReduce模型默认的行为!
  a. 如果job设置过Combiner&＃xff0c;那么现在就是使用Combiner的时候了。将有相同key的key/value对的 value加起来&＃xff0c;减少溢写到磁盘的数据量。Combiner会优化MapReduce的中间结果&＃xff0c;所以它在整 个模型中会多次使用。
  b. 那哪些场景才能使用Combiner呢?从这里分析&＃xff0c;Combiner的输出是Reducer的输入&＃xff0c;Combiner 绝不能改变最终的计算结果。Combiner只应该用于那种Reduce的输入key/value与输出key/value 类型完全一致&＃xff0c;且不影响最终结果的场景。比如累加&＃xff0c;最大值等。Combiner的使用一定得慎重&＃xff0c; 如果用好&＃xff0c;它对job执行效率有帮助&＃xff0c;反之会影响reduce的最终结果。
• 合并溢写文件:每次溢写会在磁盘上生成一个临时文件(写之前判断是否有combiner)&＃xff0c;如果 map的输出结果真的很大&＃xff0c;有多次这样的溢写发生&＃xff0c;磁盘上相应的就会有多个临时文件存在。当 整个数据处理结束之后开始对磁盘中的临时文件进行merge合并&＃xff0c;因为最终的文件只有一个&＃xff0c;写入 磁盘&＃xff0c;并且为这个文件提供了一个索引文件&＃xff0c;以记录每个reduce对应数据的偏移量。

至此map整个阶段结束!!

MapTask的一些配置

官方参考地址

https://hadoop.apache.org/docs/r2.9.2/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml

2.2 MapTask的并行度

MapTask并行度思考

MapTask的并行度决定Map阶段的任务处理并发度&＃xff0c;从而影响到整个Job的处理速度。

MapTask并行度决定机制

数据块:Block是HDFS物理上把数据分成一块一块。

切片:数据切片只是在逻辑上对输入进行分片&＃xff0c;并不会在磁盘上将其切分成片进行存储。

2.2.1 切片机制源码阅读

默认就是128M;

MapTask并行度是不是越多越好呢?

答案不是&＃xff0c;如果一个文件仅仅比128M大一点点也被当成一个split来对待&＃xff0c;而不是多个split.

MR框架在并行运算的同时也会消耗更多资源&＃xff0c;并行度越高资源消耗也越高&＃xff0c;假设129M文件分为两个分 片&＃xff0c;一个是128M&＃xff0c;一个是1M;

对于1M的切片的Maptask来说&＃xff0c;太浪费资源。

129M的文件在Hdfs存储的时候会不会切成两块?

2.3 ReduceTask 工作机制

Reduce大致分为copy、sort、reduce三个阶段&＃xff0c;重点在前两个阶段。copy阶段包含一个 eventFetcher来获取已完成的map列表&＃xff0c;由Fetcher线程去copy数据&＃xff0c;在此过程中会启动两个merge线 程&＃xff0c;分别为inMemoryMerger和onDiskMerger&＃xff0c;分别将内存中的数据merge到磁盘和将磁盘中的数据 进行merge。待数据copy完成之后&＃xff0c;copy阶段就完成了&＃xff0c;开始进行sort阶段&＃xff0c;sort阶段主要是执行 finalMerge操作&＃xff0c;纯粹的sort阶段&＃xff0c;完成之后就是reduce阶段&＃xff0c;调用用户定义的reduce函数进行处理。

详细步骤

• Copy阶段&＃xff0c;简单地拉取数据。Reduce进程启动一些数据copy线程(Fetcher)&＃xff0c;通过HTTP方式请求 maptask获取属于自己的文件。
• Merge阶段。这里的merge如map端的merge动作&＃xff0c;只是数组中存放的是不同map端copy来的数 值。Copy过来的数据会先放入内存缓冲区中&＃xff0c;这里的缓冲区大小要比map端的更为灵活。merge 有三种形式:内存到内存;内存到磁盘;磁盘到磁盘。默认情况下第一种形式不启用。当内存中的 数据量到达一定阈值&＃xff0c;就启动内存到磁盘的merge。与map 端类似&＃xff0c;这也是溢写的过程&＃xff0c;这个过 程中如果你设置有Combiner&＃xff0c;也是会启用的&＃xff0c;然后在磁盘中生成了众多的溢写文件。第二种 merge方式一直在运行&＃xff0c;直到没有map端的数据时才结束&＃xff0c;然后启动第三种磁盘到磁盘的merge 方式生成最终的文件。
• 合并排序。把分散的数据合并成一个大的数据后&＃xff0c;还会再对合并后的数据排序。
• 对排序后的键值对调用reduce方法&＃xff0c;键相等的键值对调用一次reduce方法&＃xff0c;每次调用会产生零个 或者多个键值对&＃xff0c;最后把这些输出的键值对写入到HDFS文件中。

2.4 ReduceTask并行度

ReduceTask的并行度同样影响整个Job的执行并发度和执行效率&＃xff0c;但与MapTask的并发数由切片数决定
不同&＃xff0c;ReduceTask数量的决定是可以直接手动设置:

// 默认值是1&＃xff0c;手动设置为4
job.setNumReduceTasks(4);


注意事项

• ReduceTask&＃61;0&＃xff0c;表示没有Reduce阶段&＃xff0c;输出文件数和MapTask数量保持一致;
• ReduceTask数量不设置默认就是一个&＃xff0c;输出文件数量为1个;
• 如果数据分布不均匀&＃xff0c;可能在Reduce阶段产生倾斜;

2.5 Shuffle机制

map阶段处理的数据如何传递给reduce阶段&＃xff0c;是MapReduce框架中最关键的一个流程&＃xff0c;这个流程就叫
shuffle。

shuffle: 洗牌、发牌——(核心机制:数据分区&＃xff0c;排序&＃xff0c;分组&＃xff0c;combine&＃xff0c;合并等过程)

四、YARN资源调度

1、Yarn架构

ResourceManager(rm):处理客户端请求、启动/监控ApplicationMaster、监控NodeManager、资 源分配与调度;

NodeManager(nm):单个节点上的资源管理、处理来自ResourceManager的命令、处理来自 ApplicationMaster的命令;

ApplicationMaster(am):数据切分、为应用程序申请资源&＃xff0c;并分配给内部任务、任务监控与容错。

Container:对任务运行环境的抽象&＃xff0c;封装了CPU、内存等多维资源以及环境变量、启动命令等任务运
行相关的信息。

2、Yarn任务提交(工作机制)

作业提交过程之YARN

• 作业提交
  第1步:Client调用job.waitForCompletion方法&＃xff0c;向整个集群提交MapReduce作业。
  第2步:Client向RM申请一个作业id。
  第3步:RM给Client返回该job资源的提交路径和作业id。
  第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。
  第5步:Client提交完资源后&＃xff0c;向RM申请运行MrAppMaster。
• 作业初始化
  第6步:当RM收到Client的请求后&＃xff0c;将该job添加到容量调度器中。
  第7步:某一个空闲的NM领取到该Job。
  第8步:该NM创建Container&＃xff0c;并产生MRAppmaster。
  第9步:下载Client提交的资源到本地。
• 任务分配
  第10步:MrAppMaster向RM申请运行多个MapTask任务资源。
  第11步:RM将运行MapTask任务分配给另外两个NodeManager&＃xff0c;另两个NodeManager分 别领取任务并创建容器。
• 任务运行
  第12步:MR向两个接收到任务的NodeManager发送程序启动脚本&＃xff0c;这两个NodeManager 分别启动MapTask&＃xff0c;MapTask对数据分区排序。
  第13步:MrAppMaster等待所有MapTask运行完毕后&＃xff0c;向RM申请容器&＃xff0c;运行ReduceTask。
  第14步:ReduceTask向MapTask获取相应分区的数据。
  第15步:程序运行完毕后&＃xff0c;MR会向RM申请注销自己。
• 进度和状态更新
  YARN中的任务将其进度和状态返回给应用管理器, 客户端每秒(通过 mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。
• 作业完成
  除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作 业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完 成之后, 应用管理器和Container会清理工作状态。作业的信息会被作业历史服务器存储以备 之后用户核查。

3、 Yarn调度策略

Hadoop作业调度器主要有三种:FIFO、Capacity Scheduler和Fair Scheduler。Hadoop2.9.2默认的资源调度器是Capacity Scheduler。

3.1 FIFO(先进先出调度器)

3.2 容量调度器(Capacity Scheduler 默认的调度器)

Apache Hadoop默认使用的调度策略。Capacity 调度器允许多个组织共享整个集群&＃xff0c;每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列&＃xff0c;然后再为每个队列分配一定的集 群资源&＃xff0c;这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外&＃xff0c;队列内 部又可以垂直划分&＃xff0c;这样一个组织内部的多个成员就可以共享这个队列资源了&＃xff0c;在一个队列内部&＃xff0c; 资源的调度是采用的是先进先出(FIFO)策略。

3.3 Fair Scheduler(公平调度器&＃xff0c;CDH版本的hadoop默认使用的调度器)

Fair调度器的设计目标是为所有的应用分配公平的资源(对公平的定义可以通过参数来设置)。公 平调度在也可以在多个队列间工作。举个例子&＃xff0c;假设有两个用户A和B&＃xff0c;他们分别拥有一个队列。 当A启动一个job而B没有任务时&＃xff0c;A会获得全部集群资源;当B启动一个job后&＃xff0c;A的job会继续运 行&＃xff0c;不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它 job还在运行&＃xff0c;则它将会和B的第一个job共享B这个队列的资源&＃xff0c;也就是B的两个job会用于四分之 一的集群资源&＃xff0c;而A的job仍然用于集群一半的资源&＃xff0c;结果就是资源最终在两个用户之间平等的共享。

3.4 Yarn多租户资源隔离配置

Yarn集群资源设置为A,B两个队列&＃xff0c;

• A队列设置占用资源70%主要用来运行常规的定时任务&＃xff0c;
• B队列设置占用资源30%主要运行临时任务&＃xff0c;
• 两个队列间可相互资源共享&＃xff0c;假如A队列资源占满&＃xff0c;B队列资源比较充裕&＃xff0c;A队列可以使用B队列的 资源&＃xff0c;使总体做到资源利用最大化.

3.5 选择使用Fair Scheduler调度策略

3.5.1 yarn-site.xml


<property><name>yarn.resourcemanager.scheduler.classname><value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairSch edulervalue><description>In case you do not want to use the default schedulerdescription>
property>


3.5.2 创建fair-scheduler.xml文件

在Hadoop安装目录/etc/hadoop创建该文件


<allocations><defaultQueueSchedulingPolicy>fairdefaultQueueSchedulingPolicy><queue name&＃61;"root" ><queue name&＃61;"default"><aclAdministerApps>*aclAdministerApps><aclSubmitApps>*aclSubmitApps><maxResources>9216 mb,4 vcoresmaxResources><maxRunningApps>100maxRunningApps><minResources>1024 mb,1vcoresminResources><minSharePreemptionTimeout>1000minSharePreemptionTimeout><schedulingPolicy>fairschedulingPolicy><weight>7weight>queue><queue name&＃61;"queue1"><aclAdministerApps>*aclAdministerApps><aclSubmitApps>*aclSubmitApps><maxResources>4096 mb,4vcoresmaxResources><maxRunningApps>5maxRunningApps><minResources>1024 mb, 1vcoresminResources><minSharePreemptionTimeout>1000minSharePreemptionTimeout><schedulingPolicy>fairschedulingPolicy><weight>3weight>queue>queue><queuePlacementPolicy><rule create&＃61;"false" name&＃61;"specified"/><rule create&＃61;"true" name&＃61;"default"/>queuePlacementPolicy>
allocations>


3.5.3 界面验证