一般情况下，启动一个hive任务时hive会计算这个任务需要用到的map和reduce数量，通常map数和reduce数不需要调整。但是有时如果map或reduce的计算很复杂、单个map的执行时间很长，且hive分配的map数或reduce比较少，集群还有大量计算资源没有利用的情况下，可以通过增大map数或reduce数，来提高任务并发，缩短任务计算时长，提高计算效率。
1、hive on mr
1.1、如何调整map数
InputFormat 接口按照某个策略将输入数据且分成若干个 split，以便确定 Map Task 的个数即 Mapper 的个数，在 MapReduce 框架中，一个 split 就意味着需要一个 Map Task;
当hive.input.format=org.apache.hadoop.hive.ql.io.HiveInputFormat时，hive会先计算splitSize ，然后通过splitSize、任务输入的数据量大小和文件数来共同决定split数量，即map数。
splitSize = max{minSize,min{goalSize,blockSize}}
其中
- minSize：是
mapreduce.input.fileinputformat.split.minsize决定的 InputFormat的最小长度。 - goalSize：该值由
totalSize/numSplits来确定 InputSplit 的长度，它是根据用户的期望的 InputSplit 个数计算出来的。numSplits为用户设定的 Map Task 的个数，默认为1，可通过mapreduce.job.maps设置。totalSize是hive任务处理的数据量大小。 - blockSize：HDFS 中的文件存储块block的大小，可以通过
dfs.blocksize查看大小。
由上公式可知，在org.apache.hadoop.hive.ql.io.HiveInputFormat接口下，主要是mapreduce.input.fileinputformat.split.minsize和mapreduce.job.maps来决定map数
当hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat时，主要是如下四个参数起作用：
mapreduce.input.fileinputformat.split.minsizemapreduce.input.fileinputformat.split.maxsizemapreduce.input.fileinputformat.split.minsize.per.rack-
mapreduce.input.fileinputformat.split.minsize.per.node
这里切分的逻辑比较复杂，主要的流程大致如下：
- 首先处理每个Datanode的blockInfo，先按照>=maxsplitsize来切分split，剩余的再按照blockinfo>=minSplitSizeNode切分，其余的等和rack的其余blockinfo进行合并。
- 其次对每个Rack进行处理：先按照>=maxsplitsize来切分split，剩余的再按照blockinfo>=minSplitSizeRack切分，其余的等和overflow的其余blockinfo进行合并。
- 对于overflow blockInfo直接根据maxsplitsize来进行切分。
1.2 如何调整reduce数
hive on mr模式下reduce数主要受如下两个参数影响：
-
hive.exec.reducers.bytes.per.reducer--每个reduce处理的数量量 -
hive.exec.reducers.max--hive任务最大reduce个数
reducer数 = min(hive.exec.reducers.max,max(1,totalsize/hive.exec.reducers.bytes.per.reducer))
2、hive on tez
2.1、如何调整map数
在运行hive on tez时会发现跟hive on mr的map数差异会比较大，主要原因在于 Tez 中对 inputSplit 做了 grouping 操作，将多个 inputSplit 组合成更少的 groups，然后为每个 group 生成一个 mapper 任务，而不是为每个inputSplit 生成一个mapper 任务。
可以通过调整如下参数来调整grouping数：
tez.grouping.min-sizetez.grouping.max-size
2.2、如何调整reduce数
tez on tez模式下reduce数主要受如下两个参数影响：
-
hive.exec.reducers.bytes.per.reducer--每个reduce处理的数量量 -
hive.exec.reducers.max--hive任务最大reduce个数 hive.tez.auto.reducer.parallelism-
hive.tex.min.partition.factor
-hive.tez.max.partition.factor
reducer数 = Max(1, Min(hive.exec.reducers.max, ReducerStage estimate/hive.exec.reducers.bytes.per.reducer))x hive.tez.max.partition.factor
3、其他影响map数和reduce数的情况
3.1 小文件合并
hive.merge.mapfiles = true #在Map-only的任务结束时合并小文件
hive.merge.mapredfiles = true #在Map-Reduce的任务结束时合并小文件
hive.merge.size.per.task = 256*1000*1000 #合并文件的大小
hive.merge.smallfiles.avgsize=16000000 #当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件merge
上面参数会在任务结束后，如果任务生成的小文件触发了hive.merge.smallfiles.avgsize=会另外再启reduce任务来合并小文件。
3.2 分桶表的影响
如果往分桶表里插入数据，由于hdfs最终会每个桶一个文件，因此在当分桶表设置了多少个桶，最终就会生成多少个reduce任务
3.3 只一个个redecu的情况
- 执行全局聚合，例如语句：
select count(*),sum(field1) from tablea - 做笛卡尔集操作
- 执行order by 操作
3.4 map阶段不支持拆分的情况
有的文件格式并不支持切分，如果hive表的存储的文件格式不支持切分，则在查询该表时，有多少文件就会产生多少map任务。例如，存储格式是text，但是采用了gzip压缩，这种情况下则不支持切分，读表数据时，该表对应的存储目录下有多少个文件就会生成多少个map任务，每个map任务处理一个文件的数据。
4、map数和reduce数设置多少最合适？
map数和reduce数并非越多越好，需要综合多种情况来考虑
- 任务的计算复杂度：处理同样数据量，计算逻辑越复杂，任务耗时会越长
- hdfs文件系统的元数据的压力：如果生成的小文件很多，hdfs元数据会增长很快，会增加hdfs的元数据压力
- 整合集群的计算资源
一般情况下不需要调整map数和reduce数，当单个map执行时间过长时，且map数不多的情况下，就需要通过调整map数，通过提高map数，提高并发来缩短单个map的执行时间，从而缩短整合任务的计算时间。同样reduce阶段单个reduce处理数据量很大，耗时比较长时，而分配的reduce数不多的情况下，也可以通过提高reduce数来减少每个reudce的计算时长。
那单个map执行多少时间为宜：根据在大数据集群上的实践经验，单个map宜在1-2分钟执行完是比较好，如果单个map执行时间太短，会消耗比较多的时间在申请集群资源和初始化资源阶段，反倒影响整体任务效率；如果单个map执行时间太长，长时间占用集群资源，不能及时释放资源，导致其他任务长时间等待，不利于集群计算资源的合理利用。
同样，reduce任务阶段，一般执行会比较长，因此reduce阶段不reduce数不宜太多，一般不超过集群cores数的50%，太多会占用大量集群资源，导致其他任务获取不到资源而排队，同时也会生成过多的文件。
