一、嵌套查询统计数量去重问题
描述:如果子查询中对统计的字段已经去重,外面一层就不能同时有distinct(目标统计字段)和group by操作,否则查询结果不是统计的数量而是统计的字段数据。
如:
select
- platform_id, count(distinct user_id) uv_count
from
- (
- select
- platform_id, user_id, sum(pv) pv
- where day = '20140201'
- and (
- platform_id = 12
- or platform_id = 6
- or platform_id = 11
- or platform_id = 14
- )
- and (
- select
group by platform_id
limit 10;
查询结果:
- 6 10000242
- 6 10000332
- 6 10000468
- 6 10001799
- 6 10001809
- 6 10002210
- 6 10002753
- 6 10003070
- 6 10003815
- 6 10004929
解释:该查询中里面嵌套的一层已经group by user_id所以user_id不会有重复,最外层再distinct user_id同时group by platform_id时,查询的结果就成了platform_id和user_id而不是count出来的数量,如果distinct和group by只有其中一个操作就不会有这种现象。
解决办法:将count(distinct user_id) 改为count(user_id).
二、多次嵌套查询聚合问题
描述:如果子查询嵌套的层次过多,同时查询的数据量较大,在自由分配的情况下数据会被分到多个reducers中分别计算,计算完成后不会再进行聚合,而是把每个reduce算完的结果查询出来。
如:
查询结果:
select a.userid,sum(a.pv) pv
- from(
- select c.userid,c.bookid,c.url,count(1) pv from(
- select userid,bookid,url
- from log
- where day='20140201'
- and logtype='access'
- and project='android'
- and actionname='read'
-
and (apiCode= or apiCode ='100')
-
- select userid,bookid,url
- ) c
- group by c.userid,c.bookid,c.url
- select c.userid,c.bookid,c.url,count(1) pv from(
查询结果:
- 21057243 5
- 21057243 16
- 21057243 5
- 21057243 16
- 21057243 8
查询时分配的mappers和reducers:
- number of mappers: 635; number of reducers: 6
解释:该查询的最外层已经有group by userid,按正常逻辑最后查询结果应该是一条数据,但是在查询过程中分配了6个reducers最后就把6个分别查出来,很容易导致最后统计错误。
解决方法:在查询时将reducers设为1,即set mapred.reduce.tasks=1;