【Hadoop优化】

HDFS小文件影响

缺点：
（1） 增加map开销。每一个分片都要执行一次map任务；
（2） 处理小文件，增加作业的寻址时间
（3） 需要记录小文件的元数据，造成namenode内存浪费
解决方法：
（1） 尽量避免出现小文件，将多个小文件事先合成一个顺序文件；将文件名作为键，文件内容作为值；
（2） 如果hdfs中出现大批小文件，用ComebineFileInputFormat将多个小文件打包到一个分片中；
（3） 使用hadoop自带的archive工具，主要减少namenode的负载。

数据输入小文件处理

· 合并小文件：对小文件进行归档（Har）、自定义Inputformat将小文件存储成SequenceFile文件。
· 采用ConbinFileInputFormat来作为输入，解决输入端大量小文件场景
· 对于大量小文件Job，可以开启JVM重用

Map阶段

· 增大环形缓冲区大小。由100m扩大到200m
· 增大环形缓冲区溢写的比例。减少spll的次数，减少磁盘io。由80%扩大到90%
· 减少对溢写文件的merge次数。增大merge的文件数目，缩短mr处理时间（10个文件，一次20个merge）
· 不影响实际业务的前提下，map后先采用Combiner合并，减少 I/O

Reduce阶段

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

IO 传输

· 采用数据压缩的方式，减少网络IO的的时间
· 使用SequenceFile二进制文件

整体优化

· MapTask默认内存大小为1G，可以增加MapTask内存大小为4g
· ReduceTask默认内存大小为1G，可以增加ReduceTask内存大小为4-5g
· 可以增加MapTask的cpu核数，增加ReduceTask的CPU核数
· 增加每个Container的CPU核数和内存大小
· 调整每个Map Task和Reduce Task最大重试次数

压缩

提示：如果面试过程问起，我们一般回答压缩方式为Snappy，特点速度快，缺点无法切分（可以回答在链式MR中，Reduce端输出使用bzip2压缩，以便后续的map任务对数据进行split）

你是如何解决Hadoop数据倾斜的问题的，能举个例子吗?

1）提前在map进行combine，减少传输的数据量
在Mapper加上combiner相当于提前进行reduce，即把一个Mapper中的相同key进行了聚合，减少shuffle过程中传输的数据量，以及Reducer端的计算量。
如果导致数据倾斜的key 大量分布在不同的mapper的时候，这种方法就不是很有效了
2）数据倾斜的key 大量分布在不同的mapper
在这种情况，大致有如下几种方法：
· 「局部聚合加全局聚合」
第一次在map阶段对那些导致了数据倾斜的key 加上1到n的随机前缀，这样本来相同的key 也会被分到多个Reducer 中进行局部聚合，数量就会大大降低。
第二次mapreduce，去掉key的随机前缀，进行全局聚合。
「思想」：二次mr，第一次将key随机散列到不同 reducer 进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀，按原key进行reduce处理。
这个方法进行两次mapreduce，性能稍差
· 抽样和范围分区
通过对原始数据进行抽样得到的结果集来预设分区边界值
· 「实现自定义分区」
根据数据分布情况，自定义散列函数，将key均匀分配到不同Reducer。