Created 12-13-2015 08:23 PM
The below query takes a lot of time to execute. It is run with tez execution engine.
SELECT STG.EMP_TYPE,DEPT,COUNT(DISTINCT EMP_ID) AS COUNT, A.TOTAL_COUNT FROM STAGE_SOURCE STG LEFT OUTER JOIN (SELECT EMP_TYPE,COUNT(DISTINCT EMP_ID) AS TOTAL_COUNT FROM STAGE_SOURCE GROUP BY EMP_TYPE) A ON STG.EMP_TYPE = A.EMP_TYPE GROUP BY STG.EMP_TYPE,DEPT,A.TOTAL_COUNT;
Is there any rewrite option or optimization strategy which can improve the query performance?
The subquery with alias "A" itself takes 2-3hrs to execute.
Attaching the explain plan of just the join subquery "A"
Created 12-28-2015 07:54 PM
I believe the problem is most of records has same value for EMP_TYPE (aka skewed records), that would cause all records from same EMP_TYPE value to be sent to same reducer and would cause the last reducer to take a long time to finish.
Assuming you have small number of different values of EMP_TYPE (and the result fit in memory), try solution below:
set hive.ignore.mapjoin.hint=false; SELECT /*+ MAPJOIN(A) */ STG.EMP_TYPE,DEPT,COUNT(DISTINCT EMP_ID) AS COUNT, A.TOTAL_COUNT FROM STAGE_SOURCE STG LEFT OUTER JOIN (SELECT EMP_TYPE,COUNT(DISTINCT EMP_ID) AS TOTAL_COUNT FROM STAGE_SOURCE GROUP BY EMP_TYPE) A ON STG.EMP_TYPE = A.EMP_TYPE GROUP BY STG.EMP_TYPE,DEPT,A.TOTAL_COUNT;
Created 12-14-2015 12:22 AM
@Sooraj Antony Please attach explain plan. You can copy the plan in text and upload in pdf format.
Created 12-16-2015 06:35 PM
The COUNT(DISTINCT) could be the bottleneck if it is not being parallelized. Can you share the explain plan ?
Created 12-17-2015 07:33 PM
@Neeraj Sabharwal @Jean-Philippe Player Explain Plan file is attached..
Created 12-24-2015 03:53 AM
some obvious optimizations would be to convert the tables to ORC, you're using text, the tables are pretty large and ORC can help by skipping batches of rows that don't match the criteria. Another thing to look at is table ordering, here's more info https://cwiki.apache.org/confluence/display/Hive/OuterJoinBehavior and https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34015666
Created 12-26-2015 08:25 PM
Table
STAGE_SOURCE
is already in ORC format.
Created 12-26-2015 01:39 PM
please check, if set hive.map.aggr=true or not.
Please change the table to ORC format and try to run only subquery. I hope, results should come fast.
Please check, if table can be bucketed on emp_type or not. try to implement SMB join.
Created 12-26-2015 08:28 PM
The table is in ORC and haven't tried SMB, but the process is getting stuck at the last reducer and the whole processing runs in a single node while other nodes are idle.
Can you explain the function of "hive.map.aggr" parameter?
Created 12-28-2015 07:54 PM
I believe the problem is most of records has same value for EMP_TYPE (aka skewed records), that would cause all records from same EMP_TYPE value to be sent to same reducer and would cause the last reducer to take a long time to finish.
Assuming you have small number of different values of EMP_TYPE (and the result fit in memory), try solution below:
set hive.ignore.mapjoin.hint=false; SELECT /*+ MAPJOIN(A) */ STG.EMP_TYPE,DEPT,COUNT(DISTINCT EMP_ID) AS COUNT, A.TOTAL_COUNT FROM STAGE_SOURCE STG LEFT OUTER JOIN (SELECT EMP_TYPE,COUNT(DISTINCT EMP_ID) AS TOTAL_COUNT FROM STAGE_SOURCE GROUP BY EMP_TYPE) A ON STG.EMP_TYPE = A.EMP_TYPE GROUP BY STG.EMP_TYPE,DEPT,A.TOTAL_COUNT;
Created 02-03-2016 02:41 AM
@Sooraj Antony has this been resolved? Can you post your solution or accept the best answer?