kylin-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yerui Sun (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KYLIN-1313) Enable deriving dimensions on non PK/FK
Date Thu, 14 Jan 2016 07:52:39 GMT

    [ https://issues.apache.org/jira/browse/KYLIN-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097779#comment-15097779
] 

Yerui Sun commented on KYLIN-1313:
----------------------------------

Thanks for your clearly explanation with many details.
I agreed with the trade off between functionality and performance, only item_id could be filtered
is acceptable. If there's indeed requirements  for item_url filtering, it can be added as
a individually dimension, right?  
But I still has questions on this:
* With the 'heavy deriving' supporting, the current 'light weight deriving' will be still
reserved or not? There seems no conflicting between these two deriving features;
* Is it possible to support one-to-many deriving? In your example, suppose there's one more
column called item_description, is it possible to fetch both item_url and item_description
by item_id filtering?
* Why don't we backport this feature to 1.x-staging branch? We really need this feature in
1.x-staging production environments, and I'm not is there any unsolvable problems for backporting?

Thanks for your working on this, and please let me know if there's any I could help.
 

> Enable deriving dimensions on non PK/FK
> ---------------------------------------
>
>                 Key: KYLIN-1313
>                 URL: https://issues.apache.org/jira/browse/KYLIN-1313
>             Project: Kylin
>          Issue Type: Improvement
>            Reporter: hongbin ma
>            Assignee: hongbin ma
>
> currently derived column has to be columns on look table, and the derived host column
has to be PK/FK(It's also a problem when the lookup table grows every large). Sometimes columns
on the fact exhibit deriving relationship too. Here's an example fact table:
> (dt date, seller_id bigint, seller_name varchar(100) , item_id bigint, item_url varchar(1000),
count decimal, price decimal)
> seller_name is uniquely determined by each seller id, and item_url is uniquely determined
by each item_id. The users does not expect to do filtering on columns like seller name or
item_url, they just want to retrieve it when they do grouping/filtering on other dimensions
like selller id, item id or even other dimensions like dt.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message