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? > >
