[table] Add support for temporal join on rolling aggregates #24506
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the purpose of the change
This is more of a proposal to demonstrate a possible fix. I am looking for feedback for people that are more knowledgeable.
Following this thread on the mailing list: https://lists.apache.org/thread/9q7sjyqptcnw1371wc190496nwpdv1tz
Given an order table:
and a currency rate table:
that we would aggregate in an unbounded way like this:
It's not possible to do a temporal join between
orders
andmax_rates
and it fails with the following error:After some investigation we realised the way the temporal join checks for event/proc time is by looking if the row types contains some timing information, so we added to
max_rates
another columns like this:However,
LAST_VALUE
does not support timestamp type (FLINK-15867). We added that and we ended up with a Planner assertion error:We understood the issue was in the way
RelTimeIndicatorConverter
rewrites the FlinkLogicalJoin. Left and right input expressions get theirTimeIndicatorRelDataType
types replaced by normal timestamps but in the temporal join case, thecondition
is not rewritten (but in theelse
it's actually done).However, I thought it might not be the solution to the problem. So I also compared if I replaced
max_rates
definition with a simpleSELECT
like in:What I've noticed is that the timestamp on the
right
side of the join is not replaced and stay aTimeIndicatorRelDataType
. This is because the graph ofRelNode
on the right side is:and
WatermarkAssigner
overridesderiveRowType
which actually force theTimeIndicatorRelDataType
to be there, whereas for theFlinkLogicalAggregate
it simply gets converted into a normal timestamp.So the use of
LAST_VALUE(…)
here is a bit of a hack to keep having the time information in the query. It actually would not even work depending on the aggregation ones want to write.However, it seems that supporting temporal join with rolling aggregate would be a good idea.
Looking forward to discuss more on this with you.
Brief change log
Verifying this change
Does this pull request potentially affect one of the following parts:
@Public(Evolving)
: noDocumentation