You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2022/04/09 15:22:37 UTC

[GitHub] [flink] RocMarshal commented on a diff in pull request #19401: [FLINK-25716][docs-zh] Translate "Streaming Concepts" page of "Applic…

RocMarshal commented on code in PR #19401:
URL: https://github.com/apache/flink/pull/19401#discussion_r846646275


##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用
 
-### State Usage
-
-Due to the declarative nature of Table API & SQL programs, it is not always obvious where and how much
-state is used within a pipeline. The planner decides whether state is necessary to compute a correct
-result. A pipeline is optimized to claim as little state as possible given the current set of optimizer
-rules.
+由于 Table API & SQL 程序是声明式的,管道内的状态会在哪以及如何被使用并不显然。 Planner 会确认是否需要状态来得到正确的计算结果,
+管道会被现有优化规则集优化成尽可能少地索要状态。

Review Comment:
   ```suggestion
   管道会被现有优化规则集优化成尽可能少地使用状态。
   ```



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用
 
-### State Usage
-
-Due to the declarative nature of Table API & SQL programs, it is not always obvious where and how much
-state is used within a pipeline. The planner decides whether state is necessary to compute a correct
-result. A pipeline is optimized to claim as little state as possible given the current set of optimizer
-rules.
+由于 Table API & SQL 程序是声明式的,管道内的状态会在哪以及如何被使用并不显然。 Planner 会确认是否需要状态来得到正确的计算结果,
+管道会被现有优化规则集优化成尽可能少地索要状态。
 
 {{< hint info >}}
-Conceptually, source tables are never kept entirely in state. An implementer deals with logical tables
-(i.e. [dynamic tables]({{< ref "docs/dev/table/concepts/dynamic_tables" >}})). Their state requirements
-depend on the used operations.
+从概念上讲, 源表从来不会在状态中被完全保存。 实现者在处理逻辑表(即[动态表]({{< ref "docs/dev/table/concepts/dynamic_tables" >}}))时,

Review Comment:
   从概念上讲, 源表从来不会在状态中被完全保存。 实现者处理的是逻辑表(即[动态表]({{< ref "docs/dev/table/concepts/dynamic_tables" >}}))。



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。

Review Comment:
   ```suggestion
   流模式下运行的表程序利用了 Flink 作为有状态流处理器的所有能力。
   ```



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用

Review Comment:
   ```suggestion
   <a name="xxx"></a>
   
   ### 状态使用
   ```
   
   missing link tag.



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用
 
-### State Usage
-
-Due to the declarative nature of Table API & SQL programs, it is not always obvious where and how much
-state is used within a pipeline. The planner decides whether state is necessary to compute a correct
-result. A pipeline is optimized to claim as little state as possible given the current set of optimizer
-rules.
+由于 Table API & SQL 程序是声明式的,管道内的状态会在哪以及如何被使用并不显然。 Planner 会确认是否需要状态来得到正确的计算结果,
+管道会被现有优化规则集优化成尽可能少地索要状态。
 
 {{< hint info >}}
-Conceptually, source tables are never kept entirely in state. An implementer deals with logical tables
-(i.e. [dynamic tables]({{< ref "docs/dev/table/concepts/dynamic_tables" >}})). Their state requirements
-depend on the used operations.
+从概念上讲, 源表从来不会在状态中被完全保存。 实现者在处理逻辑表(即[动态表]({{< ref "docs/dev/table/concepts/dynamic_tables" >}}))时,
+它们的状态取决于用到的操作。
 {{< /hint >}}
 
-Queries such as `SELECT ... FROM ... WHERE` which only consist of field projections or filters are usually
-stateless pipelines. However, operations such as joins, aggregations, or deduplications require keeping
-intermediate results in a fault-tolerant storage for which Flink's state abstractions are used.
+形如 `SELECT ... FROM ... WHERE` 这种只包含字段映射或过滤器的查询的查询语句通常是无状态的管道。 然而诸如 join 、

Review Comment:
   ```suggestion
   形如 `SELECT ... FROM ... WHERE` 这种只包含字段映射或过滤器的查询的查询语句通常是无状态的管道。 然而诸如 join、
   ```



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用
 
-### State Usage
-
-Due to the declarative nature of Table API & SQL programs, it is not always obvious where and how much
-state is used within a pipeline. The planner decides whether state is necessary to compute a correct
-result. A pipeline is optimized to claim as little state as possible given the current set of optimizer
-rules.
+由于 Table API & SQL 程序是声明式的,管道内的状态会在哪以及如何被使用并不显然。 Planner 会确认是否需要状态来得到正确的计算结果,

Review Comment:
   ```并不显然。``` -> ```并不明确``` ?



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用
 
-### State Usage
-
-Due to the declarative nature of Table API & SQL programs, it is not always obvious where and how much
-state is used within a pipeline. The planner decides whether state is necessary to compute a correct
-result. A pipeline is optimized to claim as little state as possible given the current set of optimizer
-rules.
+由于 Table API & SQL 程序是声明式的,管道内的状态会在哪以及如何被使用并不显然。 Planner 会确认是否需要状态来得到正确的计算结果,
+管道会被现有优化规则集优化成尽可能少地索要状态。
 
 {{< hint info >}}
-Conceptually, source tables are never kept entirely in state. An implementer deals with logical tables
-(i.e. [dynamic tables]({{< ref "docs/dev/table/concepts/dynamic_tables" >}})). Their state requirements
-depend on the used operations.
+从概念上讲, 源表从来不会在状态中被完全保存。 实现者在处理逻辑表(即[动态表]({{< ref "docs/dev/table/concepts/dynamic_tables" >}}))时,
+它们的状态取决于用到的操作。
 {{< /hint >}}
 
-Queries such as `SELECT ... FROM ... WHERE` which only consist of field projections or filters are usually
-stateless pipelines. However, operations such as joins, aggregations, or deduplications require keeping
-intermediate results in a fault-tolerant storage for which Flink's state abstractions are used.
+形如 `SELECT ... FROM ... WHERE` 这种只包含字段映射或过滤器的查询的查询语句通常是无状态的管道。 然而诸如 join 、
+聚合或去重操作需要在Flink抽象的容错存储内保持中间结果。

Review Comment:
   ```suggestion
   聚合或去重操作需要在 Flink 抽象的容错存储内保存中间结果。
   ```



##########
docs/content.zh/docs/dev/table/concepts/overview.md:
##########
@@ -34,106 +34,79 @@ Flink 的 [Table API]({{< ref "docs/dev/table/tableApi" >}}) 和 [SQL]({{< ref "
 
 下面这些页面包含了概念、实际的限制,以及流式数据处理中的一些特定的配置。
 
-State Management
+状态管理
 ----------------
+流模式下运行的表程序利用了Flink作为有状态流处理器的所有能力。
 
-Table programs that run in streaming mode leverage all capabilities of Flink as a stateful stream
-processor.
+事实上,一个表程序(Table program)可以配置一个 [state backend]({{< ref "docs/ops/state/state_backends" >}})
+和多个不同的 [checkpoint 选项]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
+以处理对不同状态大小和容错需求。这可以对正在运行的 Table API & SQL 管道(pipeline)生成 savepoint,并在这之后用其恢复应用程序的状态。
 
-In particular, a table program can be configured with a [state backend]({{< ref "docs/ops/state/state_backends" >}})
-and various [checkpointing options]({{< ref "docs/dev/datastream/fault-tolerance/checkpointing" >}})
-for handling different requirements regarding state size and fault tolerance. It is possible to take
-a savepoint of a running Table API & SQL pipeline and to restore the application's state at a later
-point in time.
+### 状态使用
 
-### State Usage
-
-Due to the declarative nature of Table API & SQL programs, it is not always obvious where and how much
-state is used within a pipeline. The planner decides whether state is necessary to compute a correct
-result. A pipeline is optimized to claim as little state as possible given the current set of optimizer
-rules.
+由于 Table API & SQL 程序是声明式的,管道内的状态会在哪以及如何被使用并不显然。 Planner 会确认是否需要状态来得到正确的计算结果,
+管道会被现有优化规则集优化成尽可能少地索要状态。
 
 {{< hint info >}}
-Conceptually, source tables are never kept entirely in state. An implementer deals with logical tables
-(i.e. [dynamic tables]({{< ref "docs/dev/table/concepts/dynamic_tables" >}})). Their state requirements
-depend on the used operations.
+从概念上讲, 源表从来不会在状态中被完全保存。 实现者在处理逻辑表(即[动态表]({{< ref "docs/dev/table/concepts/dynamic_tables" >}}))时,
+它们的状态取决于用到的操作。
 {{< /hint >}}
 
-Queries such as `SELECT ... FROM ... WHERE` which only consist of field projections or filters are usually
-stateless pipelines. However, operations such as joins, aggregations, or deduplications require keeping
-intermediate results in a fault-tolerant storage for which Flink's state abstractions are used.
+形如 `SELECT ... FROM ... WHERE` 这种只包含字段映射或过滤器的查询的查询语句通常是无状态的管道。 然而诸如 join 、
+聚合或去重操作需要在Flink抽象的容错存储内保持中间结果。
 
 {{< hint info >}}
-Please refer to the individual operator documentation for more details about how much state is required
-and how to limit a potentially ever-growing state size.
+请参考独立的算子文档来获取更多关于状态需求量和限制潜在状态大小增长的信息。

Review Comment:
   ```suggestion
   请参考独立的算子文档来获取更多关于状态需求量和限制潜在增长状态大小的信息。
   ```



-- 
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.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org