从 Map 和 Reduce 角度谈 Hive 优化

1. 从 map 的数量角度

• 1）通常情况下，作业会通过 input 的目录产生一个或者多个 map 任务。

主要的决定因素有：input 的文件总个数，input 的文件大小，集群设置的文件块大小(目前为 128M，可在 hive 中通过 set dfs.block.size;命令查看到，该参数不能自定义修改)

• 2）举例：

a) 假设 input 目录下有 1 个文件 a，大小为 780M，那么 hadoop 会将该文件 a 分隔成 7 个块（6 个 128m 的块和 1 个 12m 的块），从而产生 7 个 map 数。

b) 假设 input 目录下有 3 个文件 a，b，c 大小分别为 10m，20m，150m，那么 hadoop 会分隔成 4 个块（10m，20m，128m，22m），从而产生 4 个 map 数。即，如果文件大于块大小(128m)，那么会拆分，如果小于块大小，则把该文件当成一个块。

• 3）是不是 map 数越多越好？

答案是否定的。如果一个任务有很多小文件（远远小于块大小 128m），则每个小文件也会被当做一个块，用一个 map 任务来完成，而一个 map 任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的 map 数是受限的。

• 4）是不是保证每个 map 处理接近 128m 的文件块，就高枕无忧了？

答案也是不一定。比如有一个 127m 的文件，正常会用一个 map 去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果 map 处理的逻辑比较复杂，用一个 map 任务去做，肯定也比较耗时。

针对上面的问题 3 和 4，我们需要采取两种方式来解决：即减少 map 数和增加 map 数；

2. 从 reduce 数量

• 1）调整 reduce 个数方法一

每个Reduce处理的数据量默认是256MB	hive.exec.reducers.bytes.per.reducer=256123456每个任务最大的reduce数，默认为1009	hive.exec.reducers.max=1009计算reducer数的公式	N=min(参数2，总输入数据量/参数1)

• 2）调整 reduce 个数方法二

在 hadoop 的 mapred-default.xml 文件中修改

设置每个 job 的 Reduce 个数

set mapreduce.job.reduces = 15;

• 3）reduce 个数并不是越多越好

1）过多的启动和初始化 reduce 也会消耗时间和资源；

2）另外，有多少个 reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；

在设置 reduce 个数的时候也需要考虑这两个原则：处理大数据量利用合适的 reduce 数；使单个 reduce 任务处理数据量大小要合适；