大数据调优总结

一、 MapReduce

1、数据倾斜调优

数据中不可避免地会出现离群值（outlier），并导致数据倾斜。这些离群值会显著地拖慢MapReduce的执行。
数据倾斜会导致map和reduce的任务执行时间大为延长，也会让需要缓存数据集的操作消耗更多的内存资源

常见的数据倾斜有以下几类：

• 1）数据频率倾斜——某一个区域的数据量要远远大于其他区域。比如某一个key对应的键值对远远大于其他键的键值对。
  • 2）数据大小倾斜——部分记录的大小远远大于平均值。

2、如何诊断哪些键存在数据倾斜？

• 发现倾斜数据之后，有必要诊断造成数据倾斜的那些键。有一个简便方法就是在代码里实现追踪每个键的最大值。
• 为了减少追踪量，可以设置数据量阀值，只追踪那些数据量大于阀值的键，并输出到日志中。
• 运行作业后就可以从日志中判断发生倾斜的键以及倾斜程度；跟踪倾斜数据是了解数据的重要一步，也是设计MapReduce作业的重要基础

1）预聚合

提前在map进行combine，减少传输的数据量

2）自定义分区

根据数据分布情况，自定义散列函数，将key均匀分配到不同Reducer

3）局部聚合加全局聚合。

二次mr，第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀，按原key进行reduce处理，性能稍差。

4）增加Reducer，提升并行度

JobConf.setNumReduceTasks(int)

5）数据大小倾斜，

调参line.maxlength，限制RecordReader读取最大长度。

2、MR优化

Map阶段优化

（1）增大环形缓冲区大小。由100m扩大到200m
（2）增大环形缓冲区溢写的比例。由80%扩大到90%
（3）减少对溢写文件的merge次数。（10个文件，一次20个merge）
（4）不影响实际业务的前提下，采用Combiner提前合并，减少 I/O。

Reduce阶段优化

（1）合理设置Map和Reduce数：两个都不能设置太少，也不能设置太多。太少，会导致Task等待，延长处理时间；太多，会导致 Map、Reduce任务间竞争资源，造成处理超时等错误。
（2）设置Map、Reduce共存：调整slowstart.completedmaps参数，使Map运行到一定程度后，Reduce也开始运行，减少Reduce的等待时间。
（3）规避使用Reduce，因为Reduce在用于连接数据集的时候将会产生大量的网络消耗。
（4）增加每个Reduce去Map中拿数据的并行数
（5）集群性能可以的前提下，增大Reduce端存储数据内存的大小。

IO传输

采用数据压缩的方式，减少网络IO的时间。安装Snappy和LZOP压缩编码器。

压缩：

（1）map输入端主要考虑数据量大小和切片，支持切片的有Bzip2、LZO。注意：LZO要想支持切片必须创建索引。
（2）map输出端主要考虑速度，速度快的snappy、LZO。
（3）reduce输出端主要看具体需求，例如作为下一个mr输入需要考虑切片，永久保存考虑压缩率比较大的gzip。

3、如何减小reduce端数据倾斜

数据频率倾斜 ，常用方式有：分区、预聚合

1、自定义分区：基于输出键的背景知识，进行自定义分区。

例如，如果map输出键的单词来源于一本书。其中大部分必然是省略词（stopword）。那么就可以将自定义分区将这部分省略词发送给固定的一部分reduce实例。而将其他的都发送给剩余的reduce实例。

2、Combine预聚合：使用Combine，可大量减小数据频率倾斜和数据大小倾斜。combine的目的就是聚合并精简数据。

3、抽样和范围分区

• Hadoop默认的分区器是HashPartitioner，基于map输出键的哈希值分区。这仅在数据分布比较均匀时比较好。在有数据倾斜时就很有问题。
• 使用分区器，需要首先了解数据的特性。TotalOrderPartitioner中，可以通过对原始数据进行抽样得到的结果集来预设分区边界值
• TotalOrderPartitioner中的范围分区器可以通过预设的分区边界值进行分区。因此它也可以很好地用在矫正数据中的部分键的数据倾斜问题。

4、数据大小倾斜

在map端或reduce端的数据大小倾斜，都会对缓存造成较大的影响，乃至OOM异常。

方法就是：根源上处理；以及设置RecordReader读取的line.maxlength最大长度，默认无限制

• 设置mapreduce.input.linerecordreader.line.maxlength，来限制RecordReader读取的最大长度。
• RecordReader在TextInputFormat和KeyValueTextInputFormat类中使用。默认长度没有上限。

二、hive调优

1、配置上开启：Fetch抓取、 本地模式、 严格模式、数据压缩、并行执行

1）开启Fetch抓取，不必使用MapReduce计算

对某些情况的查询可以不必使用MapReduce计算，在全局查找、字段查找、limit查找等都不走mapreduce。
把hive-default.xml.template文件中hive.fetch.task.conversion设置成more，然后执行查询语句，查询方式都不会执行mr程序。 默认是more，（老版本minimal）；设置成none，然后执行查询语句，都会执行mapreduce程序

2）开启本地模式：如果数据量小，只启动一个Maptask

默认情况下是启用hadoop的job模式，把任务提交到集群中运行，这样会导致计算非常缓慢；

开启本地模式，并执行查询语句

set hive.exec.mode.local.auto=true; //开启本地mr

3）开启严格模式，禁止3种类型的查询

开启严格模式，可以禁止3种类型的查询。

• 分区表，where 含有分区字段 过滤条件 来限制范围，否则不允许执行
• order by，必须使用limit语句
• 限制笛卡尔积的查询

防止用户执行，那些可能意想不到的不好的影响的查询。
配置：set hive.mapred.mode=strict; 默认是非严格模式nonstrict

4）开启数据的压缩，

Hive表中间数据压缩Hive表最终输出结果压缩，

5）设置并行执行

把一个sql语句中没有相互依赖的阶段，并行去运行，提高集群资源利用率配置：
set hive.exec.parallel=true;
set hive.exec.parallel.thread.number=16;

2、开发上：表的join优化、列裁剪、 限制笛卡尔积、避免数据倾斜

1）表的join优化

• 1）老版本hive，大小表 join 时，小表放在join的左边；
• 2）大表 join 大表 时，空 key 过滤，空 key 赋一个随机的值；
• 3）map join ，在Map端先进行部分聚合，最后在Reduce端得出最终结果；
• 4）count distinct，使用先group by 再count的方式替换;
• 5）多个表关联时，最好分拆成小段，避免大sql（无法控制中间Job）；

2）使用分区剪裁、列剪裁 ，

• 尽可能早地过滤掉尽可能多的数据量，避免大量数据流入外层SQL。
• 尽量使用分区过滤，少用select *

3）限制笛卡尔积的查询

4）避免数据倾斜：

合理设置Map数 ；合理设置Reduce数；
小文件合并； 复杂文件增加Map数 ；

三、spark调优

1、资源调优：

（1）分配更多的资源：executor-memory、executor-cores、driver-memory

（2）提高并行度：task的数量cpu core数量的2~3倍，使用rdd.repartition 来重新分区

​

2、开发调优

（1）RDD持久化

可以把多次使用到的rdd，也就是公共rdd进行持久化，避免后续需要，再次重新计算，提升效率。

可以调用rdd的cache或者persist方法。

• 1）cache方法默认是把数据持久化到内存中 ，例如：rdd.cache ，其本质还是调用了persist方法
• 2）persist方法中有丰富的缓存级别，这些缓存级别都定义在StorageLevel这个object中，可以结合实际的应用场景合理的设置缓存级别。例如：
  rdd.persist(StorageLevel.MEMORY_ONLY),这是cache方法的实现。

（2）使用广播变量

若要处理的共享数据量非常大，并且一个stage中出现大量的task
，会通过网络将数据传输到各个task中去，给task使用，会涉及大量的网络传输开销与内存开销，可能会导致频繁的垃圾回收器的回收GC。

一些维度数据进行广播，该executor上的各个task再从所在节点的BlockManager获取变量，而不是从Driver获取变量，从而提升了效率。

task在运行的时候，想要使用广播变量中的数据，此时首先会在自己本地的Executor对应的BlockManager中，尝试获取变量副本；如果本地没有，那么就从Driver远程拉取广播变量副本，并保存在本地的BlockManager中；此后这个executor上的task，都会直接使用本地的BlockManager中的副本。

注意：
（1）不能将一个RDD使用广播变量广播出去，因为RDD是不存储数据的。可以将RDD的结果广播出去。
（2）广播变量只能在Driver端定义，不能在Executor端定义。
（3）在Driver端可以修改广播变量的值，在Executor端无法修改广播变量的值。
（4）如果executor端用到了Driver的变量，如果不使用广播变量在Executor有多少task就有多少Driver端的变量副本。
（5）如果Executor端用到了Driver的变量，如果使用广播变量在每个Executor中只有一份Driver端的变量副本。

配置：
  （1）通过sparkContext的broadcast方法把数据转换成广播变量，类型为Broadcast，
  val broadcastArray: Broadcast[Array[Int]] = sc.broadcast(Array(1,2,3,4,5,6))
  (2) 然后executor上的BlockManager就可以拉取该广播变量的副本获取具体的数据。
  获取广播变量中的值可以通过调用其value方法
	 val array: Array[Int] = broadcastArray.value

（3）避免shuffle类算子， join、groupByKey distinct、repartition。

shuffle涉及到数据要进行大量网络传输，下游阶段task任务需要通过网络拉取上阶段task输出数据，将分布在集群中多个节点上的同一个key，拉取到同一个节点上，进行聚合或join等操作。比如reduceByKey、join等算子，都会触发shuffle操作。

解决方法：

1） Broadcast+map代替join操作

传统的join操作会导致shuffle操作。因为两个RDD中，相同的key都需要通过网络拉取到一个节点上，由一个task进行join操作。

使用Broadcast将一个数据量较小的RDD作为广播变量。Broadcast+map的join操作，不会导致shuffle操作。

2） reduceByKey或aggregateByKey代替groupByKey ，进行预聚合

• reduceByKey/aggregateByKe