hadoop 优化之企业优化

Hadoop优化之企业优化，内容包括MapReduce跑的慢的常见原因、MapReduce的优化方法、常用的调优参数、hadoop小文件优化方法等。

MapReduce跑的慢的常见原因

MapReduce程序效率的瓶颈在于以下量两点（主要）
1、计算机的硬件设施，它包括计算机的CPU、内存、磁盘检查、网络等
2、软件方面的-I/O操作
a、数据倾斜
b、MapTask和ReduceTask的数设置的不合理
d、MapTask运行的时间太久，会导致ReduceTask等待的过久
e、小文件过多，不符合hadoop设计的初衷
f、大量的不可切片的超大的压缩文件
g、切片（Spill）的次数过多
h、合并（Merge）的次数过多等等

MapReduce的优化方法

概述

想要优化MapReduce，我们主要从以下六个方面进行考虑：
a、数据输入阶段
b、Map阶段
c、Reduce阶段
d、I/O传输阶段
e、数据倾斜
f、常用的调优参数

下面就对这几个进行分别的说明

数据输入阶段

1、在这个阶段出现的问题，主要是因为小文件过多导致的，为此可以通过一下两点解决：
a、合并小文件。在执行MapReduce任务前将小文件进行合并。因为大佬的小文件会产生大量的MapTask，增大了MapTask装载的次数，而任务的装载又是比较耗时的，从而导致了MapReduce运行较慢
b、采用CombineTextInputFormat类来作为输入，解决输入端大量小文件的输入的问题。它是通过合并小文件来解决的。

MapTask阶段

主要问题：
a、溢写次数多降低性能
b、小文件多
c、MapTask后的输出小文件多
解决办法：
a、减少溢写（spill）的次数。通过调整mapreduce.task.io.sort.mb和
mapreduce.map.sort.spill.percent参数值，增大触发Spill的内存上限，减少Spill次数，从而减少磁盘I/O。
b、减少合并（merge）次数。通过调整mapreduce.task.io.sort.factor参数，增大merge的文件数目，减少合并的次数，从而缩短MapReduce的处理时间
c、在map之后，在不影响业务逻辑的前提下，先进行Combine处理，以减少I/O。

Reduce阶段

a、设置合理的map和reduce数量。注意：两个都不能设置太少，也不能设置太多，太少会导致Task等待，延长处理时间。太多，会导致Map、Reduce任务间竞争资源，造成处理超时等错误。
b、设置Map和Reduce共存。通过调整mapreduce.job.reduce.showstart.completedmaps参数，使Map运行到一定程度后，reduce也开始运行，减少了reduce等待的时间。
c、规避使用reduce。因为在reduce用于连接大量数据集时会产生大量的reduce阶段。
d、合理的设置reduce端的buffer。默认情况下，数据达到一个阈值的时候，buffer中的数据就会写入磁盘，然后reduce会从磁盘中获得所有的数据。也就是说，buffer和reduce是没有直接关联的，中间多次写磁盘到读磁盘的过程，既然操作这样的弊端，那么久可以通过参数来配置，使得buffer中的一部分数据可以直接输送到reduce，从而减少I/O开：mapreduce.reduce.input.buffer.percent，默认为0.0.当值大于0的时候，会保留指定比例的内存读buffer中的数据直接拿给reduce使用。这样以来，设置buffer需要内存，读取数据需要内存，reduce计算也要内存，所有要根据作业的运行情况进行调整。

I/O

a、采用数据压缩的方式来减少网络I/O的传输时间。可以通过安装Snappy和LZO压缩编码器，因为他们两个压缩速度快，综合时间和硬件情况下选择他们两个是最合适的（参见另外一篇博客：hadoop数据压缩及涉及的相关算法和（MapReduce）代码示例演示）
b、使用SequenceFile二进制文件（注意，这种方式在现在使用的已经很少了）

数据倾斜

数据倾斜现象。

第一个是数据频率倾斜，即某一个区域的数据量要远远大于其它区域。第二个是数据大小倾斜，即部分记录的大小远远大于平均值。

减少数据倾斜的方法

a、抽样和范围分区。即通过对原始数据进行抽样得到的结果集来预设分区的边界值。
b、自定义分区。这个是基于输出键的背景知识进行自定义分区。比如，一个map输出键的单词来源于一本书，且其中某几个专业词汇较多。那么就可以自定义分区将这些专业词汇发送给固定的一部分reduce实例，从而将其它的都发送给剩余的reduce实例。
c、Combiner。即使用Combiner可以大量的减少数据倾斜，在有可能的情况下，Combiner的目的就是聚合并精简数据。
d、采用map join来尽可能的避免reduce join。

常用的调优参数

和资源相关的参数

---

以下参数是在用户自己的MapReduceApplication中配置就可以生效（mapred-default.xml）

---

配置参数	参数解释
mapreducemapmemory.mb	即一个MapTask可使用的资源的上限（单位：MB），默认为1024MB。如果MapTask实际使用的资源量超过该值，则会被强行杀死。
mapreduce.reduce.memory.mb	即一个reduce可以使用的资源上行，默认为1024MB。如果ReduceTask在实际使用的资源中超过了该值，则也会被强制杀死。
mapreduce.map.cpu.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内存值的0.66，即660MB）
mapreduce.reduce.shuffle.input.buffer.percent	buffer大小占reduce可用内存的比例，0.7，即700MB
mapreduce.reduce.input.buffer.percent	指定多少比例的内存用来存放buffer中的数据，默认的值为0.0，这里可以设置成小于等于mapreduce.reduce.shuffle.merge.percent的值

---

应该在yarn启动之前就配置咋服务器的配置文件才能生效（yarn-default.xml）

---

配置参数	参数解释
yarn.scheduler.mininum-allocation-mb	给应用程序Container分配的最小内存，默认值为1024MB
yarn.scheduler.maximum-allocation-mb	给应用程序Container分配的最大内存，默认值为8196MB，即8GB。
yarn.scheduler.minimum-allocation-vcores	每个container申请的最小CPU core，默认值为1个
yarn.scheduler.maximum-allocation-vcores	每个container申请的最大CPU core，默认值为32个
yarn.nodemanager.resource.memory-mb	给containers分配的最大物理内存，默认值为8192MB，即8GB。

---

shuffle性能的优化参数，应该在yarn启动之前就配置好（mapred-default.xml）

配置参数	参数解释
mapreduc.task.io.sort.mb	shuffle的环形缓冲区的大小，其默认值为100MB。
mapreduce.map.sort.spill.percent	环形缓冲区溢出的阈值，默认值为80%。

容错相关的配置参数（MR性能优化）

配置参数	参数解释
mapreduce.map.maxattempts	每个MapTask最大重试次数，一旦重试次数超过该值，则认为MapTask运行失败，其默认值为4次。
mapreduce.reduce.maxattempts	每个ReduceTask最大重试次数，一旦重试次数超过该值，则认为MapTask运行失败，默认值也是4次。
mapreduce.task.timeout	Task 超时时间，经常需要设置的一个参数，该参数表达的意思为：如果一个 Task 在一定时间内没有任何进入，即不会读取新的数据，也没有输出数据，则认为该 Task 处于 Block 状态，可能是卡住了，也许永远会卡住，为了防止因为用户程序永远 Block 住不退出，则强制设置了一个该超时时间（单位毫秒），默认600000（10 分钟）。如果你的程序对每条输入数据的处理时间过长（比如会访问数据库，通过网络拉取数据等），建议将该参数调大，该参数过小常出现的错误提示是：“AttemptID:attempt_14267829456721_123456_m_000224_0Timed out after 300 secsContainer killed by theApplicationMaster.”。

hadoop小文件优化方法

hadoop小文件弊端

分布式文件系统上的每个文件都要在nn上创建对应的元数据，这个元数据大小约为150byte，这样当小文件比较多的时候，就会产生很多的元数据文件。一方面不仅会占用大量的nn的内存空间，还会让元数据文件过多，导致寻址的时间边长，速度变慢。

小文件过多，会导致在mapreduce计算时生成大量的切片，需要启用过多的MapTask，每个MapTask处理的数据量小，导致MapTask的处理时间比启动时间还小，从而会浪费资源。

小文件解决方案

小文件的优化

a、在数据采集阶段就尽可能的将小文件或小批量的数据合成大文件再上传Hdfs。
b、在业务处理之前，在hdfs上使用MapReduce程序对小文件进行合并。
c、在MapReduce处理时，可采用CombineTextInputFormat来提高效率
d、开启uber模式，实现jvm重用。

hadoop archive

hadoop archive是一个高效的将小文件放入hdfs块中的问及那存档工具，能够将小文件打包成一个HAR文件，从而达到减小NameNode的内存使用。

sequenceFile

SequenceFile是有一系列的二进制KV键值对组成，如果K值为文件名，则V值为文件内容，可将将大批小文件合并成一个大文件

CombineTextInputFormat

CombineTextInputFormat多用于将多个小文件在切片的过程中生成一个单独的切片或者少量的切片。

开启Uber模式

开启uber模式，可以实现jvm的重用。在默认情况下，每个Task都需要启动一个jvm来运行，如果task计算的数据量很小，就可以让同一个job的多个task运行在一个jvm中，不必每个task都开启一个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.maxreduces</name>
	<value>1</value>
</property>

<!-- uber 模式中最大的输入数据量，默认使用 dfs.blocksize 的值，可向下修改 -->
<property>
	<name>mapreduce.job.ubertask.maxbytes</name>
	<value></value>
</property>