You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kylin.apache.org by dong wang <el...@gmail.com> on 2015/03/11 03:25:47 UTC
a little suggestion about the data type of the partition column for a cube
As we know that from kylin 0.71, we must define a "date" column if we want
to have a partition column when designing a cube, of course, it's
reasonable, however, it is not that flexible, is it possible that we can
aslo support "timestamp" type since "timestamp" are much more flexible than
"date",and which can be recognized in many other database and much easier
to be converted to other date type, especially for "impala", "impala" only
supports "timestamp"
Re: a little suggestion about the data type of the partition column
for a cube
Posted by "Shi, Shaofeng" <sh...@ebay.com>.
Yes it should support; While in previous release there was a bug caused
the Hive partition columns were not sync into Kylin;
Now the issue has been fixed, please check this JIRA:
https://issues.apache.org/jira/browse/KYLIN-627
On 3/16/15, 11:59 AM, "dong wang" <el...@gmail.com> wrote:
>Will it be also available for that if we use kylin partition date column
>as
>HIVE dynamic partition column?
>
>2015-03-16 11:03 GMT+08:00 Li Yang <li...@apache.org>:
>
>> The partitioning is by java Date type (in its long form) in the
>>backend. So
>> timestamp support in this sense was always there. The GUI only allows
>>date,
>> however, is because all cases we've done so far didn't require a finer
>>time
>> granularity. Will expose more options.
>>
>> On Wed, Mar 11, 2015 at 12:34 PM, Luke Han <lu...@gmail.com> wrote:
>>
>> > Supporting timestamp is one enhancement should to be done, even should
>> > considering String type with given date format.
>> >
>> > Here's JIRA for tracking:
>> https://issues.apache.org/jira/browse/KYLIN-633
>> >
>> > Thanks.
>> >
>> >
>> > Best Regards!
>> > ---------------------
>> >
>> > Luke Han
>> >
>> > 2015-03-10 19:25 GMT-07:00 dong wang <el...@gmail.com>:
>> >
>> > > As we know that from kylin 0.71, we must define a "date" column if
>>we
>> > want
>> > > to have a partition column when designing a cube, of course, it's
>> > > reasonable, however, it is not that flexible, is it possible that we
>> can
>> > > aslo support "timestamp" type since "timestamp" are much more
>>flexible
>> > than
>> > > "date",and which can be recognized in many other database and much
>> easier
>> > > to be converted to other date type, especially for "impala",
>>"impala"
>> > only
>> > > supports "timestamp"
>> > >
>> >
>>
Re: a little suggestion about the data type of the partition column
for a cube
Posted by dong wang <el...@gmail.com>.
Will it be also available for that if we use kylin partition date column as
HIVE dynamic partition column?
2015-03-16 11:03 GMT+08:00 Li Yang <li...@apache.org>:
> The partitioning is by java Date type (in its long form) in the backend. So
> timestamp support in this sense was always there. The GUI only allows date,
> however, is because all cases we've done so far didn't require a finer time
> granularity. Will expose more options.
>
> On Wed, Mar 11, 2015 at 12:34 PM, Luke Han <lu...@gmail.com> wrote:
>
> > Supporting timestamp is one enhancement should to be done, even should
> > considering String type with given date format.
> >
> > Here's JIRA for tracking:
> https://issues.apache.org/jira/browse/KYLIN-633
> >
> > Thanks.
> >
> >
> > Best Regards!
> > ---------------------
> >
> > Luke Han
> >
> > 2015-03-10 19:25 GMT-07:00 dong wang <el...@gmail.com>:
> >
> > > As we know that from kylin 0.71, we must define a "date" column if we
> > want
> > > to have a partition column when designing a cube, of course, it's
> > > reasonable, however, it is not that flexible, is it possible that we
> can
> > > aslo support "timestamp" type since "timestamp" are much more flexible
> > than
> > > "date",and which can be recognized in many other database and much
> easier
> > > to be converted to other date type, especially for "impala", "impala"
> > only
> > > supports "timestamp"
> > >
> >
>
Re: a little suggestion about the data type of the partition column
for a cube
Posted by Li Yang <li...@apache.org>.
The partitioning is by java Date type (in its long form) in the backend. So
timestamp support in this sense was always there. The GUI only allows date,
however, is because all cases we've done so far didn't require a finer time
granularity. Will expose more options.
On Wed, Mar 11, 2015 at 12:34 PM, Luke Han <lu...@gmail.com> wrote:
> Supporting timestamp is one enhancement should to be done, even should
> considering String type with given date format.
>
> Here's JIRA for tracking: https://issues.apache.org/jira/browse/KYLIN-633
>
> Thanks.
>
>
> Best Regards!
> ---------------------
>
> Luke Han
>
> 2015-03-10 19:25 GMT-07:00 dong wang <el...@gmail.com>:
>
> > As we know that from kylin 0.71, we must define a "date" column if we
> want
> > to have a partition column when designing a cube, of course, it's
> > reasonable, however, it is not that flexible, is it possible that we can
> > aslo support "timestamp" type since "timestamp" are much more flexible
> than
> > "date",and which can be recognized in many other database and much easier
> > to be converted to other date type, especially for "impala", "impala"
> only
> > supports "timestamp"
> >
>
Re: a little suggestion about the data type of the partition column
for a cube
Posted by Luke Han <lu...@gmail.com>.
Supporting timestamp is one enhancement should to be done, even should
considering String type with given date format.
Here's JIRA for tracking: https://issues.apache.org/jira/browse/KYLIN-633
Thanks.
Best Regards!
---------------------
Luke Han
2015-03-10 19:25 GMT-07:00 dong wang <el...@gmail.com>:
> As we know that from kylin 0.71, we must define a "date" column if we want
> to have a partition column when designing a cube, of course, it's
> reasonable, however, it is not that flexible, is it possible that we can
> aslo support "timestamp" type since "timestamp" are much more flexible than
> "date",and which can be recognized in many other database and much easier
> to be converted to other date type, especially for "impala", "impala" only
> supports "timestamp"
>