[
https://issues.apache.org/jira/browse/KYLIN-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775621#comment-16775621
]
KANG-SEN LU commented on KYLIN-3322:
------------------------------------
I am disappointed that kylin group takes this approach to solve this problem.
I know that in the sample project, we have only one cube designed, so the
TOPN(SUM(X), GROUP-BY-B) does come with SUM(X).
But what if some project needs to have two cube design. One for non-TOPN
application, and the other for purely TOPN application. Now we may end up with
both cube can support SUM(X) and one query may be routed to the wrong cube and
costs long execution.
Even worse, if a SUM(X) query was supposed to be routed to non-TOPN cube, but
now TOPN cube also satisfy the require. So the SUM(X) query is routed to the
TOPN cube. In side the TOPN-cube, the correct answer would be go after the
SUM(X) metric directly. But my experiment seems to suggest the kylin took the
path of going after TOPN(SUM(X)), then sum over the dimension B, which in
general has a hugh cardinality, and therefore, takes a long tim eto finish.
Now the question is that if you add documentation to inform user that SUM(X) is
required if TOPN(SUM(X)) is configured. Then can you make sure the proper
metric is used in case non-TOPN metric is accessed.
> TopN requires a SUM to work
> ---------------------------
>
> Key: KYLIN-3322
> URL: https://issues.apache.org/jira/browse/KYLIN-3322
> Project: Kylin
> Issue Type: Bug
> Components: Measure - TopN
> Reporter: liyang
> Assignee: Na Zhai
> Priority: Major
>
> Currently if user creates a measure of TopN seller by sum of price, it is
> required that user also creates a measure of SUM(price). Otherwise, NPE will
> be thrown at query time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
