[
https://issues.apache.org/jira/browse/FLINK-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196602#comment-16196602
]
ASF GitHub Bot commented on FLINK-6233:
---------------------------------------
Github user fhueske commented on a diff in the pull request:
https://github.com/apache/flink/pull/4625#discussion_r143400052
--- Diff:
flink-libraries/flink-table/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamWindowJoin.scala
---
@@ -184,4 +229,50 @@ class DataStreamWindowJoin(
.returns(returnTypeInfo)
}
}
+
+ def createRowTimeInnerJoin(
+ leftDataStream: DataStream[CRow],
+ rightDataStream: DataStream[CRow],
+ returnTypeInfo: TypeInformation[CRow],
+ joinFunctionName: String,
+ joinFunctionCode: String,
+ leftKeys: Array[Int],
+ rightKeys: Array[Int]): DataStream[CRow] = {
+
+ val rowTimeInnerJoinFunc = new RowTimeBoundedStreamInnerJoin(
+ leftLowerBound,
+ leftUpperBound,
+ allowedLateness = 0L,
+ leftSchema.typeInfo,
+ rightSchema.typeInfo,
+ joinFunctionName,
+ joinFunctionCode,
+ leftTimeIdx,
+ rightTimeIdx)
+
+ if (!leftKeys.isEmpty) {
+ leftDataStream
+ .connect(rightDataStream)
+ .keyBy(leftKeys, rightKeys)
--- End diff --
That's a good point. The motivation for this restriction is to prevent
nested-loop joins for the batch execution.
In the streaming window join case, no equi-join keys would result in a
single thread execution which is not efficient either (could be parallelized by
broadcasting one of the inputs but without statistics this is quite risky) but
not as bad as a full nested-loop join because we can bound the computation due
to the window predicates.
We could add a boolean flag to the constructor of
`FlinkLogicalJoinConverter` to allow cross joins. Right now the set of logical
optimization rules is shared by DataSet and DataStream. I'd keep the joint rule
set for now and just add an additional rule by overriding
`getLogicalOptRuleSet` in `StreamExecutionEnvironment`.
> 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)
