Is it achieve via following steps?
1. Clone the cube 2. Make changes to clone 3. Rebuild clone 4. Enable clone 5. Disable original cube so that kylin will redirect queries to new Clone cubes? But in that interim time when both clones and original cubes are available on same hive tables how kylin know which one to pick? based on query metadata? dimensions, aggregations etc? Thanks On Thu, May 11, 2017 at 11:18 AM, Nirav Patel <[email protected]> wrote: > Hi, > > I understand currently kylin does't support partial changes to existing > cube data. In which case entire cube has to be rebuild. WHat is the impact > of it on clients/query interface? Do they have to wait when cube is getting > refreshed? > Also what happens during incremental refresh? If some client query for new > data which are being built would kylin allow dirty read on cube that is > being built? > > Thanks, > Nirav > -- [image: What's New with Xactly] <http://www.xactlycorp.com/email-click/> <https://www.nyse.com/quote/XNYS:XTLY> [image: LinkedIn] <https://www.linkedin.com/company/xactly-corporation> [image: Twitter] <https://twitter.com/Xactly> [image: Facebook] <https://www.facebook.com/XactlyCorp> [image: YouTube] <http://www.youtube.com/xactlycorporation>
