[
https://issues.apache.org/jira/browse/HIVE-23356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097997#comment-17097997
]
Hive QA commented on HIVE-23356:
--------------------------------
Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/13001884/HIVE-23356.02.patch
{color:green}SUCCESS:{color} +1 due to 1 test(s) being added or modified.
{color:green}SUCCESS:{color} +1 due to 17196 tests passed
Test results:
https://builds.apache.org/job/PreCommit-HIVE-Build/22078/testReport
Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/22078/console
Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-22078/
Messages:
{noformat}
Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}
This message is automatically generated.
ATTACHMENT ID: 13001884 - PreCommit-HIVE-Build
> Hash aggregation is always disabled while processing querys with grouping
> sets expressions.
> -------------------------------------------------------------------------------------------
>
> Key: HIVE-23356
> URL: https://issues.apache.org/jira/browse/HIVE-23356
> Project: Hive
> Issue Type: Bug
> Components: Hive, Operators, Query Processor
> Affects Versions: All Versions
> Reporter: Qiang.Kang
> Assignee: Qiang.Kang
> Priority: Critical
> Labels: performance
> Attachments: HIVE-23356.01.patch, HIVE-23356.02.patch,
> HIVE-23356.03.patch
>
>
> Hi, we find that many MapReduce map attempts disable hash aggregation while
> processing GroupBy Operator with grouping sets expressions. Logs are just
> like this:
> `Disable Hash Aggr: #hash table = 104427 #total = 100000 reduction = 1.0
> minReduction = 0.5`, which means hashTable size is even larger than the
> number of input rows.
> Dig deeper we can find that GroupBy operator disables hash aggregation just
> based on the number of input rows instead of rows actually processed. For
> GroupBy Operator with grouping sets (such as: roll up, cube, etc.),
> `numberRowsProcessed` equals `groupingSets.size()*numberRowsInput`, causing
> hashTableSize much larger than querys without grouping sets expressions.
> Let's consider a example below:
> - Query:
> SELECT col1, col2, MAX(col0) FROM tbl GROUP BY col1, col2 GROUPING SETS
> (col1,col2);
> - Input data:
> col0, col1, col2
> [0,-1,-1]
> [1,-1,-1]
> [2,-1,-1]
> [3,3,3]
> [4,4,4]
> - Configuration:
> hive.groupby.mapaggr.checkinterval = 1;
> minReductionHashAggr = 0.5;
> - Currently, there are 10 rows in partial aggregate result. (hash aggregation
> is disabled very early):
> [-1, null, 0]
> [null, -1, 0]
> [-1, null, 1]
> [null, -1, 1]
> [-1, null, 2]
> [null, -1, 2]
> [3, null, 3]
> [null, 3, 3]
> [4, null, 4]
> [null, 4, 4]
> The patch below disables hash aggregation based on the number of rows
> actually processed, reducing partial result entries a lot and improving the
> performance of aggregation. There are only 6 rows in partial aggregate result:
> [-1, null, 2]
> [null, -1, 2]
> [null, 3, 3]
> [4, null, 4]
> [null, 4, 4]
> [3, null, 3]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
