[
https://issues.apache.org/jira/browse/HIVE-19586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479891#comment-16479891
]
slim bouguerra commented on HIVE-19586:
---------------------------------------
After Talking with [~ashutoshc] Offline we decided to tackle the simple case
first.
This patch will allow us to expand an aggregate with single count distinct and
valid Druid aggregates as a series of Group by. Thus this will lead to a plan
where the first GB is executed by Druid while the rest will be done in HIVE.
The next step will be to fix the couple of related issue and enable push down
of Grouping set down to Druid once it is supported.
> Optimize Count(distinct X) pushdown based on the storage capabilities
> ----------------------------------------------------------------------
>
> Key: HIVE-19586
> URL: https://issues.apache.org/jira/browse/HIVE-19586
> Project: Hive
> Issue Type: Improvement
> Components: Druid integration, Logical Optimizer
> Reporter: slim bouguerra
> Assignee: slim bouguerra
> Priority: Major
> Fix For: 3.0.0
>
> Attachments: HIVE-19586.patch
>
>
> h1. Goal
> Provide a way to rewrite queries with combination of COUNT(Distinct) and
> Aggregates like SUM as a series of Group By.
> This can be useful to push down to Druid queries like
> {code}
> select count(DISTINCT interval_marker), count (distinct dim), sum(num_l)
> FROM druid_test_table GROUP BY `__time`, `zone` ;
> {code}
> In general this can be useful to be used in cases where storage handlers can
> not perform count (distinct column)
> h1. How to do it.
> Use the Calcite rule {code}
> org.apache.calcite.rel.rules.AggregateExpandDistinctAggregatesRule{code} that
> breaks down Count distinct to a single Group by with Grouping sets or
> multiple series of Group by that might be linked with Joins if multiple
> counts are present.
> FYI today Hive does have a similar rule {code}
> org.apache.hadoop.hive.ql.optimizer.calcite.rules.HiveExpandDistinctAggregatesRule{code},
> but it only provides a rewrite to Grouping sets based plan.
> I am planing to use the actual Calcite rule, [~ashutoshc] any concerns or
> caveats to be aware of?
> h2. Concerns/questions
> Need to have a way to switch between Grouping sets or Simple chained group by
> based on the plan cost. For instance for Druid based scan it makes always
> sense (at least today) to push down a series of Group by and stitch result
> sets in Hive later (as oppose to scan everything).
> But this might be not true for other storage handler that can handle Grouping
> sets it is better to push down the Grouping sets as one table scan.
> Am still unsure how i can lean on the cost optimizer to select the best plan,
> [~ashutoshc]/[~jcamachorodriguez] any inputs?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
