[ https://issues.apache.org/jira/browse/FLINK-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125182#comment-16125182 ]
Xingcan Cui commented on FLINK-6233: ------------------------------------ Hi [~fhueske], thanks for the previous work by you and yuhong, the implementation process is going well. Nevertheless, I've got some minor questions/ideas. # Considering that the core logics of the rowtime inner join and proctime inner join are almost the same. Can I extract an abstract {{TimeWindowInnerJoin}} class and let the {{ProcTimeWindowInnerJoin}} and {{RowTimeWindowInnerJoin}} extend it? # The clean up process for the cached data is triggered by ProcessingTimeTimers in the {{ProcTimeWindowInnerJoin}}. For {{RowTimeWindowInnerJoin}}, I think this process could be directly triggered by the watermarks without registering the EventTimeTimer, right? # Since the collections provided by the state backend are simple, it may be inefficient to search for the out-of-dated records. I think the current "short-circuit" codes (as shown below) can not clean all the expired data. {code:java} while (keyIter.hasNext && !validTimestamp) { val recordTime = keyIter.next if (recordTime < expiredTime) { removeList.add(recordTime) } else { // we found a timestamp that is still valid validTimestamp = true } } {code} To cope with that, I plan to split the "cache window" into continuous static-panes, and casting one to expired as a whole. By doing like that, we may store some extra records, whose time interval is equal to the static span of the panes, but can remove the expired data efficiently. # I'd like to introduce an extra {{allowLateness}} parameter (which can be set in the {{StreamQueryConfig}}) to the join function. But for now, I'll give it a default {{0L}} value. > Support rowtime inner equi-join between two streams in the SQL API > ------------------------------------------------------------------ > > Key: FLINK-6233 > URL: https://issues.apache.org/jira/browse/FLINK-6233 > Project: Flink > Issue Type: Sub-task > Components: Table API & SQL > Reporter: hongyuhong > Assignee: Xingcan Cui > > The goal of this issue is to add support for inner equi-join on proc time > streams to the SQL interface. > Queries similar to the following should be supported: > {code} > SELECT o.rowtime , o.productId, o.orderId, s.rowtime AS shipTime > FROM Orders AS o > JOIN Shipments AS s > ON o.orderId = s.orderId > AND o.rowtime BETWEEN s.rowtime AND s.rowtime + INTERVAL '1' HOUR; > {code} > The following restrictions should initially apply: > * The join hint only support inner join > * The ON clause should include equi-join condition > * The time-condition {{o.rowtime BETWEEN s.rowtime AND s.rowtime + INTERVAL > '1' HOUR}} only can use rowtime that is a system attribute, the time > condition only support bounded time range like {{o.rowtime BETWEEN s.rowtime > - INTERVAL '1' HOUR AND s.rowtime + INTERVAL '1' HOUR}}, not support > unbounded like {{o.rowtime < s.rowtime}} , and should include both two > stream's rowtime attribute, {{o.rowtime between rowtime () and rowtime () + > 1}} should also not be supported. > An row-time streams join will not be able to handle late data, because this > would mean in insert a row into a sorted order shift all other computations. > This would be too expensive to maintain. Therefore, we will throw an error if > a user tries to use an row-time stream join with late data handling. > This issue includes: > * Design of the DataStream operator to deal with stream join > * Translation from Calcite's RelNode representation (LogicalJoin). -- This message was sent by Atlassian JIRA (v6.4.14#64029)