shuffle优化、数据倾斜

shuffle 就是map到reduce的过程 map阶段:

增大缓冲区的大小：默认100M，可以改为200增大缓冲区的溢写百分比：默认0.8，可以改为0.9减少溢写文件的merge次数采用combiner提前预聚合，减少IO。（不影响业务逻辑的前提下，只能加减，不能做乘除等复杂聚合）

合理设置map和reduce数：两个都不能设置太少，也不能设置太多。
太少，会导致task等待，延长处理时间太多，会导致map、reduce任务之间竞争资源，造成处理超时等错误
增加每个reduce去map中拿数据的并行度增大reduce端存储数据内存的大小

采用数据压缩的方式，减少IO时间。map输入端：主要考虑数据量大小和切片，支持切片的有lzo，Bzip2。Lzo要想支持切片必须创建索引map输出端：主要考虑速度，如：snappy，lzoreduce输出端：主要看具体需求，比如：如果有下一个MR阶段，就要考虑切片，永久保存就考虑压缩率比较大的gzip

yarn.nodemanager.resouce.memory-mb：nodemanager默认内存8G。需要根据服务器实际配置灵活调整，例如128G内存，配置为100G内存左右yarn.scheduler.maximum-allocation-mb：单任务默认内存8G。需要根据该任务的数据量灵活调整，例如128m数据，配置1G内存mapreduce.map.memory.mb：默认内存大小为1G。控制分配给MapTask内存上限，如果超过会kill掉进程（报：Container is running beyond physical memory limits. Current usage:565MB of512MB physical memory used；Killing Container）。如果数据量是128m，正常不需要调整内存；如果数据量大于128m，可以增加MapTask内存，最大可以增加到4-5g。mapreduce.reduce.memory.mb：默认内存大小为1G。控制分配给ReduceTask内存上限。如果数据量是128m，正常不需要调整内存；如果数据量大于128m，可以增加ReduceTask内存大小为4-5g。mapreduce.map.java.opts：控制maptask堆内存大小。（如果内存不够，报：java.lang.OutOfMemoryError）mapreduce.reduce.java.opts：控制reducetask堆内存大小。（如果内存不够，报：java.lang.OutOfMemoryError）增加maptask和reducetask的CPU核数增加每个container的CPU核数和内存在hdfs-site.xml文件中配置多目录dfs.namenode.handler.count=20*log2(cluster size): namenode的一个工作线程池，用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。

压缩：对数据进行压缩，减少读写数据量；减少不必要的排序内存化：Shuffle的数据不放在磁盘而是尽量放在内存中，除非逼不得已往磁盘上放；当然了如果有性能和内存相当的第三方存储系统，那放在第三方存储系统上也是很好的

数据倾斜是指分配给每个任务的数据量的不平衡或处理数据所需的工作量的不平衡。在 MapReduce 中，当一个节点在 Map 或 Reduce 阶段分配要处理的数据多于其他节点时，就会发生倾斜

空值引发的数据倾斜
实际业务中有些大量的null值或者一些无意义的数据参与到计算作业中，表中有大量的null值，如果表之间进行join操作，就会有shuffle产生这样所有的null值都会被分配到一个reduce中，必然产生数据倾斜

解决方案：
第一种：可以直接不让null值参与join操作，就是不让null值有shuffle阶段
第二种：因为null值参与shuffle时的hash结果是一致的，那么我们可以给null值随机赋值，这样它们的hash结果就不一样，就会进到不同的reduce中：

不同数据类型引发的数据倾斜
对于两个表join，表a中需要join的字段key为int，表b中key字段既有string类型也有int类型。当按照key进行两个表的join操作时，默认的Hash操作会按int型的id来进行分配，这样所有的string类型都被分配成同一个id，结果就是所有的string类型的字段进入到一个reduce中，引发数据倾斜。

解决方案: 把int转为string统一key的数据类型

不可拆分的大文件引发的数据倾斜
当集群的数据量增长到一定规模，有些数据需要归档或者转储，这时候往往会对数据进行压缩;当对文件使用GZIP压缩等 不支持文件分割的压缩方式，在日后有作业涉及读取压缩后的文件时，该压缩文件只会被一个任务所读取。如果该压缩文件很大，则处理该文件的Map需要花费的时间会远多于读取普通文件的Map时间，该Map任务会成为作业运行的瓶颈。这种情况也就是Map读取文件的数据倾斜。

解决方案: 将使用GZIP压缩等不支持文件分割的文件转为bzip和zip等支持文件分割的压缩方式