1.Map数
1.1 通常情况下，作业会通过input的目录产生一个或者多个map任务
主要的决定因素有：input的文件总个数，input的文件大小，集群设置的文件块大小(目前为128M，可在hive中通过set dfs.block.size;命令查看到)；
map task的数量即mapred.map.tasks的参数值，用户不能直接设置这个参数。Input Split的大小，决定了一个Job拥有多少个map。 mapred.min.split.size这个配置项决定了每个 Input Split的最小值，用户可以修改这个参数（mapred.min.split.size），从而改变map task的数量。
1.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)，那么会拆分，如果小于块大小，则把该文件当成一个块。
1.3 是不是map数越多越好？
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m），则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限的。
1.4 是不是保证每个map处理接近128m的文件块，就高枕无忧了？
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。
针对上面的问题3和4，我们需要采取两种方式来解决：即减少map数和增加map数；
减少map数（合并小文件）
| --假设一个SQL任务： select count(1) from tab_info where pt = '2020-07-04'; --该任务共有194个文件，其中很多是远远小于128M的小文件，总大小9G，正常执行会用194个map任务。 --Map总共消耗的计算资源：SLOTS_MILLIS_MAPS= 623,020
--通过以下方法来在map执行前合并小文件，减少map数： set mapred.max.split.size=112345600; set mapred.min.split.size.per.node=112345600; set mapred.min.split.size.per.rack=112345600; --这三个参数确定合并文件块的大小，大于文件块大小128m的，按照128m来分隔， --小于128m,大于100m的，按照100m来分隔，把那些小于100m的（包括小文件和分隔大文件剩下的）， --进行合并,最终生成了74个块。
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; --这个参数表示执行前进行小文件合并，
--再执行上面的语句，用了74个map任务，map消耗的计算资源：SLOTS_MILLIS_MAPS= 333,500 --对于这个简单SQL任务，执行时间上可能差不多，但节省了一半的计算资源。 |
增加Map数
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率。
| --假设有这样一个任务： select data_desc, count(1), count(distinct id), sum(case when ...), sum(case when ...), sum(...) from a group by data_desc /* 如果表a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的， 这种情况下，我们要考虑将这一个文件合理的拆分成多个， 这样就可以用多个map任务去完成。 */ set mapred.reduce.tasks=10; map task的数量即mapred.map.tasks的参数值，用户不能直接设置这个参数。Input Split的大小，决定了一个Job拥有多少个map。 mapred.min.split.size这个配置项决定了每个 Input Split的最小值，用户可以修改这个参数，从而改变map task的数量。 reduce task的数量由mapred.reduce.tasks这个参数设定，默认值是1。 create table a_1 as select * from tab_info distribute by rand(123); distribute by是控制在map端如何拆分数据给reduce端的。hive会根据distribute by后面列，对应reduce的个数进行分发，默认是采用hash算法. 大部分情况都用于解决Map输出的文件大小不均,Reduce输出文件大小不均,小文件过多,文件超大等情况. 当 distribute by 后边跟的列是：rand()时，即保证每个分区的数据量基本一致 /* 这样会将a表的记录，随机的分散到包含10个文件的a_1表中，再用a_1代替上面sql中的a表，则会用10个map任务去完成。 每个map任务处理大于12M（几百万记录）的数据，效率肯定会好很多。 */ 扩展：
|
2.Reduce数
如果Reduce设置的过大，那么将会产生很多小文件，对NameNode会产生一定的影响，而且整个作业的运行时间未必会减少；如果Reduce设置的过小，那么单个Reduce处理的数据将会加大，很可能会引起OOM异常（outofmemory的简称,称之为内存溢出）。
如果设置了mapred.reduce.tasks/mapreduce.job.reduces参数，那么Hive会直接使用它的值作为Reduce的个数；如果mapred.reduce.tasks/mapreduce.job.reduces的值没有设置（也就是-1），那么Hive会根据输入文件的大小估算出Reduce的个数。
根据输入文件估算Reduce的个数可能未必很准确，因为Reduce的输入是Map的输出，而Map的输出可能会比输入要小，所以最准确的是根据Map的输出估算Reduce的个数。
Hive自己如何确定reduce数
不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定：
hive.exec.reducers.bytes.per.reducer（每个reduce任务处理的数据量，默认为1000^3=1G）
hive.exec.reducers.max（每个任务最大的reduce数，默认为999）
计算reducer数的公式很简单N=min（参数2，总输入数据量/参数1），即如果reduce的输入（map的输出）总大小不超过1G，那么只会有一个reduce任务；
调整reduce个数方法一：
调整hive.exec.reducers.bytes.per.reducer参数的值：set hive.exec.reducers.bytes.per.reducer=
调整reduce个数方法二：
set mapred.reduce.tasks=
reduce个数并不是越多越好：
同map一样，启动和初始化reduce也会消耗时间和资源；
有多少个reduce，就会有个多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；
什么情况下只有一个reduce：
1.数据量小于hive.exec.reducers.bytes.per.reducer参数值
2.没有group by的汇总
3.用了Order by
4.有笛卡尔积
注意：在设置reduce个数的时候也需要考虑这两个原则：使大数据量利用合适的reduce数；是单个reduce任务处理合适的数据量；
939
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
