I guess I can assume I don't rebuild for historic data or that I only do it for major changes which should be rare.
But what about derived dimensions? I was thinking of something like that : Fact table with storeID and measures. Hierarchy with - storeID - city - country - region Derived dimension with storeID <--> storeName Let's say the store name can change and I can have 1000's of stores so statistically I can have changes every day. I was thinking that I can have the storeID in the cube (this doesn't change) and the storeName in a simple key/value table, at query time the user sees the store name but the internal query is on the ID, the key/value table name table can be updated every day easily and the cube stays the same. I thought derived dimensions could be used like this. If I change a derived dimension do I need to recompute as well? On Tue, Jun 9, 2015 at 4:37 AM, Li Yang <[email protected]> wrote: > It depends on whether you want the rebranding on historic data. If you hope > the sells in the past be re-grouped according to the new branding, then > like Shaofeng said, a rebuild is required. The reason is obvious as the > pre-calculated sums are now invalid. > > However, if new branding only take effect since a certain date, then there > no need to rebuild old cube segments. Just make sure your dimension table > is updated on that date, and any subsequent build will start to use the new > branding. > > Cheers > Yang > > On Mon, Jun 8, 2015 at 10:15 PM, Shi, Shaofeng <[email protected]> wrote: > > > In this case, your cube need a rebuild; Kylin assumes the lookup table is > > stable (only append new records, not change history data); Once history > > data be changed, the cube will be out of date, the query result might be > > wrong; > > > > So far there is no way to manage such changes easily I think; > > > > On 6/8/15, 9:33 PM, "alex schufo" <[email protected]> wrote: > > > > >Hello, > > > > > >I was wondering how the hierarchy dimensions are managed in the cube and > > >what happens if I update the Hive table that contains the dimension. > > > > > >Let's say I have a fact table with a storeID and then a dimension table > > >that goes like this : > > > > > > - storeID > > > - city > > > - country > > > - region > > > > > >and I want the sum of products sold either by store, city, region, etc. > > > > > >This seems fine with Kylin. > > > > > >For regions, internally is a row going to be created with key as > something > > >like region and the pre-calculated sum? > > > > > >Now let's say there is rebranding and the region is renamed, or that the > > >strategy changes and that a country that was part of region is now part > of > > >another region. > > > > > >Every time some of those changes occur, should I rebuild completely my > > >cube > > >or is there any way to manage those changes? > > > > >
