[jira] [Commented] (FLINK-6233) Support rowtime inner equi-join between two streams in the SQL API

["Xingcan Cui (JIRA)" <ji...@apache.org>]

    [ 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 &lt; 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)