If multiple cubes could answer the same query, such as the clone ones, Kylin will route the query to the cube who has the lowest query cost. The query cost is computed by dimensions complexity, not query latency.
2017-05-12 9:23 GMT+08:00 Nirav Patel <npa...@xactlycorp.com>: > 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 <npa...@xactlycorp.com> > 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> >
