You are right, derived dimension (like store name) is free to change and does not require cube rebuild.
Another common trick is do the name lookup in the front end (like a report engine). Then in cube, store ID is all you need. On Fri, Jun 12, 2015 at 5:21 PM, alex schufo <[email protected]> wrote: > 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? > > > > > > > > >
