[Hive]从一个经典案例看优化mapred.map.tasks的重要性
来源:互联网 发布:phxpaxos源码分析 编辑:程序博客网 时间:2024/05/02 08:08
我所在公司所使用的生产Hive环境的几个参数配置如下:
dfs.block.size=268435456
hive.merge.mapredfiles=true
hive.merge.mapfiles=true
hive.merge.size.per.task=256000000
mapred.map.tasks=2
因为合并小文件默认为true,而dfs.block.size与hive.merge.size.per.task的搭配使得合并后的绝大部分文件都在300MB左右。
CASE 1:
现在我们假设有3个300MB大小的文件,那么goalsize = min(900MB/2,256MB) = 256MB
所以整个JOB会有6个map,其中3个map分别处理256MB的数据,还有3个map分别处理44MB的数据。
这时候木桶效应就来了,整个JOB的map阶段的执行时间不是看最短的1个map的执行时间,而是看最长的1个map的执行时间。所以,虽然有3个map分别只处理44MB的数据,可以很快跑完,但它们还是要等待另外3个处理256MB的map。显然,处理256MB的3个map拖了整个JOB的后腿。
CASE 2:
如果我们把mapred.map.tasks设置成6,再来看一下有什么变化:
goalsize = min(900MB/6,256MB) = 150MB
整个JOB同样会分配6个map来处理,每个map处理150MB的数据,非常均匀,谁都不会拖后腿,最合理地分配了资源,执行时间大约为CASE 1的59%(150/256)
案例分析:
虽然mapred.map.tasks从2调整到了6,但是CASE 2并没有比CASE 1多用map资源,同样都是使用6个map。而CASE 2的执行时间约为CASE 1执行时间的59%。
从这个案例可以看出,对mapred.map.tasks进行自动化的优化设置其实是可以很明显地提高作业执行效率的。
- [Hive]从一个经典案例看优化mapred.map.tasks的重要性
- [Hive]从一个经典案例看优化mapred.map.tasks的重要性
- [Hive]从一个经典案例看优化mapred.map.tasks的重要性
- 从一个经典案例看优化mapred.map.tasks的重要性
- mapred.map.tasks 如何影响map的个数
- mapred.map.tasks 如何影响map的个数
- hadoop中mapred.tasktracker.map.tasks.maximum的设置
- hadoop中mapred.tasktracker.map.tasks.maximum的设置
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- map和reduce 个数的设定 (Hive优化)经典
- tomcat手动部署项目
- xfire发布ws服务-同名函数问题
- struts2访问request、session、servletContext属性
- Python+Django+SAE系列教程11-----request/pose/get/表单
- Merge k Sorted Lists
- [Hive]从一个经典案例看优化mapred.map.tasks的重要性
- tomcat修改端口
- socket(AF_INET,SOCK_RAW,IPPROTO_IP)的意思
- alertdilog加载一个gridview页面并实现gridView中每个imagebutton的点击事件
- leetcode:Anagrams
- 蓝牙技术
- 查看操作系统位数
- 淘气包弟弟
- 基于地理位置信息的traceroute