温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

TEZ MRR optimize to MR?

发布时间:2020-06-16 19:33:51 来源:网络 阅读:694 作者:r7raul 栏目:大数据

https://issues.apache.org/jira/browse/HIVE-2340

select userid,count(*) from u_data group by userid order by userid    will product MRR.

 

I think when the result of  userid,count(*) is small(one reduce can process the result) . This query plan can optimize to MR ?


To prevent bad reducer merging, the reducer merging only kicks in when the

optimizer thinks it gets a perf boost.

 

MR -> MRR is not a big win when it comes Tez, due to container-reuse -

going wide on the large cardinality in case of missing map-side

aggregation will be safer.

 

If hive.map.aggr=true and the userid set fits within memory, then smushing

the reducers would be nicer.

 

To reset the wide-narrow checks, do

 

set hive.optimize.reducededuplication.min.reducer=1;

 

 

But be aware that it will fail (I1ve seen full disks) as you scale upwards

to the 10+ Tb cases.

 

Cheers,

Gopal

hive.optimize.reducededuplication.min.reducer
  • Default Value: 4

  • Added In: Hive 0.11.0 with HIVE-2340

Reduce deduplication merges two RSs (reduce sink operators) by moving key/parts/reducer-num of the child RS to parent RS. That means if reducer-num of the child RS is fixed (order by or forced bucketing) and small, it can make very slow, single MR. The optimization will be disabled if number of reducers is less than specified value.


向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI