hive的map数量和reduce数量控制
参考文档:
- https://blog.csdn.net/may_fly/article/details/102888436
- https://blog.csdn.net/javastart/article/details/91381168
- https://blog.csdn.net/qq_23596677/article/details/99587559
- (mapreduce内存分配)https://blog.csdn.net/u014665013/article/details/80923044
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任务处理合适的数据量。
听上去好像没说什么
网友评论