map和reduce数量调整
是map数越多越好?
答案是否定的。如果一个任务有很多小文件(远远小于块大小128m),则每个小文件也会被当做一个块,用一个map任务来完成,而一个map任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。而且,同时可执行的map数是受限的。
是不是保证每个map处理接近128m的文件块,就高枕无忧了?
答案也是不一定。比如有一个127m的文件,正常会用一个map去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果map处理的逻辑比较复杂,用一个map任务去做,肯定也比较耗时。
是不是reduce数越多越好?
答案是否定的。如果reduce设置的过大,对整个作业会产生一定的影响。 ①过多的启动和初始化reduce也会消耗时间和资源; ②另外,有多少个reduce,就会有多少个输出文件,如果生成了很多个小文件,那么如果这些小文件作为下一个任务的输入,则也会出现小文件过多的问题;
Maptask个数调整
-- 小文件场景 -- 每个Map最大输入大小(这个值决定了合并后文件的数量) set mapred.max.split.size=112345600; -- 一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并) set mapred.min.split.size.per.node=112345600; -- 一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并) set mapred.min.split.size.per.rack=112345600; -- 执行Map前进行小文件合并 set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 大文件场景, 增加Map数 set mapred.reduce.tasks=10;
Reducetask个数调整
-- 总共受3个参数控制: -- 每个Reduce处理的数据量默认是256MB hive.exec.reducers.bytes.per.reducer=256123456 -- 每个任务最大的reduce数,默认为999 hive.exec.reducers.max=999 -- mapreduce.job.reduces -- 该值默认为-1,由hive自己根据任务情况进行判断。也可以手动控制 set mapreduce.job.reduces = 8;
注意: 以下几种, 不管如何设置, 最终翻译后reduce只能有一个
执行order by操作
执行不需要group by直接聚合的操作
执行笛卡尔积