day47-hadoop-yarn
day47-hadoop-yarn
hadopp-yarn
容量调度器多队列提交案例

需求
Yarn默认的容量调度器是一条单队列的调度器,在实际使用中会出现单个任务阻塞整个队列的情况。同时,随着业务的增长,公司需要分业务限制集群使用率。这就需要我们按照业务种类配置多条任务队列。
具体配置
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>
修改配置文件capacity-scheduler.xml
修改后

向指定队列提交任务
只需要在配置项中指定具体的队列名
Configuration conf=new Configuration();
conf.set("mapreduce.job.queuename","atguigu")
任务的推测执行
1. 作业完成时间取决于最慢的任务完成时间
一个作业由若干个Map任务和Reduce任务构成。因硬件老化、软件Bug等,某些任务可能运行非常慢。
思考:系统中99%的Map任务都完成了,只有少数几个Map老是进度很慢,完不成怎么办?
2. 推测执行机制
发现拖后腿的任务,比如某个任务运行速度远慢于任务平均速度。为拖后腿任务启动一个备份任务,同时运行。谁先运行完,则采用谁的结果。
3. 执行推测任务的前提条件
1. 每个Task只能有一个备份任务
2. 当前Job已完成的Task必须不小于0.05
3. 开启推测执行参数设置。mapred-site.xml文件中默认是打开的
<property>
<name>mapreduce.map.speculative</name>
<value>true</value>
</property>
<property>
<name>mapreduce.reduce.speculative</name>
<value>true</value>
</property>
4. 不能启用推测执行机制情况
1. 任务间存在严重的负载倾斜
2. 特殊任务,比如任务向数据库中写数据
5 算法原理

Hadoop优化
Hadoop数据压缩
压缩概述
压缩技术能够有效减少底层存储系统(HDFS)读写字节数。压缩提高了网络带宽和磁盘空间的效率。在运行MR程序时,I/O操作、网络数据传输、Shuffle和Merge要花大量的时间,尤其是数据规模很大和工作负载密集的情况下,因此,使用数据压缩显得非常重要。
鉴于磁盘I/O和网络带宽是Hadoop的宝贵资源,数据压缩对节省资源、最小磁盘I/O和网络传输非常有帮助。可以在任意MapReduce阶段启用压缩。不过,尽管压缩与解压操作的CPU开销不高,其性能的提升和资源的节省并非没有代价。
压缩策略和原则
压缩是提高Hadoop运行效率的一种优化策略
通过对Mapper、Reducer运行过程的数据进行压缩,以减少磁盘IO,提高MR程序运行速度。
注意:采用压缩计数减少了磁盘IO,但同时增加了CPU运算负担。所以,压缩特性运用得当能提高性能,但运用不当也可能降低性能。
压缩基本原则
1. 运算密集的job,少用压缩
2. IO密集型的job,多用压缩
MR支持的压缩编码
| 压缩格式 | hadoop自带? | 算法 | 文件扩展名 | 是否可切分 | 换成压缩格式后,原来的程序是否需要修改 |
|---|---|---|---|---|---|
| DEFLATE | 是,直接使用 | DEFLATE | .deflate | 否 | 和文本处理一样,不需要修改 |
| Gzip | 是,直接使用 | DEFLATE | .gz | 否 | 和文本处理一样,不需要修改 |
| bzip2 | 是,直接使用 | bzip2 | .bz2 | 是 | 和文本处理一样,不需要修改 |
| LZO | 否,需要按照 | LZO | .lzo | 是 | 需要建索引,还需要指定输入格式 |
| Snappy | 是,直接使用 | Snappy | .snappy | 否 | 和文本处理一样,不需要修改 |
为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器,
| 压缩格式 | 对应的编码/解压器 |
|---|---|
| DEFLATE | or.apache.hadoop.io.compress.DefaultCodec |
| gzip | or.apache.hadoop.io.compress.GzipCodec |
| bzip2 | org.apache.hadoop.io.compress.BZip2Codec |
| LZO | com.hadoop.compression.lzo.LzopCodec |
| Snappy | org.apache.hadoop.io.compress.SnappyCodec |
压缩性能比较
| 压缩算法 | 原始文件大小 | 压缩文件大小 | 压缩速度 | 解压速度 |
|---|---|---|---|---|
| gzip | 8.3GB | 1.8GB | 17.5MB/s | 58MB/s |
| bzip2 | 8.3GB | 1.1GB | 2.4MB/s | 9.5MB/s |
| LZO | 8.3GB | 2.9GB | 49.3MB/s | 74.6MB/s |
Gzip压缩
- 优点
压缩率比较高,而且压缩/解压缩速度也比较快;Hadoop本身支持,在应用中处理Gzip格式的文件就知道和直接处理文本一样;大部分Linux系统都自带Gzip命令,使用方便。
支持切片
- 缺点
不支持Split(切片)
- 应用场景
当每个文件压缩之后再130M以内(一个快大小内),都可以考虑Gzip压缩格式。例如说一天或者一个小时的日志压缩成一个Gzip文件
Bzip2压缩
- 优点
支持Split;具有很高的压缩率,比Gzip压缩率都高;Hadoop本身自带,使用方便
- 缺点
压缩/解压速度慢
- 应用场景
适合对速度要求不高,但需要较高的压缩率的时候;或者输出之后的数据比较大,处理之后的数据需要压缩存档减少磁盘空间并且以后数据用的比较少的情况;或者对单个很大的文本文件想压缩减少存储空间,同时又需要支持Split,而且兼容之前的应用程序的情况。
LZO压缩(拉泽罗)
- 优点
压缩/解压速度也比较快,合理的压缩率;支持split,是Hadoop中最流行的压缩格式;可以再Linux系统下安装lzop命令,使用方便。
- 缺点
压缩率比Gzip要低一些;Hadoop本身不支持,需要安装;再应用中对Lzo格式的文件需要做一些特殊处理(为了支持Split需要建索引,还需要指定InputFormat为Lzo格式)
- 应用场景
一个很大的文本文件,压缩之后还大于200M以上的可以考虑,而且单个文件越大,Lzo优点越明显
Snappy
- 优点
高速压缩速度和合理的压缩率
- 缺点
不支持Split;压缩率比Gzip要低;(Hadopp3.1.3已经支持了Snappy)Hadoop本身不支持,需要安装
- 应用场景
当MapReduce作业的Map输出的数据比较大的时候,作为Map到Reduce的中间数据的压缩格式;或者作为一个MapReduce作业的输出和另外一个MapReduce作业的输入。
压缩位置的选择
压缩可以再MapReduce作用的任意阶段启用
压缩参数的配置
| 参数 | 默认值 | 阶段 | 说明 |
|---|---|---|---|
| io.compression.codecs | Hadoop使用文件扩展名判断是否支持某种编解码器 | ||
| mapreduce.map.output.compress(在mapred-site.xml中配置) | false | mapper输出 | 设为true,启用压缩 |
| mapreduce.map.output.compress.codec(在mapred-site.xml中配置) | org.apache.hadoop.io.compress.DeffaultCodec | mapper输出 | 企业多使用LZO或Snappy编解码 |
| mapreduce.output.fileoutputformat.coompress(mapred-site.xml) | false | reducer输出 | 设置为true为启用压缩 |
| mapreduceoutput.fileoutputformat.compress.codec(mapred-site.xml) | org.apache.hadoop.io.coompress.DefaultCodec | reducer输出 | 使用标准工作或者编解码器,如gzip和bzip2 |
| mapreduce.output.fileoutputformat.compress.type | RECORD | reducer输出 | SequenceFile输出使用的压缩类 |
压缩操作案例
数据流压缩和解压缩
CompressionCodec有两个方法可以用于轻松地压缩或解压缩数据
想要对正在被写入一个输出流的数据进行压缩,我们可以使用createOutputStream(OutputStreamout)方法创建一个CompressionOutputStream,将其以压缩格式写入底层的流
相反,想要对输入流读取而来的数据进行解压缩,则调用createInputStream(InputStream)函数,从而获得一个CompressionInputStream,从而从底层的流读取未压缩的数据
Map输出端采用压缩
/**
* 压缩:使用支持压缩的流将数据写入到文件
*/
@Test
public void testCompress() throws IOException, ClassNotFoundException {
Configuration conf = new Configuration(); // 创建配置对象
// 待压缩的文件
String srcFile = "D:\\a测试文件\\input\\wordcount2\\abc.txt";
// 压缩后的文件
String desFile = "D:\\a测试文件\\input\\wordcount2\\abc.txt";
// 输入流
FileInputStream fin = new FileInputStream(new File(srcFile));
// 使用压缩的编解码器
String className = "org.apache.hadoop.io.compress.DefaultCodec";
Class<?> aClass = Class.forName(className); // 获取类对象
CompressionCodec codec = (CompressionCodec) ReflectionUtils.newInstance(aClass, conf);// 通过反射获取编解码器对象
// 输入流
FileOutputStream fout = new FileOutputStream(new File(desFile + codec.getDefaultExtension()));
CompressionOutputStream compressionOutputStream = codec.createOutputStream(fout);
// 读写
IOUtils.copyBytes(fin, compressionOutputStream, conf); //
// 关闭流
IOUtils.closeStream(fin);
IOUtils.closeStream(compressionOutputStream);
}
Reduce输出端采用压缩
/**
* 解压缩:使用支持压缩的输入流将数据从文件中读入
*/
@Test
public void DeConpress() throws Exception {
Configuration conf = new Configuration();
// 带解压的文件
String srcFile = "D:\\a测试文件\\input\\wordcount2\\abc.txt.deflate";
// 解压后的文件
String desFile = "D:\\a测试文件\\input\\wordcount2\\abc.txt";
// 输入流
FileInputStream fin = new FileInputStream(new File(srcFile));
// 输出流
FileOutputStream fout = new FileOutputStream(new File(desFile));
// 获取解码器对象
CompressionCodec codec = new CompressionCodecFactory(conf).getCodec(new Path(srcFile));
CompressionInputStream codecInputStream = codec.createInputStream(fin); // 通过解码器对象获取输入流
// 进行读写操作
IOUtils.copyBytes(codecInputStream, fout, conf);
// 关闭流
IOUtils.closeStream(codecInputStream);
IOUtils.closeStream(fout);
}
MapReduce跑的慢的原因
1. 计算机性能
CPU、内存、磁盘健康、网络
2. I/O操作优化
1. 数据倾斜
2. Map和Reduce数设置不合理
3. Map运行时间太长,导致Reduce等待过久
4. 小文件过多
5. 大量的不可分快的超大文件
6. Spill次数过多
7. Merge次数过多等
MapReduce优化方法
MapReduce优化方法主要从六个方面考虑:数据输入、Map阶段、Reduce阶段、IO传输、数据倾斜问题和常用的调优参数
数据输入
1. 合并小文件:在执行MR任务前将小文件进行合并,大量的小文件会产生大量的Map任务,增大Map任务装载比较耗时,从而导致MR运行较慢。
2. 采用CombineTextInputFormat来作为输入,解决输入端大量小文件场景。
Map阶段
1. 减少溢写(spill)次数:通过调整mapreduce.task.io.sort.mb即mpreduce.task.sort.spill.percent参数值,增大触发Spill的内存上限,减少Spill次数,从而减少磁盘IO。
2. 减少合并(Merge)次数:通过调整mapreduce.task.io.sort.factor参数,增大Merge的文件数据,减少Merge的次数,从而缩短MR处理时间。
3. 在Map之后,不影响业务逻辑前提下,先进行Combine处理,减少I/O。
Reduce阶段
1. 合理设置Map和Reduce数:两个都不能设置太少,也不能设置太多。
太少,会导致Task等待,延长处理时间;太多,会导致Map、Reduce任务见竞争资源,造成处理超时等错误
2. 设置Map、Reduce共存:调整mapreduce.job.reduce.slowstart.completedmaps参数,是Map运行到一定程度后,Reduce也开始运行,减少Reduce的等待时间
3. 规避使用Reduce:因为Reduce在用于连接数据集的时候将会产生大量的网络消耗
4. 合理设置Reducae端的Buffer:默认情况下,数据达到一个阈值的时候,Buffer中的数据就会写入磁盘,然后Reduce会从磁盘中获得所有的数据。也就是说,BUffer和Reduce是没有直接关联的,中间多次写磁盘->读磁盘的过程,既然有这个弊端,那么就可以通过参数来配置,使得Buffer中的一部分数据可以直接输送的Reduce,从而减少IO开销:mapreduce.reduce.input.buffer.percent,默认为0.0。当值大于0的时候,会保留指定比例的内存读Buffer中的数据直接拿给Reduce使用。这样一来,设置BUffer需要内存,读取数据需要内存,Reduce计算也要内存,所以要根据作业的运行情况进行调整。
IO传输
1. 采用数据压缩的方式,减少网络IO的时间。安装Snappy和LZO压缩编码器。
2. 使用SequenceFile二进制文件。
数据倾斜问题
数据倾斜现象:
数据频率倾斜--某一个区域的数据量要远远大于其他区域
数据大小倾斜--部分记录的大小远远大于平均值
- 减少数据倾斜的方法
1. 抽样和范围分区
可以通过对原始数据进行抽样得到的结果集来预设分区边界值
2. 自定义区
基于输出键的背景知识进行自定义分区。例如,如果Map输出键的单词来源于一本书。且其中某几个专业词汇较多。那么就可以自定义分区将这些专业词汇发送给固定的一部分Reduce实例。而将其他的都发送给剩余的Reduce实例。
3. Combine
使用Combine可以大量地减少数据倾斜。在可能的情况下,Combine的目的就是聚合并精简数据
4. 采用Map Join,尽量避免Reduce Join
常用的调优参数
- 资源相关参数
以下参数是在用户自己的MR应用程序中配置就可以生效(mapred-default.xml)
| 配置参数 | 参数说明 |
|---|---|
| mapreduce.map.memory.mb | 一个MapTask可使用的资源上限(单位:MB),默认为1024.如果MapTask实际使用的资源超过该值,则会被强制杀死。 |
| mapreduce.reduce.memory.mb | 一个ReduceTask可使用的资源上限(单位:MB),默认为1024.如果MapTask实际使用的资源超过该值,则会被强制杀死。 |
| mapreduce.map.cup.vcores | 每个MapTask可使用的最多cpu core数目,默认值:1 |
| mapreduce.reduce.cpu.vcores | 每个ReduceTask可使用的最多cpu core数目,默认值:1 |
| mapreduce.reduce.shuffle.parallelcopies | 每个Reduce去Map中取数据的并行数。默认值是5 |
| mapreduce.reduce.shuffle.merge.percent | Buffer中的数据达到多少比例开些写入磁盘。默认值0.66 |
| mapreduce.reduce.shuffle.input.buffer.percent | Buffer大小占Reduce可用内存的比例。默认值0.7 |
| mapreduce.reduce.input.buffer.percent | 指定多少比例的内存用来放Buffer中的数据,默认值是0.0 |
- 应该在YARN启动之前就配置在服务器的配置文件中才能生效(yarn-default.xml)
| 配置参数 | 参数说明 |
|---|---|
| yarn.scheduler.minimum-allocation-mb | 给应用程序Container分配的最小内存,默认值:1024 |
| yarn.scheduler.maximum-allocation-mb | 给应用程序Container分配的最大内存,默认值:8192 |
| yarn.scheduler.minimum-allocation-vcores | 每个Container申请的最小CPU核数,默认值:1 |
| yarn.scheduler.maximum-allocation-vcores | 每个Container申请的最大CPU核数,默认值:4 |
| yarn.nodemanager.resource.memory-mb | 给Containers分配的最大物理内存,默认值:8192 |
- Shuffle性能优化的关键参数,应在YARN启动之前就配置好(mapred-default.xml)
| 配置参数 | 参数说明 |
|---|---|
| mapreduce.task.io.sort.mb | Shuffle的环形缓冲区大小,默认100m |
| mapreduce.map.sort.spill.percent | 环形缓冲区溢出的阈值,默认80% |
- 容错相关参数(MapReduce性能优化)
| 配置参数 | 参数说明 |
|---|---|
| mapreduce.map.maxattempts | 每个MapTask最大重试次数,一旦重试参数超过该值,则认为MapTask运行失败,默认值:4 |
| mapreduce.reduce.maxattempts | 每个ReduceTask最大重试次数,一旦重试参数超过该值,则认为MapTask运行失败,默认值:4 |
| mapreduce.task.timeout | Task超时时间,经常需要设置的一个参数,该参数表达的意思为:如果一个Task在一定时间内没有任何进入,既不会读取新的数据,也没有输出数据,则认为该Task处于Block状态,可能卡住了,也许永远会卡住,为了防止因为用户程序永远Block住不退出,则强制设置了一个该超时时间(单位毫秒),默认是600000。如果你的程序对每条输入数据的处理时间过长(比如会访问数据库,通过网络拉去数据等),建议将该参数调大,该参数过小常出现的错误提示是 |
小文件的优化
- 小文件的弊端
HDFS上每个文件都要在NameNode中都有对应的元数据,这个元数据的大小约为150byte,这样当小文件比较多的时候,一方面会大量占用NameNode的内存空间,另一方面就是元数据过多的情况查找速度变慢。
小文件过多,在进行MR计算时,会导致生成过多的切片。需要启动过多的MapTask
- 小文件解决方案
1. 小文件优化的方向:
1. 在数据采集的时候,就将小文件或小皮数据合成大文件再上传HDFS
2. 再业务处理之前,再HDFS上使用MapReduce程序对小文件进行合并。
3. 再Mapreduce处理时,可采用CombineTextInputFormat提高效率
4. 开启uber模式,实现jvm重用
- Hadoop Archive
是一个高效的将小文件放入HDFS块中的文档存档工具,能够将多个小文件打包成一个HAR文件,从而达到减少NameNode的内存使用
- SequenceFile
SequeneFile是由一系列的二进制k/v组成,如果为key为文件名,value为文件内容,可将大批小文件合并成一个大文件
- CombinTextInputFormat
CombineTextInputFormat用于将多个小文件在切片过程中生成一个单独的切片或者少量的切片
- 开启uber模式,实现jvm重用。
默认情况下,每个Task任务都需要启动一个jvm来运行,如果Task任务计算的数据量小,我们可以让同一个Job的多个Task运行在一个Jvm中,不必为每个Taks都开启一个Jvm
开启uber模式,在Mapred-site.xml中添加如下配置
<!--开启uber模式-->
<property>
<name>mapreduce.job.ubertask.enable</name>
<value>true</value>
</property>
<!--uber模式最大的mapTask数量,可向下修改-->
<property>
<name>mapreduce.job.ubertask.maxmaps</name>
<value>9</value>
</property>
<!--uber模式中最大的reduce数量,可向下修改-->
<property>
<name>mapreduce.job.ubertask</name>
<value>1</value>
</property>
<!--uber模式最大的输入数据量,如果不配置,则使用dfs.blocksize的值,可向下修改-->
<property>
<name>mapreduce.job.ubertask.maxbytes</name>
<value></value>
</property>
配置mapreduce.job.jvm.numtasks 参数实现在一个Jvm中运行多个Task,如果设置为-1,则没有数量限制。一般设置在10-20之间。
Zookeeper
概述
Zookeepr是一个开源的分布式的,为分布式应用提供协调
Zookeeper从设计模式角度来理解,是一个基于观察者模式设计的的分布式服务管理框架,它负责存储和管理大叫都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生了变化,Zookeeper就负责通知已经在Zookeepr上注册的那些观察者做出相应的反应
Zookeepr=文件系统+通知机制
其他
ACL
查看Hadoop支持的压缩格式
hadoop checknative

浙公网安备 33010602011771号