[
https://issues.apache.org/jira/browse/FLINK-9712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629066#comment-16629066
]
ASF GitHub Bot commented on FLINK-9712:
---------------------------------------
fhueske commented on a change in pull request #6741: [FLINK-9712][table,docs]
Document processing time Temporal Table Joins
URL: https://github.com/apache/flink/pull/6741#discussion_r220609016
##########
File path: docs/dev/table/streaming/index.md
##########
@@ -0,0 +1,73 @@
+---
+title: "Streaming Concepts"
+nav-id: streaming_tableapi
+nav-parent_id: tableapi
+nav-pos: 10
+is_beta: false
+nav-show_overview: true
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+Flink's [Table API](../tableApi.html) and [SQL support](../sql.html) are
unified APIs for batch and stream processing. This means that Table API and SQL
queries have the same semantics regardless whether their input is bounded batch
input or unbounded stream input. Because the relational algebra and SQL were
originally designed for batch processing, relational queries on unbounded
streaming input are not as well understood as relational queries on bounded
batch input.
+
+In this section, we explain concepts, practical limitations, and
stream-specific configuration parameters of Flink's relational APIs on
streaming data.
+
+Relational Queries on Data Streams
+----------------------------------
+
+SQL and the relational algebra have not been designed with streaming data in
mind. As a consequence, there are few conceptual gaps between relational
algebra (and SQL) and stream processing.
+
+<table class="table table-bordered">
+ <tr>
+ <th>Relational Algebra / SQL</th>
+ <th>Stream Processing</th>
+ </tr>
+ <tr>
+ <td>Relations (or tables) are bounded (multi-)sets of
tuples.</td>
+ <td>A stream is an infinite sequences of tuples.</td>
+ </tr>
+ <tr>
+ <td>A query that is executed on batch data (e.g., a table in a
relational database) has access to the complete input data.</td>
+ <td>A streaming query cannot access all data when is started
and has to "wait" for data to be streamed in.</td>
+ </tr>
+ <tr>
+ <td>A batch query terminates after it produced a fixed sized
result.</td>
+ <td>A streaming query continuously updates its result based on
the received records and never completes.</td>
+ </tr>
+</table>
+
+Despite these differences, processing streams with relational queries and SQL
is not impossible. Advanced relational database systems offer a feature called
*Materialized Views*. A materialized view is defined as a SQL query, just like
a regular virtual view. In contrast to a virtual view, a materialized view
caches the result of the query such that the query does not need to be
evaluated when the view is accessed. A common challenge for caching is to
prevent a cache from serving outdated results. A materialized view becomes
outdated when the base tables of its definition query are modified. *Eager View
Maintenance* is a technique to update materialized views and updates a
materialized view as soon as its base tables are updated.
+
+The connection between eager view maintenance and SQL queries on streams
becomes obvious if we consider the following:
+
+- A database table is the result of a *stream* of `INSERT`, `UPDATE`, and
`DELETE` DML statements, often called *changelog stream*.
+- A materialized view is defined as a SQL query. In order to update the view,
the query is continuously processes the changelog streams of the view's base
relations.
+- The materialized view is the result of the streaming SQL query.
+
+With these points in mind, we introduce following concepts:
+
+* [Dynamic Tables & Continuous Queries]({{ site.baseurl
}}/dev/table/streaming/dynamic_tables.html)
+* [Time attributes]({{ site.baseurl
}}/dev/table/streaming/time_attributes.html)
+* [Joins]({{ site.baseurl }}/dev/table/streaming/joins.html)
Review comment:
Change "Joins" to "Joins in Continuous Queries" to emphasize that this is
not about joins in general?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Support enrichment joins in Flink SQL/Table API
> -----------------------------------------------
>
> Key: FLINK-9712
> URL: https://issues.apache.org/jira/browse/FLINK-9712
> Project: Flink
> Issue Type: New Feature
> Components: Table API & SQL
> Affects Versions: 1.5.0
> Reporter: Piotr Nowojski
> Assignee: Piotr Nowojski
> Priority: Major
> Labels: pull-request-available
>
> As described here:
> https://docs.google.com/document/d/1KaAkPZjWFeu-ffrC9FhYuxE6CIKsatHTTxyrxSBR8Sk/edit?usp=sharing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
