What Marek described is as designed (an early design though, and we can
discuss if the design makes sense).
Out of simplicity, Kylin 1.x requires all segment be continuous and there's
no gap in between. So a new incremental segment always starts from where
the last segment ends. I agree the Rest
Hi Marek
Is this your first time to build the cube?
Kylin will use the end time of last segment's as the start time. And
if there are no segments have been built, the partition start date will be
used as the first segment's start time.
Marek Wiewiorka 于2015年12月7日周一 下午8:14写道：
> Hi All,
>
Build an empty segment by those days, say day 2, 3, 4 are empty, but 5
contains data.
Build each segment one by one until 5, so you could query data from 5.
Next time, once data fill into 2, 3, 4, refresh them again.
Thanks.
Best Regards!
-
Luke Han
On Tue, Dec 8, 2015 at
Thanks!
So is there any option to build daily segments not in monotonic order?
It's sometimes the case that data are partitioned and due to some problems
in processing
more recent partitions are ready earlier than older ones.
How can it be handled in Kylin in daily refresh scenario?
Marek
20
Kylin will ignore startTime while building a segment, It will take 1)
start time you set in building cube if you are build first segment, 2)
end time of last segment if you append new segment as start time of
new segment.
2015-12-07 20:22 GMT+08:00, Marek Wiewiorka :
> Hi All,
> I came across a we
Hi All,
I came across a weird situation with Kylin cube incremental refresh.
I will try to describe it:
I've a cube with data up to 2015.12.03.
When tried to to build a cube segment for 2015.12.06 by specify a json like
this:
{
"startTime": "144936000",
"endTime": "144944640",
"buildType
Hi All,
I came across a weird situation with Kylin cube incremental refresh.
I will try to describe it:
I've a cube with data up to 2015.12.03.
When tried to to build a cube segment for 2015.12.06 by specify a json like
this:
{
"startTime": "144936000",
"endTime": "144944640",
"buildType
