Repository navigation
Support Min/Max of timestamp #3298
Description
I have a need to know when the source input row of the given aggregated value starts and ends.
For example with following data consisted of timestamp, dimension, and metric value,
2015-07-28T01:00:00.000Z A 1
2015-07-28T02:00:00.000Z A 1
2015-07-28T03:00:00.000Z A 1
2015-07-28T04:00:00.000Z B 1
2015-07-28T05:00:00.000Z A 1
2015-07-28T06:00:00.000Z B 1
2015-07-28T07:00:00.000Z C 1
2015-07-28T08:00:00.000Z C 1
2015-07-28T09:00:00.000Z A 1
2015-07-28T10:00:00.000Z A 1
What I want to know is aggregation(e.g. sum) of metric value and start/end time of corresponding input data like followings
2015-07-28T00:00:00.000Z A 5 2015-07-28T01:00:00.000Z 2015-07-28T10:00:00.000Z
2015-07-28T00:00:00.000Z B 2 2015-07-28T04:00:00.000Z 2015-07-28T06:00:00.000Z
2015-07-28T00:00:00.000Z C 2 2015-07-28T07:00:00.000Z 2015-07-28T08:00:00.000Z
Because existing __time column has only the same granularity as query granularity,
I think It need to add min/max aggregator for timestamp column.
It targets not just for timestamp column, but also for any columns whose type are Timestamp, DateTime, or string representation of Timestamp.
I made an extension to support this and I'm going to PR soon.
Any comments, please.
Activity
gianm commentedon Jul 29, 2016
@sirpkt, use case makes sense, thanks for the explanation.
I wonder if being able to apply extractionFns at ingestion time (and, I guess, extractionFns being able to return longs) would remove the need for time-specific aggregators. Something like InputRow transformers. Then you could use a timestamp-parsing extractionFn to generate a long and feed that into a regular longMax/longMin aggregator.
sirpkt commentedon Aug 16, 2016
@gianm Thank you for the comment.
You're right. I can get the same value with your suggestion.
But, someones do not like to see long value as a result and feel inconvenient to convert that long to timestamp.
I don't think what I did is the best solution because it shows timestamp value only with group by query as internal data type is still long,
and it would be best if timestamp data type is supported.
stale commentedon Jun 21, 2019
This issue has been marked as stale due to 280 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the dev@druid.apache.org list. Thank you for your contributions.
stale commentedon Jul 5, 2019
This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.