- Subscribe to RSS Feed
- Mark Question as New
- Mark Question as Read
- Float this Question for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Optimize a long running hive query - has a join with same table
- Labels:
-
Apache Hive
-
Apache Tez
Created ‎12-13-2015 08:23 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Neeraj Sabharwal @Jean-Philippe Player Explain Plan file is attached..
Created ‎12-24-2015 03:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Table
STAGE_SOURCE
is already in ORC format.
Created ‎12-26-2015 01:39 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Sooraj Antony has this been resolved? Can you post your solution or accept the best answer?
