klion26 commented on a change in pull request #12420:
URL: https://github.com/apache/flink/pull/12420#discussion_r458534394
##########
File path: docs/dev/table/streaming/joins.zh.md
##########
@@ -140,26 +138,21 @@ FROM
WHERE r.currency = o.currency
{% endhighlight %}
-Each record from the probe side will be joined with the version of the build
side table at the time of the correlated time attribute of the probe side
record.
-In order to support updates (overwrites) of previous values on the build side
table, the table must define a primary key.
+探针侧的每条记录都将与构建侧的表执行 Join 运算，构建侧的表中与探针侧对应时间属性的记录将参与运算。为了支持更新（包括覆盖）构建侧的表，该表必须定义主键。
-In our example, each record from `Orders` will be joined with the version of
`Rates` at time `o.rowtime`. The `currency` field has been defined as the
primary key of `Rates` before and is used to connect both tables in our
example. If the query were using a processing-time notion, a newly appended
order would always be joined with the most recent version of `Rates` when
executing the operation.
+在示例中，`Orders` 表中的每一条记录都与时间点 `o.rowtime` 的 `Rates` 进行 Join 运算。`currency`
字段已被定义为 `Rates` 表的主键，在示例中该字段也被用于连接两个表。如果该查询采用的是处理时间，则在执行时新增的订单将始终与最新的 `Rates`
执行 Join。
-In contrast to [regular joins](#regular-joins), this means that if there is a
new record on the build side, it will not affect the previous results of the
join.
-This again allows Flink to limit the number of elements that must be kept in
the state.
+与[常规 Join](#regular-joins) 相反，时态表函数 Join 意味着如果在构建侧新增一行记录将不会影响之前的结果。这同时使得 Flink
能够限制必须保存在 state 中的元素数量（因为不再需要保存之前的状态）。
-Compared to [interval joins](#interval-joins), temporal table joins do not
define a time window within which bounds the records will be joined.
-Records from the probe side are always joined with the build side's version at
the time specified by the time attribute. Thus, records on the build side might
be arbitrarily old.
-As time passes, the previous and no longer needed versions of the record (for
the given primary key) will be removed from the state.
+与[时间区间 Join](#interval-joins) 相比，时态表 Join 没有定义限制了每次参与 Join
运算的元素的时间范围。探针侧的记录总是会和构建侧中对应特定时间属性的数据进行 Join
操作。因而在构建侧的记录可以是任意时间之前的。随着时间流动，之前产生的和不再需要的给定 primary key 所对应的记录将从 state 中移除。
-Such behaviour makes a temporal table join a good candidate to express stream
enrichment in relational terms.
+这种做法让时态表 Join 成为一个很好的用于表达不同流之间关联的方法。
-### Usage
+### 用法
Review comment:
这里也添加一下 `<a>` 标签吧
##########
File path: docs/dev/table/streaming/joins.zh.md
##########
@@ -22,37 +22,38 @@ specific language governing permissions and limitations
under the License.
-->
-Joins are a common and well-understood operation in batch data processing to
connect the rows of two relations. However, the semantics of joins on [dynamic
tables](dynamic_tables.html) are much less obvious or even confusing.
+Join 在批数据处理中是比较常见且广为人知的运算，一般用于连接两张关系表。然而在[动态表]({%link
dev/table/streaming/dynamic_tables.zh.md %})中 Join 的语义会难以理解甚至让人困惑。
-Because of that, there are a couple of ways to actually perform a join using
either Table API or SQL.
+因而，Flink 提供了几种基于 Table API 和 SQL 的 Join 方法。
-For more information regarding the syntax, please check the join sections in
[Table API](../tableApi.html#joins) and [SQL]({{ site.baseurl
}}/dev/table/sql/queries.html#joins).
+欲获取更多关于 Join 语法的细节，请参考 [Table API]({%link dev/table/tableApi.zh.md %}#joins) 和
[SQL]({%link dev/table/sql/queries.zh.md %}#joins) 中的 Join 章节。
* This will be replaced by the TOC
{:toc}
-Regular Joins
+<a name="regular-joins"></a>
+
+常规 Join
-------------
-Regular joins are the most generic type of join in which any new records or
changes to either side of the join input are visible and are affecting the
whole join result.
-For example, if there is a new record on the left side, it will be joined with
all of the previous and future records on the right side.
+常规 Join 是最常用的 Join 用法。在常规 Join 中，任何新记录或对 Join 两侧表的任何更改都是可见的，并会影响最终整个 Join
的结果。例如，如果 Join 左侧插入了一条新的记录，那么它将会与 Join 右侧过去与将来的所有记录进行 Join 运算。
{% highlight sql %}
SELECT * FROM Orders
INNER JOIN Product
ON Orders.productId = Product.id
{% endhighlight %}
-These semantics allow for any kind of updating (insert, update, delete) input
tables.
+上述语意允许对输入表进行任意类型的更新操作（insert, update, delete）。
+
+然而，常规 Join 隐含了一个重要的前提：即它需要在 Flink 的状态中永久保存 Join 两侧的数据。因而，如果 Join
操作中的一方或双方输入表持续增长的话，资源消耗也将会随之无限增长。
-However, this operation has an important implication: it requires to keep both
sides of the join input in Flink's state forever.
-Thus, the resource usage will grow indefinitely as well, if one or both input
tables are continuously growing.
+<a name="interval-joins"></a>
-Interval Joins
+时间区间 Join
Review comment:
上面的 `常规 Join` 前面添加了 `<a>` 标签，这里也添加一下吧
##########
File path: docs/dev/table/streaming/joins.zh.md
##########
@@ -189,50 +182,43 @@ val result = orders
</div>
</div>
-**Note**: State retention defined in a [query
configuration](query_configuration.html) is not yet implemented for temporal
joins.
-This means that the required state to compute the query result might grow
infinitely depending on the number of distinct primary keys for the history
table.
+**注意**: 时态 Join 中的 State 保留（在[查询配置]({%link
dev/table/streaming/query_configuration.zh.md
%})中定义）还未实现。这意味着计算的查询结果所需的状态可能会无限增长，具体数量取决于历史记录表的不重复主键个数。
+
+### 基于处理时间的时态 Join
-### Processing-time Temporal Joins
+如果将处理时间作为时间属性，将无法将 _过去_ 时间属性作为参数传递给时态表函数。
+根据定义，处理时间总会是当前时间戳。因此，基于处理时间的时态表函数将始终返回基础表的最新已知版本，时态表函数的调用将始终返回基础表的最新已知版本，并且基础历史表中的任何更新也将立即覆盖当前值。
-With a processing-time time attribute, it is impossible to pass _past_ time
attributes as an argument to the temporal table function.
-By definition, it is always the current timestamp. Thus, invocations of a
processing-time temporal table function will always return the latest known
versions of the underlying table
-and any updates in the underlying history table will also immediately
overwrite the current values.
+只有最新版本的构建侧记录（是否最新由所定义的主键所决定）会被保存在 state 中。
+构建侧的更新不会对之前 Join 的结果产生影响。
-Only the latest versions (with respect to the defined primary key) of the
build side records are kept in the state.
-Updates of the build side will have no effect on previously emitted join
results.
+可以将处理时间的时态 Join 视作简单的 `HashMap <K，V>`，HashMap 中存储来自构建侧的所有记录。
+当来自构建侧的新插入的记录与旧值具有相同的 Key 时，旧值会被覆盖。
+探针侧的每条记录将总会根据 `HashMap` 的最新/当前状态来计算。
-One can think about a processing-time temporal join as a simple `HashMap<K,
V>` that stores all of the records from the build side.
-When a new record from the build side has the same key as some previous
record, the old value is just simply overwritten.
-Every record from the probe side is always evaluated against the most
recent/current state of the `HashMap`.
+### 基于事件时间的时态 Join
Review comment:
这里也添加一下 `<a>` 标签吧
##########
File path: docs/dev/table/streaming/joins.zh.md
##########
@@ -300,25 +285,26 @@ FROM
ON r.currency = o.currency
{% endhighlight %}
-Each record from the probe side will be joined with the current version of the
build side table. In our example, the query is using the processing-time
notion, so a newly appended order would always be joined with the most recent
version of `LatestRates` when executing the operation. Note that the result is
not deterministic for processing-time.
+探针侧表中的每个记录都将与构建侧表的当前版本所关联。 在此示例中，查询使用`处理时间`作为处理时间，因而新增订单将始终与表 `LatestRates`
的最新汇率执行 Join 操作。 注意，结果对于处理时间来说不是确定的。
+
+与[常规 Join](#regular-joins) 相比，尽管构建侧表的数据发生了变化，但时态表 Join 的变化前结果不会随之变化。而且时态表 Join
运算非常轻量级且不会保留任何状态。
-In contrast to [regular joins](#regular-joins), the previous results of the
temporal table join will not be affected despite the changes on the build side.
Also, the temporal table join operator is very lightweight and does not keep
any state.
+与[时间区间 Join](#interval-joins) 相比，时态表 Join 没有定义决定哪些记录将被 Join 的时间窗口。
+探针侧的记录将总是与构建侧在对应`处理时间`的最新数据执行 Join。因而构建侧的数据可能是任意旧的。
-Compared to [interval joins](#interval-joins), temporal table joins do not
define a time window within which the records will be joined.
-Records from the probe side are always joined with the build side's latest
version at processing time. Thus, records on the build side might be
arbitrarily old.
+[时态表函数 Join](#join-with-a-temporal-table-function) 和时态表 Join 都有类似的功能，但是有不同的
SQL 语法和 runtime 实现：
-Both [temporal table function join](#join-with-a-temporal-table-function) and
temporal table join come from the same motivation but have different SQL syntax
and runtime implementations:
-* The SQL syntax of the temporal table function join is a join UDTF, while the
temporal table join uses the standard temporal table syntax introduced in
SQL:2011.
-* The implementation of temporal table function joins actually joins two
streams and keeps them in state, while temporal table joins just receive the
only input stream and look up the external database according to the key in the
record.
-* The temporal table function join is usually used to join a changelog stream,
while the temporal table join is usually used to join an external table (i.e.
dimension table).
+* 时态表函数 Join 的 SQL 语法是一种 Join 用户定义生成表函数(UDTF，User-Defined Table-Generating
Functions)，而时态表 Join 使用了 SQL:2011 标准引入的标准时态表语法。
+* 时态表函数 Join 的实现实际上是 Join 两个流并保存在 state 中，而时态表 Join 只接受唯一的输入流，并根据记录的键值查找外部数据库。
+* 时态表函数 Join 通常用于与变更日志流执行 Join，而时态表 Join 通常与外部表（例如维度表）执行 Join 操作。
-Such behaviour makes a temporal table join a good candidate to express stream
enrichment in relational terms.
+这种做法让时态表 Join 成为一个很好的用于表达不同流之间关联的方法。
-In the future, the temporal table join will support the features of temporal
table function joins, i.e. support to temporal join a changelog stream.
+将来，时态表 Join 将支持时态表函数 Join 的功能，即支持时态 Join 变更日志流。
-### Usage
+### 用法
Review comment:
这里也添加一下 `<a>` 标签吧
这里需要注意下，前面已经有一个 `Usage` 的标题了，这里可能需要使用 `<a name="usage-1"></a>`
具体的可以看一下英文文章的链接
##########
File path: docs/dev/table/streaming/joins.zh.md
##########
@@ -189,50 +182,43 @@ val result = orders
</div>
</div>
-**Note**: State retention defined in a [query
configuration](query_configuration.html) is not yet implemented for temporal
joins.
-This means that the required state to compute the query result might grow
infinitely depending on the number of distinct primary keys for the history
table.
+**注意**: 时态 Join 中的 State 保留（在[查询配置]({%link
dev/table/streaming/query_configuration.zh.md
%})中定义）还未实现。这意味着计算的查询结果所需的状态可能会无限增长，具体数量取决于历史记录表的不重复主键个数。
+
+### 基于处理时间的时态 Join
Review comment:
这里也添加一下 `<a>` 标签吧
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
