You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@kylin.apache.org by Sonny Heer <so...@gmail.com> on 2017/03/08 20:48:45 UTC
Hive table design (multiple fact tables or rolled up)
Hi I'm somewhat new to Kylin. we have a relational db schema imported into
hive as is at the moment. The schema is highly normalized with lots of
tables. I can see this database having multiple fact tables or a handful
of fact tables.
In Kylin I see when creating a model (star) you have the option to pick a
single fact table...meaning there is a single cube per fact table. Please
provide pros/cons on running transformations to denormalize the tables into
a single table vs keeping lots of tables with many fact/lookup tables.
In short:
should we do any transformations in Hive before presenting the tables to
kylin for cubing?...
Thanks
Re: Hive table design (multiple fact tables or rolled up)
Posted by ShaoFeng Shi <sh...@apache.org>.
Correct; Kylin supports star schema or snowflake schema, both are single
fact table models.
2018-09-03 14:59 GMT+08:00 mvneethu <ne...@tigeranalytics.com>:
> Hi,
>
> I know this is the old post, but I don't think kylin 2.x has the facility
> to
> add more than 1 fact table. Is this correct. Please clarify.
>
> Thanks,
> Neethu
>
> --
> Sent from: http://apache-kylin.74782.x6.nabble.com/
>
--
Best regards,
Shaofeng Shi 史少锋
Re: Hive table design (multiple fact tables or rolled up)
Posted by mvneethu <ne...@tigeranalytics.com>.
Hi,
I know this is the old post, but I don't think kylin 2.x has the facility to
add more than 1 fact table. Is this correct. Please clarify.
Thanks,
Neethu
--
Sent from: http://apache-kylin.74782.x6.nabble.com/
Re: Hive table design (multiple fact tables or rolled up)
Posted by ShaoFeng Shi <sh...@apache.org>.
"Refresh" is almost the same as "build"; the only difference is "refresh"
for an existing segment, "build" for a new segment.
2017-03-16 22:56 GMT+08:00 Sonny Heer <so...@gmail.com>:
> Can you describe the performance between "refresh", "build" and "merge"?
> I'm assuming refresh is essentially the same as a full build of the same
> cube, or is it doing something else to speed up processing?
>
> Thanks for all the clarifications.
>
> On Wed, Mar 15, 2017 at 2:09 PM, Billy Liu <bi...@apache.org> wrote:
>
>> Kylin is the OLAP on Hadoop. OLAP is the read-only query engine. So we
>> suppose there is no update/delete operator directly. Kylin support build
>> incrementally. So if new data is ingested, you could build new one(new time
>> range). If you want to update existing cube since the underline data
>> changed, please click "Refresh" on the Cube.
>>
>> 2017-03-15 13:23 GMT-07:00 Sonny Heer <so...@gmail.com>:
>>
>>> Thanks ShaoFeng,
>>>
>>> views is what we are doing now. How does kylin handle
>>> new/updated/deleted records? I have a schema that i create a single view
>>> from (denormalized). can you explain kylin's pattern to handle
>>> new/updated/deleted data?
>>>
>>> On Tue, Mar 14, 2017 at 6:21 PM, ShaoFeng Shi <sh...@apache.org>
>>> wrote:
>>>
>>>> View might be slower, but it is flexible. This is a tradeoff.
>>>>
>>>> 2017-03-14 4:15 GMT+08:00 Sonny Heer <so...@gmail.com>:
>>>>
>>>>> How about Hive view fed into kylin vs materialized table...performance
>>>>> impact?
>>>>>
>>>>> On Fri, Mar 10, 2017 at 1:34 AM, ShaoFeng Shi <sh...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> One Cube is one topic, all activities like build and ACL are managed
>>>>>> by cube; one query should only hit one cube; acrossing cube query isn't
>>>>>> suggested.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Pushpinder S. Heer
>>>>> Senior Software Engineer
>>>>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>>
>>>> Shaofeng Shi 史少锋
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Pushpinder S. Heer
>>> Senior Software Engineer
>>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>>
>>
>>
>
>
> --
>
>
> Pushpinder S. Heer
> Senior Software Engineer
> m: 360-434-4354 h: 509-884-2574
>
--
Best regards,
Shaofeng Shi 史少锋
Re: Hive table design (multiple fact tables or rolled up)
Posted by Sonny Heer <so...@gmail.com>.
Can you describe the performance between "refresh", "build" and "merge"?
I'm assuming refresh is essentially the same as a full build of the same
cube, or is it doing something else to speed up processing?
Thanks for all the clarifications.
On Wed, Mar 15, 2017 at 2:09 PM, Billy Liu <bi...@apache.org> wrote:
> Kylin is the OLAP on Hadoop. OLAP is the read-only query engine. So we
> suppose there is no update/delete operator directly. Kylin support build
> incrementally. So if new data is ingested, you could build new one(new time
> range). If you want to update existing cube since the underline data
> changed, please click "Refresh" on the Cube.
>
> 2017-03-15 13:23 GMT-07:00 Sonny Heer <so...@gmail.com>:
>
>> Thanks ShaoFeng,
>>
>> views is what we are doing now. How does kylin handle
>> new/updated/deleted records? I have a schema that i create a single view
>> from (denormalized). can you explain kylin's pattern to handle
>> new/updated/deleted data?
>>
>> On Tue, Mar 14, 2017 at 6:21 PM, ShaoFeng Shi <sh...@apache.org>
>> wrote:
>>
>>> View might be slower, but it is flexible. This is a tradeoff.
>>>
>>> 2017-03-14 4:15 GMT+08:00 Sonny Heer <so...@gmail.com>:
>>>
>>>> How about Hive view fed into kylin vs materialized table...performance
>>>> impact?
>>>>
>>>> On Fri, Mar 10, 2017 at 1:34 AM, ShaoFeng Shi <sh...@apache.org>
>>>> wrote:
>>>>
>>>>> One Cube is one topic, all activities like build and ACL are managed
>>>>> by cube; one query should only hit one cube; acrossing cube query isn't
>>>>> suggested.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Pushpinder S. Heer
>>>> Senior Software Engineer
>>>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Shaofeng Shi 史少锋
>>>
>>>
>>
>>
>> --
>>
>>
>> Pushpinder S. Heer
>> Senior Software Engineer
>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>
>
>
--
Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Re: Hive table design (multiple fact tables or rolled up)
Posted by Billy Liu <bi...@apache.org>.
Kylin is the OLAP on Hadoop. OLAP is the read-only query engine. So we
suppose there is no update/delete operator directly. Kylin support build
incrementally. So if new data is ingested, you could build new one(new time
range). If you want to update existing cube since the underline data
changed, please click "Refresh" on the Cube.
2017-03-15 13:23 GMT-07:00 Sonny Heer <so...@gmail.com>:
> Thanks ShaoFeng,
>
> views is what we are doing now. How does kylin handle new/updated/deleted
> records? I have a schema that i create a single view from (denormalized).
> can you explain kylin's pattern to handle new/updated/deleted data?
>
> On Tue, Mar 14, 2017 at 6:21 PM, ShaoFeng Shi <sh...@apache.org>
> wrote:
>
>> View might be slower, but it is flexible. This is a tradeoff.
>>
>> 2017-03-14 4:15 GMT+08:00 Sonny Heer <so...@gmail.com>:
>>
>>> How about Hive view fed into kylin vs materialized table...performance
>>> impact?
>>>
>>> On Fri, Mar 10, 2017 at 1:34 AM, ShaoFeng Shi <sh...@apache.org>
>>> wrote:
>>>
>>>> One Cube is one topic, all activities like build and ACL are managed by
>>>> cube; one query should only hit one cube; acrossing cube query isn't
>>>> suggested.
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Pushpinder S. Heer
>>> Senior Software Engineer
>>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>>
>>
>>
>>
>> --
>> Best regards,
>>
>> Shaofeng Shi 史少锋
>>
>>
>
>
> --
>
>
> Pushpinder S. Heer
> Senior Software Engineer
> m: 360-434-4354 h: 509-884-2574
>
Re: Hive table design (multiple fact tables or rolled up)
Posted by Sonny Heer <so...@gmail.com>.
Thanks ShaoFeng,
views is what we are doing now. How does kylin handle new/updated/deleted
records? I have a schema that i create a single view from (denormalized).
can you explain kylin's pattern to handle new/updated/deleted data?
On Tue, Mar 14, 2017 at 6:21 PM, ShaoFeng Shi <sh...@apache.org>
wrote:
> View might be slower, but it is flexible. This is a tradeoff.
>
> 2017-03-14 4:15 GMT+08:00 Sonny Heer <so...@gmail.com>:
>
>> How about Hive view fed into kylin vs materialized table...performance
>> impact?
>>
>> On Fri, Mar 10, 2017 at 1:34 AM, ShaoFeng Shi <sh...@apache.org>
>> wrote:
>>
>>> One Cube is one topic, all activities like build and ACL are managed by
>>> cube; one query should only hit one cube; acrossing cube query isn't
>>> suggested.
>>>
>>
>>
>>
>> --
>>
>>
>> Pushpinder S. Heer
>> Senior Software Engineer
>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>
>
>
>
> --
> Best regards,
>
> Shaofeng Shi 史少锋
>
>
--
Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Re: Hive table design (multiple fact tables or rolled up)
Posted by ShaoFeng Shi <sh...@apache.org>.
View might be slower, but it is flexible. This is a tradeoff.
2017-03-14 4:15 GMT+08:00 Sonny Heer <so...@gmail.com>:
> How about Hive view fed into kylin vs materialized table...performance
> impact?
>
> On Fri, Mar 10, 2017 at 1:34 AM, ShaoFeng Shi <sh...@apache.org>
> wrote:
>
>> One Cube is one topic, all activities like build and ACL are managed by
>> cube; one query should only hit one cube; acrossing cube query isn't
>> suggested.
>>
>
>
>
> --
>
>
> Pushpinder S. Heer
> Senior Software Engineer
> m: 360-434-4354 h: 509-884-2574
>
--
Best regards,
Shaofeng Shi 史少锋
Re: Hive table design (multiple fact tables or rolled up)
Posted by Sonny Heer <so...@gmail.com>.
How about Hive view fed into kylin vs materialized table...performance
impact?
On Fri, Mar 10, 2017 at 1:34 AM, ShaoFeng Shi <sh...@apache.org>
wrote:
> One Cube is one topic, all activities like build and ACL are managed by
> cube; one query should only hit one cube; acrossing cube query isn't
> suggested.
>
--
Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Re: Hive table design (multiple fact tables or rolled up)
Posted by ShaoFeng Shi <sh...@apache.org>.
One Cube is one topic, all activities like build and ACL are managed by
cube; one query should only hit one cube; acrossing cube query isn't
suggested.
Re: Hive table design (multiple fact tables or rolled up)
Posted by Sonny Heer <so...@gmail.com>.
>
> Thanks ShaoFeng. That makes sense. Can you talk about having two cubes
> vs one and if queries go across cubes (e.g. on columns from both cubes)?
On Wed, Mar 8, 2017 at 9:22 PM, ShaoFeng Shi <sh...@apache.org> wrote:
> In Kylin 1.x as it only allow one Fact table, you have to join multiple
> big tables as one before using in Cube. Of course you can do that with a
> Hive view, so all joins are over fly when Kylin fetches data from Hive. The
> impact is, when query Kylin you need to use the name of the joined table,
> instead of original fact table name.
>
> From Kylin 2.x, it supports multiple Fact tables in one Cube; You don't
> need create additional view or flat table, just use the original names.
>
> 2017-03-09 9:45 GMT+08:00 Sonny Heer <so...@gmail.com>:
>
>> to clarify in my use case the data can be organized to either have a
>> couple fact tables or a large single one. Queries are open ended at this
>> point. queries may cross facts or may not.
>>
>> On Wed, Mar 8, 2017 at 5:13 PM, Sonny Heer <so...@gmail.com> wrote:
>>
>>> Let me put it anther way. assume a SALES table and a PRODUCT table.
>>> This is not highly normalized in the grand scheme of things, but somewhat.
>>> The question is what benefit is there to denormalize this further into a
>>> single table for kylin. i read something about hierarchical dimensions.
>>> So from Kylin perspective which is better. have one-to-many in a single
>>> table or some normalized form?
>>>
>>> On Wed, Mar 8, 2017 at 4:24 PM, Billy Liu <bi...@apache.org> wrote:
>>>
>>>> please check star schema first： https://en.wikipedia.or
>>>> g/wiki/Star_schema
>>>>
>>>> 2017-03-08 12:48 GMT-08:00 Sonny Heer <so...@gmail.com>:
>>>>
>>>>> Hi I'm somewhat new to Kylin. we have a relational db schema imported
>>>>> into hive as is at the moment. The schema is highly normalized with lots
>>>>> of tables. I can see this database having multiple fact tables or a
>>>>> handful of fact tables.
>>>>>
>>>>> In Kylin I see when creating a model (star) you have the option to
>>>>> pick a single fact table...meaning there is a single cube per fact table.
>>>>> Please provide pros/cons on running transformations to denormalize the
>>>>> tables into a single table vs keeping lots of tables with many fact/lookup
>>>>> tables.
>>>>>
>>>>> In short:
>>>>> should we do any transformations in Hive before presenting the tables
>>>>> to kylin for cubing?...
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Pushpinder S. Heer
>>> Senior Software Engineer
>>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>>
>>
>>
>>
>> --
>>
>>
>> Pushpinder S. Heer
>> Senior Software Engineer
>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>
>
>
>
> --
> Best regards,
>
> Shaofeng Shi 史少锋
>
>
--
Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Re: Hive table design (multiple fact tables or rolled up)
Posted by ShaoFeng Shi <sh...@apache.org>.
In Kylin 1.x as it only allow one Fact table, you have to join multiple big
tables as one before using in Cube. Of course you can do that with a Hive
view, so all joins are over fly when Kylin fetches data from Hive. The
impact is, when query Kylin you need to use the name of the joined table,
instead of original fact table name.
From Kylin 2.x, it supports multiple Fact tables in one Cube; You don't
need create additional view or flat table, just use the original names.
2017-03-09 9:45 GMT+08:00 Sonny Heer <so...@gmail.com>:
> to clarify in my use case the data can be organized to either have a
> couple fact tables or a large single one. Queries are open ended at this
> point. queries may cross facts or may not.
>
> On Wed, Mar 8, 2017 at 5:13 PM, Sonny Heer <so...@gmail.com> wrote:
>
>> Let me put it anther way. assume a SALES table and a PRODUCT table.
>> This is not highly normalized in the grand scheme of things, but somewhat.
>> The question is what benefit is there to denormalize this further into a
>> single table for kylin. i read something about hierarchical dimensions.
>> So from Kylin perspective which is better. have one-to-many in a single
>> table or some normalized form?
>>
>> On Wed, Mar 8, 2017 at 4:24 PM, Billy Liu <bi...@apache.org> wrote:
>>
>>> please check star schema first： https://en.wikipedia.or
>>> g/wiki/Star_schema
>>>
>>> 2017-03-08 12:48 GMT-08:00 Sonny Heer <so...@gmail.com>:
>>>
>>>> Hi I'm somewhat new to Kylin. we have a relational db schema imported
>>>> into hive as is at the moment. The schema is highly normalized with lots
>>>> of tables. I can see this database having multiple fact tables or a
>>>> handful of fact tables.
>>>>
>>>> In Kylin I see when creating a model (star) you have the option to pick
>>>> a single fact table...meaning there is a single cube per fact table.
>>>> Please provide pros/cons on running transformations to denormalize the
>>>> tables into a single table vs keeping lots of tables with many fact/lookup
>>>> tables.
>>>>
>>>> In short:
>>>> should we do any transformations in Hive before presenting the tables
>>>> to kylin for cubing?...
>>>>
>>>> Thanks
>>>>
>>>
>>>
>>
>>
>> --
>>
>>
>> Pushpinder S. Heer
>> Senior Software Engineer
>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>
>
>
>
> --
>
>
> Pushpinder S. Heer
> Senior Software Engineer
> m: 360-434-4354 h: 509-884-2574
>
--
Best regards,
Shaofeng Shi 史少锋
Re: Hive table design (multiple fact tables or rolled up)
Posted by ShaoFeng Shi <sh...@apache.org>.
In Kylin 1.x as it only allow one Fact table, you have to join multiple big
tables as one before using in Cube. Of course you can do that with a Hive
view, so all joins are over fly when Kylin fetches data from Hive. The
impact is, when query Kylin you need to use the name of the joined table,
instead of original fact table name.
From Kylin 2.x, it supports multiple Fact tables in one Cube; You don't
need create additional view or flat table, just use the original names.
2017-03-09 9:45 GMT+08:00 Sonny Heer <so...@gmail.com>:
> to clarify in my use case the data can be organized to either have a
> couple fact tables or a large single one. Queries are open ended at this
> point. queries may cross facts or may not.
>
> On Wed, Mar 8, 2017 at 5:13 PM, Sonny Heer <so...@gmail.com> wrote:
>
>> Let me put it anther way. assume a SALES table and a PRODUCT table.
>> This is not highly normalized in the grand scheme of things, but somewhat.
>> The question is what benefit is there to denormalize this further into a
>> single table for kylin. i read something about hierarchical dimensions.
>> So from Kylin perspective which is better. have one-to-many in a single
>> table or some normalized form?
>>
>> On Wed, Mar 8, 2017 at 4:24 PM, Billy Liu <bi...@apache.org> wrote:
>>
>>> please check star schema first： https://en.wikipedia.or
>>> g/wiki/Star_schema
>>>
>>> 2017-03-08 12:48 GMT-08:00 Sonny Heer <so...@gmail.com>:
>>>
>>>> Hi I'm somewhat new to Kylin. we have a relational db schema imported
>>>> into hive as is at the moment. The schema is highly normalized with lots
>>>> of tables. I can see this database having multiple fact tables or a
>>>> handful of fact tables.
>>>>
>>>> In Kylin I see when creating a model (star) you have the option to pick
>>>> a single fact table...meaning there is a single cube per fact table.
>>>> Please provide pros/cons on running transformations to denormalize the
>>>> tables into a single table vs keeping lots of tables with many fact/lookup
>>>> tables.
>>>>
>>>> In short:
>>>> should we do any transformations in Hive before presenting the tables
>>>> to kylin for cubing?...
>>>>
>>>> Thanks
>>>>
>>>
>>>
>>
>>
>> --
>>
>>
>> Pushpinder S. Heer
>> Senior Software Engineer
>> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>>
>
>
>
> --
>
>
> Pushpinder S. Heer
> Senior Software Engineer
> m: 360-434-4354 h: 509-884-2574
>
--
Best regards,
Shaofeng Shi 史少锋
Re: Hive table design (multiple fact tables or rolled up)
Posted by Sonny Heer <so...@gmail.com>.
to clarify in my use case the data can be organized to either have a couple
fact tables or a large single one. Queries are open ended at this point.
queries may cross facts or may not.
On Wed, Mar 8, 2017 at 5:13 PM, Sonny Heer <so...@gmail.com> wrote:
> Let me put it anther way. assume a SALES table and a PRODUCT table. This
> is not highly normalized in the grand scheme of things, but somewhat. The
> question is what benefit is there to denormalize this further into a single
> table for kylin. i read something about hierarchical dimensions. So from
> Kylin perspective which is better. have one-to-many in a single table or
> some normalized form?
>
> On Wed, Mar 8, 2017 at 4:24 PM, Billy Liu <bi...@apache.org> wrote:
>
>> please check star schema first： https://en.wikipedia.org/wiki/Star_schema
>>
>> 2017-03-08 12:48 GMT-08:00 Sonny Heer <so...@gmail.com>:
>>
>>> Hi I'm somewhat new to Kylin. we have a relational db schema imported
>>> into hive as is at the moment. The schema is highly normalized with lots
>>> of tables. I can see this database having multiple fact tables or a
>>> handful of fact tables.
>>>
>>> In Kylin I see when creating a model (star) you have the option to pick
>>> a single fact table...meaning there is a single cube per fact table.
>>> Please provide pros/cons on running transformations to denormalize the
>>> tables into a single table vs keeping lots of tables with many fact/lookup
>>> tables.
>>>
>>> In short:
>>> should we do any transformations in Hive before presenting the tables to
>>> kylin for cubing?...
>>>
>>> Thanks
>>>
>>
>>
>
>
> --
>
>
> Pushpinder S. Heer
> Senior Software Engineer
> m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574>
>
--
Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Re: Hive table design (multiple fact tables or rolled up)
Posted by Sonny Heer <so...@gmail.com>.
Let me put it anther way. assume a SALES table and a PRODUCT table. This
is not highly normalized in the grand scheme of things, but somewhat. The
question is what benefit is there to denormalize this further into a single
table for kylin. i read something about hierarchical dimensions. So from
Kylin perspective which is better. have one-to-many in a single table or
some normalized form?
On Wed, Mar 8, 2017 at 4:24 PM, Billy Liu <bi...@apache.org> wrote:
> please check star schema first： https://en.wikipedia.org/wiki/Star_schema
>
> 2017-03-08 12:48 GMT-08:00 Sonny Heer <so...@gmail.com>:
>
>> Hi I'm somewhat new to Kylin. we have a relational db schema imported
>> into hive as is at the moment. The schema is highly normalized with lots
>> of tables. I can see this database having multiple fact tables or a
>> handful of fact tables.
>>
>> In Kylin I see when creating a model (star) you have the option to pick a
>> single fact table...meaning there is a single cube per fact table. Please
>> provide pros/cons on running transformations to denormalize the tables into
>> a single table vs keeping lots of tables with many fact/lookup tables.
>>
>> In short:
>> should we do any transformations in Hive before presenting the tables to
>> kylin for cubing?...
>>
>> Thanks
>>
>
>
--
Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Re: Hive table design (multiple fact tables or rolled up)
Posted by Billy Liu <bi...@apache.org>.
please check star schema first： https://en.wikipedia.org/wiki/Star_schema
2017-03-08 12:48 GMT-08:00 Sonny Heer <so...@gmail.com>:
> Hi I'm somewhat new to Kylin. we have a relational db schema imported
> into hive as is at the moment. The schema is highly normalized with lots
> of tables. I can see this database having multiple fact tables or a
> handful of fact tables.
>
> In Kylin I see when creating a model (star) you have the option to pick a
> single fact table...meaning there is a single cube per fact table. Please
> provide pros/cons on running transformations to denormalize the tables into
> a single table vs keeping lots of tables with many fact/lookup tables.
>
> In short:
> should we do any transformations in Hive before presenting the tables to
> kylin for cubing?...
>
> Thanks
>