hive的map数量和reduce数量控制

参考文档：

map数量控制

map数量由以下几个因素确定

输入文件的总个数
输入文件的大小
集群设置的文件块大小（默认128M，可在hive shell中通过set dfs.block.size查看，单位byte）

举例

文件不足128M则当做一个块，大于128M则拆分

input目录下有七个文件，大小均为64M，则共7个map
input目录下有10M，10M，129M三个文件，则共4个map，其中129M拆分为128M+1M两个文件
input目录下有10M，10M，257M三个文件，则共5个map，其中129M拆分为128M+128M+1M三个文件

map数量应该控制在多少

map数量不是越多越好

如果有过多的小文件(大小远不够128M)，则每个小文件也会当做一个块，甚至计算时间没有map任务的启动和初始化时间，则会造成资源的浪费。

解决方案：合并小文件，减少map数，可通过设置如下参数解决：

map输入时合并小文件

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;  #执行Map前进行小文件合并
set mapred.max.split.size=128000000;  #每个Map最大输入大小，单位为KB
set mapred.min.split.size.per.node=100000000; #一个节点上split的至少的大小，单位为KB
set mapred.min.split.size.per.rack=100000000; #一个交换机下split的至少的大小，单位为KB

map输出时合并小文件

set hive.merge.mapfiles = true #在Map-only的任务结束时合并小文件
set hive.merge.mapredfiles = true #在Map-Reduce的任务结束时合并小文件
set hive.merge.sparkfiles = true #在hive on spark任务后开启合并小文件
set hive.merge.size.per.task = 256*1000*1000 #合并文件的大小
set hive.merge.smallfiles.avgsize=16000000 #当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件merge

小文件合并待验证

保证map处理的所有文件块都接近128M，效率也不一定高

如果文件中只有一两个字段，则有过多条数据，此时在一个map中会执行的很慢。当任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率

解决方案为：计算每个文件块合适大小maxSize，然后设置以下参数来将文件切分为，文件大小为maxSize的小文件

set mapreduce.input.fileinputformat.split.maxsize=maxSize;

问题：怎样才算复杂的任务逻辑？map阶段可以做哪些复杂的业务逻辑？进而如何具体操作，确定块的大小？（是通过试验摸索吗）

同时存在大文件切分和小文件合并是必要的吗？

答：在实际处理数据的时候存在多种多样的情况，根据实际情况控制map数量需要遵从两个原则：

大量数据处理需要合适的map数量

单个map任务处理需要合适的数据量。

只有把握好这两点才能最大效率的处理数据(类似生活中，一件工作安排给多个人会快一些，但是安排过多的人并不会让任务更快的完成，相反给这么多人安排工作是一件非常费力的事情)。

reduce数量控制

reduce个数的设定极大影响任务的执行效率

reduce数量如何计算

不指定reduce个数的情况下，hive会基于以下两个参数计算reduce的个数

hive.exec.reducers.bytes.per.reducer，如果要处理的数据大小不大于这个值，则只有1个reduce，否则会有：数据量 / hive.exec.reducers.bytes.per.reducer个reduce。注意这个数据量是map之前的数据文件大小，所以和map输出的数据量并不一致，只是一种估算。

hive.exec.reducers.max，总的reduce数量不会超过这个值。

具体到reduce数据推算的细节请阅读下面文章
《hive中reducetask数量是怎么推算的》。文章里面有代码讲解。以下是节选的一些内容：

hive.exec.reducers.bytes.per.reducer

此参数从Hive 0.2.0开始引入。在Hive 0.14.0版本之前默认值是1G(1,000,000,000)；而从Hive 0.14.0开始，默认值变成了256M(256,000,000)，可以参见HIVE-7158和HIVE-7917。这个参数的含义是每个Reduce处理的字节数。比如输入文件的大小是1GB，那么会启动4个Reduce来处理数据。

hive.exec.reducers.max

此参数从Hive 0.2.0开始引入。在Hive 0.14.0版本之前默认值是999；而从Hive 0.14.0开始，默认值变成了1009；可以参见HIVE-7158和HIVE-7917。这个参数的含义是最多启动的Reduce个数。比如input size/hive.exec.reducers.bytes.per.reducer>hive.exec.reducers.max，那么Hive启动的Reduce个数为hive.exec.reducers.max；反之为input size/hive.exec.reducers.bytes.per.reducer。这个参数只有在mapred.reduce.tasks/mapreduce.job.reduces设置为负数的时候才有效。

mapred.reduce.tasks/mapreduce.job.reduces

此参数从Hive 0.1.0开始引入。默认值是-1。此参数的含义是Reduce的个数，典型的情况是设置成接近可用节点的质数。如果mapred.job.tracker的值是local此参数将会被忽略。在Hadoop中此参数的默认值是1；而在Hive中默认值是-1。通过将此参数设置为-1，Hive将自动计算出应该启动多少个Reduce。

如何调整reduce的数量

设置hive.exec.reducers.bytes.per.reducer的大小。

在hadoop的mapred-default.xml中设置reduce的个数或通过hive shell设置set mapreduce.job.reduces=reduceNum;来硬性规定reduce的个数。一般set mapreduce.job.reduces=-1，这样生效的是上面1里面的参数hive.exec.reducers.bytes.per.reducer。如果set mapreduce.job.reduces某一个具体值，那就会固定死这个值了。

reduce数量设置多少合适？

reduce个数不是越多越好

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

有多少个reduce就会有多少个输出文件，如果生成了很多小文件，如果这些小文件作为下一个任务的输入，则也会出现效率问题

为何有时候设置的reduce数量不起作用？一直是1个reduce？

只有一个reduce的情况，有时候会出现不过多大数据量和怎么硬性规定都只有一个reduce，共有三种情况会导致这种结果：这三种情况都是全局的，不得不使用一个reduce来完成。

没有使用group by这类汇总

使用了order by

有笛卡尔积

关于这三种情况下面这篇文章更详细一点：
https://blog.csdn.net/javastart/article/details/91381168

reduce设置原则

在设置reduce个数的时候也需要考虑这两个原则：

使大数据量利用合适的reduce数；

使单个reduce任务处理合适的数据量。

听上去好像没说什么

hive如何调整map和reduce的数量