Zakelly commented on code in PR #22582:
URL: https://github.com/apache/flink/pull/22582#discussion_r1495629446
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -111,43 +111,38 @@
env.getCheckpointConfig().setAlignedCheckpointTimeout(Duration.ofSeconds(30));
execution.checkpointing.aligned-checkpoint-timeout: 30 s
```
-在启动时，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
+当激活后，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
`aligned-checkpoint-timeout` 时， 如果 aligned checkpoint 还没完成，那么 Checkpoint 将会转换为
Unaligned Checkpoint。
### 限制
-#### 并发 Checkpoint
+#### 并发 Checkpoints
-Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能也根本就不需要并发的
+Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能根本就不需要并发的
Checkpoint。此外，Savepoint 也不能与非对齐 Checkpoint 同时发生，因此它们将会花费稍长的时间。
#### 与 Watermark 的相互影响
-非对齐 Checkpoint 在恢复的过程中改变了关于 Watermark 的一个隐式保证。目前，Flink 确保了 Watermark 作为恢复的第一步，
+非对齐 Checkpoint 在恢复的过程中打破了关于 Watermark 的一个隐式保证。目前，Flink 确保了生成 Watermark
作为恢复的第一步，
而不是将最近的 Watermark 存放在 Operator 中，以方便扩缩容。在非对齐 Checkpoint 中，这意味着当恢复时，**Flink 会在恢复
-In-flight 数据后再生成 Watermark**。如果您的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
-使用对齐 Checkpoint产生**不同的结果**。如果您的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
-存放在 OperatorState 中。在这种情况下，Watermark 应该使用单键 group 存放在 UnionState 以方便扩缩容。
-
-#### Interplay with long-running record processing
-
-Despite that unaligned checkpoints barriers are able to overtake all other
records in the queue.
-The handling of this barrier still can be delayed if the current record takes
a lot of time to be processed.
-This situation can occur when firing many timers all at once, for example in
windowed operations.
-Second problematic scenario might occur when system is being blocked waiting
for more than one
-network buffer availability when processing a single input record. Flink can
not interrupt processing of
-a single input record, and unaligned checkpoints have to wait for the
currently processed record to be
-fully processed. This can cause problems in two scenarios. Either as a result
of serialisation of a large
-record that doesn't fit into single network buffer or in a flatMap operation,
that produces many output
-records for one input record. In such scenarios back pressure can block
unaligned checkpoints until all
-the network buffers required to process the single input record are available.
-It also can happen in any other situation when the processing of the single
record takes a while.
-As result, the time of the checkpoint can be higher than expected or it can
vary.
-
-#### Certain data distribution patterns are not checkpointed
+In-flight 数据后再生成 Watermark**。如果你的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
+使用对齐 Checkpoint产生**不同的结果**。如果你的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
+存放在 Operator State 中。在这种情况下，Watermark 应该按 key group 存放在 Union State 中以方便扩缩容。
+
+#### 与长时间运行的记录处理的相互作用
+
+尽管未对齐的 checkpoints barriers 能够越过队列中的所有其他记录。但是，如果当前记录需要更多的时间来处理，那么对于这个 barrier
的处理仍可能被延迟。
+例如在窗口操作中，当同时触发多个计时器时，可能会发生这种情况。当系统处理单个输入记录的时候被阻塞，等待多个网络缓冲区可用，这种情况将会第二次发生。Flink
不能中断对单个输入记录的处理，因此未对齐的 checkpoints 必须等待当前记录被完全处理。
+这可能在两种情况下会引发问题。第一种情况是由于一个大记录的序列化的结果无法放入单个网络缓冲区，第二种情况是在 flatMap
操作中，为一个输入记录产生了许多输出记录。
+在这种情况下，反压会阻塞非对齐 checkpoints，直到处理单个输入记录所需的所有网络缓冲区都可用。
Review Comment:
```suggestion
在这种情况下，反压会阻塞非对齐的 checkpoint，直到处理单个输入记录所需的网络缓冲区可用。
```
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -24,67 +24,67 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-# Checkpointing under backpressure
+# 反压状态下的 Checkpoint
通常情况下，对齐 Checkpoint 的时长主要受 Checkpointing 过程中的同步和异步两个部分的影响。
-然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因子将会是传递 Checkpoint Barrier 到
-所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing))
+然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因素将会是传递 Checkpoint Barrier 到
+所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing)
的概述中有说明原因。并且可以通过高 [alignment time and start delay metrics]({{< ref
"docs/ops/monitoring/checkpoint_monitoring" >}}#history-tab)
观察到。
-当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
-1. 消除背压源头，通过优化 Flink 作业，通过调整 Flink 或 JVM 参数，抑或是通过扩容。
-2. 减少 Flink 作业中缓冲在 In-flight 数据的数据量。
-3. 启用非对齐 Checkpoints。
+当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
+1. 通过优化 Flink 作业、调整 Flink 或 JVM 配置或者是通过扩容来消除反压源头。
+2. 减少 Flink 作业中缓冲的大量 In-flight 数据。
+3. 启用非对齐 Checkpoints。
+
这些选项并不是互斥的，可以组合在一起。本文档重点介绍后两个选项。
## 缓冲区 Debloating
-Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的 In-flight 数据的数据量。缓冲区 Debloating
机
+Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的大量 In-flight 数据。缓冲区 Debloating 机
制可以通过将属性`taskmanager.network.memory.buffer-debloat.enabled`设置为`true`来启用。
-此特性对对齐和非对齐 Checkpoint 都生效，并且在这两种情况下都能缩短 Checkpointing 的时间，不过 Debloating 的效果对于
-对齐 Checkpoint 最明显。
+此功能适用于对齐和未对齐的 Checkpoint，并且可以在这两种情况下改善 Checkpoint 时间，但 Debloating 的效果在
Checkpoint 对齐时最为明显。
当在非对齐 Checkpoint 情况下使用缓冲区 Debloating 时，额外的好处是 Checkpoint 大小会更小，并且恢复时间更快 (需要保存
和恢复的 In-flight 数据更少)。
-有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，可以参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
-请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲在 In-flight 数据的数据量。
+有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，请参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
+请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲的大量 In-flight 数据。
-## 非对齐 Checkpoints
+## 非对齐的 Checkpoints
从Flink 1.11开始，Checkpoint 可以是非对齐的。
[Unaligned checkpoints]({{< ref "docs/concepts/stateful-stream-processing"
>}}#unaligned-checkpointing)
-包含 In-flight 数据(例如，存储在缓冲区中的数据)作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
-Checkpoint 时长变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中。
+包含 In-flight 数据（例如，存储在缓冲区中的数据）作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
+Checkpoint 持续时间变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中了。
-如果您的 Checkpointing 由于背压导致周期非常的长，您应该使用非对齐 Checkpoint。这样，Checkpointing 时间基本上就与
-端到端延迟无关。请注意，非对齐 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
-正的瓶颈时，您不应当使用非对齐 Checkpointing。
+如果由于反压导致你的 Checkpointing 持续时间非常长，你应该使用非对齐 Checkpoints。这样，Checkpointing 时间基本上就与
+端到端延迟无关。请注意，非对齐的 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
Review Comment:
```suggestion
端到端延迟无关。请注意，非对齐的 checkpoint 会增加状态存储的 I/O，因此当状态存储的 I/O 是整个 checkpoint 过程当中真
```
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -111,43 +111,38 @@
env.getCheckpointConfig().setAlignedCheckpointTimeout(Duration.ofSeconds(30));
execution.checkpointing.aligned-checkpoint-timeout: 30 s
```
-在启动时，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
+当激活后，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
`aligned-checkpoint-timeout` 时， 如果 aligned checkpoint 还没完成，那么 Checkpoint 将会转换为
Unaligned Checkpoint。
### 限制
-#### 并发 Checkpoint
+#### 并发 Checkpoints
-Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能也根本就不需要并发的
+Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能根本就不需要并发的
Checkpoint。此外，Savepoint 也不能与非对齐 Checkpoint 同时发生，因此它们将会花费稍长的时间。
#### 与 Watermark 的相互影响
-非对齐 Checkpoint 在恢复的过程中改变了关于 Watermark 的一个隐式保证。目前，Flink 确保了 Watermark 作为恢复的第一步，
+非对齐 Checkpoint 在恢复的过程中打破了关于 Watermark 的一个隐式保证。目前，Flink 确保了生成 Watermark
作为恢复的第一步，
而不是将最近的 Watermark 存放在 Operator 中，以方便扩缩容。在非对齐 Checkpoint 中，这意味着当恢复时，**Flink 会在恢复
-In-flight 数据后再生成 Watermark**。如果您的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
-使用对齐 Checkpoint产生**不同的结果**。如果您的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
-存放在 OperatorState 中。在这种情况下，Watermark 应该使用单键 group 存放在 UnionState 以方便扩缩容。
-
-#### Interplay with long-running record processing
-
-Despite that unaligned checkpoints barriers are able to overtake all other
records in the queue.
-The handling of this barrier still can be delayed if the current record takes
a lot of time to be processed.
-This situation can occur when firing many timers all at once, for example in
windowed operations.
-Second problematic scenario might occur when system is being blocked waiting
for more than one
-network buffer availability when processing a single input record. Flink can
not interrupt processing of
-a single input record, and unaligned checkpoints have to wait for the
currently processed record to be
-fully processed. This can cause problems in two scenarios. Either as a result
of serialisation of a large
-record that doesn't fit into single network buffer or in a flatMap operation,
that produces many output
-records for one input record. In such scenarios back pressure can block
unaligned checkpoints until all
-the network buffers required to process the single input record are available.
-It also can happen in any other situation when the processing of the single
record takes a while.
-As result, the time of the checkpoint can be higher than expected or it can
vary.
-
-#### Certain data distribution patterns are not checkpointed
+In-flight 数据后再生成 Watermark**。如果你的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
+使用对齐 Checkpoint产生**不同的结果**。如果你的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
+存放在 Operator State 中。在这种情况下，Watermark 应该按 key group 存放在 Union State 中以方便扩缩容。
+
+#### 与长时间运行的记录处理的相互作用
+
+尽管未对齐的 checkpoints barriers 能够越过队列中的所有其他记录。但是，如果当前记录需要更多的时间来处理，那么对于这个 barrier
的处理仍可能被延迟。
Review Comment:
```suggestion
尽管未对齐的 checkpoint barrier 能够越过队列中的所有其他记录。但是，如果当前记录需要更多的时间来处理，那么对于这个 barrier
的处理仍可能被延迟。
```
##########
docs/layouts/shortcodes/generated/checkpointing_configuration.html:
##########
@@ -12,55 +12,55 @@
<td><h5>state.backend.incremental</h5></td>
<td style="word-wrap: break-word;">false</td>
<td>Boolean</td>
- <td>Option whether the state backend should create incremental
checkpoints, if possible. For an incremental checkpoint, only a diff from the
previous checkpoint is stored, rather than the complete checkpoint state. Once
enabled, the state size shown in web UI or fetched from rest API only
represents the delta checkpoint size instead of full checkpoint size. Some
state backends may not support incremental checkpoints and ignore this
option.</td>
+ <td>选择是否启用 State Backend 创建增量 Checkpoint（如果可能）。对于增量
Checkpoint，只会存储与上一个 Checkpoint 的差异，而不是完整的 Checkpoint State。一旦启用，Web UI 中显示的
State 大小或从 REST API 获取的 State 大小仅表示增量 Checkpoint 大小，而不是完整的 Checkpoint 大小。某些
State Backend 可能不支持增量 Checkpoint 并忽略此选项。</td>
Review Comment:
Hi, I think those generated docs should not be translated into Chinese.
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -24,67 +24,67 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-# Checkpointing under backpressure
+# 反压状态下的 Checkpoint
通常情况下，对齐 Checkpoint 的时长主要受 Checkpointing 过程中的同步和异步两个部分的影响。
-然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因子将会是传递 Checkpoint Barrier 到
-所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing))
+然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因素将会是传递 Checkpoint Barrier 到
+所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing)
的概述中有说明原因。并且可以通过高 [alignment time and start delay metrics]({{< ref
"docs/ops/monitoring/checkpoint_monitoring" >}}#history-tab)
观察到。
-当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
-1. 消除背压源头，通过优化 Flink 作业，通过调整 Flink 或 JVM 参数，抑或是通过扩容。
-2. 减少 Flink 作业中缓冲在 In-flight 数据的数据量。
-3. 启用非对齐 Checkpoints。
+当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
+1. 通过优化 Flink 作业、调整 Flink 或 JVM 配置或者是通过扩容来消除反压源头。
+2. 减少 Flink 作业中缓冲的大量 In-flight 数据。
+3. 启用非对齐 Checkpoints。
+
这些选项并不是互斥的，可以组合在一起。本文档重点介绍后两个选项。
## 缓冲区 Debloating
-Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的 In-flight 数据的数据量。缓冲区 Debloating
机
+Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的大量 In-flight 数据。缓冲区 Debloating 机
制可以通过将属性`taskmanager.network.memory.buffer-debloat.enabled`设置为`true`来启用。
-此特性对对齐和非对齐 Checkpoint 都生效，并且在这两种情况下都能缩短 Checkpointing 的时间，不过 Debloating 的效果对于
-对齐 Checkpoint 最明显。
+此功能适用于对齐和未对齐的 Checkpoint，并且可以在这两种情况下改善 Checkpoint 时间，但 Debloating 的效果在
Checkpoint 对齐时最为明显。
当在非对齐 Checkpoint 情况下使用缓冲区 Debloating 时，额外的好处是 Checkpoint 大小会更小，并且恢复时间更快 (需要保存
和恢复的 In-flight 数据更少)。
-有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，可以参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
-请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲在 In-flight 数据的数据量。
+有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，请参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
+请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲的大量 In-flight 数据。
-## 非对齐 Checkpoints
+## 非对齐的 Checkpoints
从Flink 1.11开始，Checkpoint 可以是非对齐的。
[Unaligned checkpoints]({{< ref "docs/concepts/stateful-stream-processing"
>}}#unaligned-checkpointing)
-包含 In-flight 数据(例如，存储在缓冲区中的数据)作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
-Checkpoint 时长变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中。
+包含 In-flight 数据（例如，存储在缓冲区中的数据）作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
+Checkpoint 持续时间变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中了。
-如果您的 Checkpointing 由于背压导致周期非常的长，您应该使用非对齐 Checkpoint。这样，Checkpointing 时间基本上就与
-端到端延迟无关。请注意，非对齐 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
-正的瓶颈时，您不应当使用非对齐 Checkpointing。
+如果由于反压导致你的 Checkpointing 持续时间非常长，你应该使用非对齐 Checkpoints。这样，Checkpointing 时间基本上就与
+端到端延迟无关。请注意，非对齐的 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
+正的瓶颈时，你不应当使用它。
-为了启用非对齐 Checkpoint，您可以：
+为了启用非对齐的 checkpoints，你可以：
Review Comment:
```suggestion
为了启用非对齐的 checkpoint，你可以：
```
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -111,43 +111,38 @@
env.getCheckpointConfig().setAlignedCheckpointTimeout(Duration.ofSeconds(30));
execution.checkpointing.aligned-checkpoint-timeout: 30 s
```
-在启动时，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
+当激活后，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
`aligned-checkpoint-timeout` 时， 如果 aligned checkpoint 还没完成，那么 Checkpoint 将会转换为
Unaligned Checkpoint。
### 限制
-#### 并发 Checkpoint
+#### 并发 Checkpoints
-Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能也根本就不需要并发的
+Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能根本就不需要并发的
Checkpoint。此外，Savepoint 也不能与非对齐 Checkpoint 同时发生，因此它们将会花费稍长的时间。
#### 与 Watermark 的相互影响
-非对齐 Checkpoint 在恢复的过程中改变了关于 Watermark 的一个隐式保证。目前，Flink 确保了 Watermark 作为恢复的第一步，
+非对齐 Checkpoint 在恢复的过程中打破了关于 Watermark 的一个隐式保证。目前，Flink 确保了生成 Watermark
作为恢复的第一步，
而不是将最近的 Watermark 存放在 Operator 中，以方便扩缩容。在非对齐 Checkpoint 中，这意味着当恢复时，**Flink 会在恢复
-In-flight 数据后再生成 Watermark**。如果您的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
-使用对齐 Checkpoint产生**不同的结果**。如果您的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
-存放在 OperatorState 中。在这种情况下，Watermark 应该使用单键 group 存放在 UnionState 以方便扩缩容。
-
-#### Interplay with long-running record processing
-
-Despite that unaligned checkpoints barriers are able to overtake all other
records in the queue.
-The handling of this barrier still can be delayed if the current record takes
a lot of time to be processed.
-This situation can occur when firing many timers all at once, for example in
windowed operations.
-Second problematic scenario might occur when system is being blocked waiting
for more than one
-network buffer availability when processing a single input record. Flink can
not interrupt processing of
-a single input record, and unaligned checkpoints have to wait for the
currently processed record to be
-fully processed. This can cause problems in two scenarios. Either as a result
of serialisation of a large
-record that doesn't fit into single network buffer or in a flatMap operation,
that produces many output
-records for one input record. In such scenarios back pressure can block
unaligned checkpoints until all
-the network buffers required to process the single input record are available.
-It also can happen in any other situation when the processing of the single
record takes a while.
-As result, the time of the checkpoint can be higher than expected or it can
vary.
-
-#### Certain data distribution patterns are not checkpointed
+In-flight 数据后再生成 Watermark**。如果你的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
+使用对齐 Checkpoint产生**不同的结果**。如果你的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
+存放在 Operator State 中。在这种情况下，Watermark 应该按 key group 存放在 Union State 中以方便扩缩容。
+
+#### 与长时间运行的记录处理的相互作用
+
+尽管未对齐的 checkpoints barriers 能够越过队列中的所有其他记录。但是，如果当前记录需要更多的时间来处理，那么对于这个 barrier
的处理仍可能被延迟。
+例如在窗口操作中，当同时触发多个计时器时，可能会发生这种情况。当系统处理单个输入记录的时候被阻塞，等待多个网络缓冲区可用，这种情况将会第二次发生。Flink
不能中断对单个输入记录的处理，因此未对齐的 checkpoints 必须等待当前记录被完全处理。
Review Comment:
```suggestion
例如在窗口操作中，当同时触发多个计时器时，可能会发生这种情况。当系统处理单个输入记录的时候被阻塞，等待多个网络缓冲区可用，这种情况也会发生。Flink
不能中断对单个输入记录的处理，因此未对齐的 checkpoint 必须等待当前记录被完全处理。
```
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -24,67 +24,67 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-# Checkpointing under backpressure
+# 反压状态下的 Checkpoint
通常情况下，对齐 Checkpoint 的时长主要受 Checkpointing 过程中的同步和异步两个部分的影响。
-然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因子将会是传递 Checkpoint Barrier 到
-所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing))
+然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因素将会是传递 Checkpoint Barrier 到
+所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing)
的概述中有说明原因。并且可以通过高 [alignment time and start delay metrics]({{< ref
"docs/ops/monitoring/checkpoint_monitoring" >}}#history-tab)
观察到。
-当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
-1. 消除背压源头，通过优化 Flink 作业，通过调整 Flink 或 JVM 参数，抑或是通过扩容。
-2. 减少 Flink 作业中缓冲在 In-flight 数据的数据量。
-3. 启用非对齐 Checkpoints。
+当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
+1. 通过优化 Flink 作业、调整 Flink 或 JVM 配置或者是通过扩容来消除反压源头。
+2. 减少 Flink 作业中缓冲的大量 In-flight 数据。
+3. 启用非对齐 Checkpoints。
+
这些选项并不是互斥的，可以组合在一起。本文档重点介绍后两个选项。
## 缓冲区 Debloating
-Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的 In-flight 数据的数据量。缓冲区 Debloating
机
+Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的大量 In-flight 数据。缓冲区 Debloating 机
制可以通过将属性`taskmanager.network.memory.buffer-debloat.enabled`设置为`true`来启用。
-此特性对对齐和非对齐 Checkpoint 都生效，并且在这两种情况下都能缩短 Checkpointing 的时间，不过 Debloating 的效果对于
-对齐 Checkpoint 最明显。
+此功能适用于对齐和未对齐的 Checkpoint，并且可以在这两种情况下改善 Checkpoint 时间，但 Debloating 的效果在
Checkpoint 对齐时最为明显。
当在非对齐 Checkpoint 情况下使用缓冲区 Debloating 时，额外的好处是 Checkpoint 大小会更小，并且恢复时间更快 (需要保存
和恢复的 In-flight 数据更少)。
-有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，可以参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
-请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲在 In-flight 数据的数据量。
+有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，请参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
+请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲的大量 In-flight 数据。
-## 非对齐 Checkpoints
+## 非对齐的 Checkpoints
从Flink 1.11开始，Checkpoint 可以是非对齐的。
[Unaligned checkpoints]({{< ref "docs/concepts/stateful-stream-processing"
>}}#unaligned-checkpointing)
-包含 In-flight 数据(例如，存储在缓冲区中的数据)作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
-Checkpoint 时长变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中。
+包含 In-flight 数据（例如，存储在缓冲区中的数据）作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
+Checkpoint 持续时间变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中了。
-如果您的 Checkpointing 由于背压导致周期非常的长，您应该使用非对齐 Checkpoint。这样，Checkpointing 时间基本上就与
-端到端延迟无关。请注意，非对齐 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
-正的瓶颈时，您不应当使用非对齐 Checkpointing。
+如果由于反压导致你的 Checkpointing 持续时间非常长，你应该使用非对齐 Checkpoints。这样，Checkpointing 时间基本上就与
Review Comment:
```suggestion
如果由于反压导致你的 checkpoint 持续时间非常长，你应该使用非对齐 checkpoint。这样，checkpoint 时间基本上就与
```
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -111,43 +111,38 @@
env.getCheckpointConfig().setAlignedCheckpointTimeout(Duration.ofSeconds(30));
execution.checkpointing.aligned-checkpoint-timeout: 30 s
```
-在启动时，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
+当激活后，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
`aligned-checkpoint-timeout` 时， 如果 aligned checkpoint 还没完成，那么 Checkpoint 将会转换为
Unaligned Checkpoint。
### 限制
-#### 并发 Checkpoint
+#### 并发 Checkpoints
-Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能也根本就不需要并发的
+Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能根本就不需要并发的
Checkpoint。此外，Savepoint 也不能与非对齐 Checkpoint 同时发生，因此它们将会花费稍长的时间。
#### 与 Watermark 的相互影响
-非对齐 Checkpoint 在恢复的过程中改变了关于 Watermark 的一个隐式保证。目前，Flink 确保了 Watermark 作为恢复的第一步，
+非对齐 Checkpoint 在恢复的过程中打破了关于 Watermark 的一个隐式保证。目前，Flink 确保了生成 Watermark
作为恢复的第一步，
而不是将最近的 Watermark 存放在 Operator 中，以方便扩缩容。在非对齐 Checkpoint 中，这意味着当恢复时，**Flink 会在恢复
-In-flight 数据后再生成 Watermark**。如果您的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
-使用对齐 Checkpoint产生**不同的结果**。如果您的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
-存放在 OperatorState 中。在这种情况下，Watermark 应该使用单键 group 存放在 UnionState 以方便扩缩容。
-
-#### Interplay with long-running record processing
-
-Despite that unaligned checkpoints barriers are able to overtake all other
records in the queue.
-The handling of this barrier still can be delayed if the current record takes
a lot of time to be processed.
-This situation can occur when firing many timers all at once, for example in
windowed operations.
-Second problematic scenario might occur when system is being blocked waiting
for more than one
-network buffer availability when processing a single input record. Flink can
not interrupt processing of
-a single input record, and unaligned checkpoints have to wait for the
currently processed record to be
-fully processed. This can cause problems in two scenarios. Either as a result
of serialisation of a large
-record that doesn't fit into single network buffer or in a flatMap operation,
that produces many output
-records for one input record. In such scenarios back pressure can block
unaligned checkpoints until all
-the network buffers required to process the single input record are available.
-It also can happen in any other situation when the processing of the single
record takes a while.
-As result, the time of the checkpoint can be higher than expected or it can
vary.
-
-#### Certain data distribution patterns are not checkpointed
+In-flight 数据后再生成 Watermark**。如果你的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
+使用对齐 Checkpoint产生**不同的结果**。如果你的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
+存放在 Operator State 中。在这种情况下，Watermark 应该按 key group 存放在 Union State 中以方便扩缩容。
+
+#### 与长时间运行的记录处理的相互作用
Review Comment:
```suggestion
#### 与长时间运行作业的交互
```
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -111,43 +111,38 @@
env.getCheckpointConfig().setAlignedCheckpointTimeout(Duration.ofSeconds(30));
execution.checkpointing.aligned-checkpoint-timeout: 30 s
```
-在启动时，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
+当激活后，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过
`aligned-checkpoint-timeout` 时， 如果 aligned checkpoint 还没完成，那么 Checkpoint 将会转换为
Unaligned Checkpoint。
### 限制
-#### 并发 Checkpoint
+#### 并发 Checkpoints
-Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能也根本就不需要并发的
+Flink 当前并不支持并发的非对齐 Checkpoint。然而，由于更可预测的和更短的 Checkpointing 时长，可能根本就不需要并发的
Checkpoint。此外，Savepoint 也不能与非对齐 Checkpoint 同时发生，因此它们将会花费稍长的时间。
#### 与 Watermark 的相互影响
-非对齐 Checkpoint 在恢复的过程中改变了关于 Watermark 的一个隐式保证。目前，Flink 确保了 Watermark 作为恢复的第一步，
+非对齐 Checkpoint 在恢复的过程中打破了关于 Watermark 的一个隐式保证。目前，Flink 确保了生成 Watermark
作为恢复的第一步，
而不是将最近的 Watermark 存放在 Operator 中，以方便扩缩容。在非对齐 Checkpoint 中，这意味着当恢复时，**Flink 会在恢复
-In-flight 数据后再生成 Watermark**。如果您的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
-使用对齐 Checkpoint产生**不同的结果**。如果您的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
-存放在 OperatorState 中。在这种情况下，Watermark 应该使用单键 group 存放在 UnionState 以方便扩缩容。
-
-#### Interplay with long-running record processing
-
-Despite that unaligned checkpoints barriers are able to overtake all other
records in the queue.
-The handling of this barrier still can be delayed if the current record takes
a lot of time to be processed.
-This situation can occur when firing many timers all at once, for example in
windowed operations.
-Second problematic scenario might occur when system is being blocked waiting
for more than one
-network buffer availability when processing a single input record. Flink can
not interrupt processing of
-a single input record, and unaligned checkpoints have to wait for the
currently processed record to be
-fully processed. This can cause problems in two scenarios. Either as a result
of serialisation of a large
-record that doesn't fit into single network buffer or in a flatMap operation,
that produces many output
-records for one input record. In such scenarios back pressure can block
unaligned checkpoints until all
-the network buffers required to process the single input record are available.
-It also can happen in any other situation when the processing of the single
record takes a while.
-As result, the time of the checkpoint can be higher than expected or it can
vary.
-
-#### Certain data distribution patterns are not checkpointed
+In-flight 数据后再生成 Watermark**。如果你的 Pipeline 中使用了**对每条记录都应用最新的 Watermark
的算子**将会相对于
+使用对齐 Checkpoint产生**不同的结果**。如果你的 Operator 依赖于最新的 Watermark 始终可用，解决办法是将
Watermark
+存放在 Operator State 中。在这种情况下，Watermark 应该按 key group 存放在 Union State 中以方便扩缩容。
+
+#### 与长时间运行的记录处理的相互作用
+
+尽管未对齐的 checkpoints barriers 能够越过队列中的所有其他记录。但是，如果当前记录需要更多的时间来处理，那么对于这个 barrier
的处理仍可能被延迟。
+例如在窗口操作中，当同时触发多个计时器时，可能会发生这种情况。当系统处理单个输入记录的时候被阻塞，等待多个网络缓冲区可用，这种情况将会第二次发生。Flink
不能中断对单个输入记录的处理，因此未对齐的 checkpoints 必须等待当前记录被完全处理。
+这可能在两种情况下会引发问题。第一种情况是由于一个大记录的序列化的结果无法放入单个网络缓冲区，第二种情况是在 flatMap
操作中，为一个输入记录产生了许多输出记录。
+在这种情况下，反压会阻塞非对齐 checkpoints，直到处理单个输入记录所需的所有网络缓冲区都可用。
+当处理单个记录的时间较长时，也可能发生这种情况。因此，checkpoint 的时间可能高于预期或可能会有所不同。
+
+
+#### 某些数据分发模式不会进行检查点保存
有一部分包含属性的的连接无法与 Channel 中的数据一样保存在 Checkpoint 中。为了保留这些特性并且确保没有状态冲突或
非预期的行为，非对齐 Checkpoint 对于这些类型的连接是禁用的。所有其他的交换仍然执行非对齐 Checkpoint。
+存在一些连接类型，其属性无法与存储在 Checkpoint 中的通道数据保持一致。为了保留这些特性并确保没有状态损坏或意外行为，对于这些连接，非对齐
Checkpoint 被禁用。所有其他交换仍会执行非对齐 Checkpoint。
Review Comment:
多出来的部分？
##########
docs/content.zh/docs/ops/state/checkpointing_under_backpressure.md:
##########
@@ -24,67 +24,67 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-# Checkpointing under backpressure
+# 反压状态下的 Checkpoint
通常情况下，对齐 Checkpoint 的时长主要受 Checkpointing 过程中的同步和异步两个部分的影响。
-然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因子将会是传递 Checkpoint Barrier 到
-所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing))
+然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因素将会是传递 Checkpoint Barrier 到
+所有的算子/子任务的时间。这在 [checkpointing process]({{< ref
"docs/concepts/stateful-stream-processing" >}}#checkpointing)
的概述中有说明原因。并且可以通过高 [alignment time and start delay metrics]({{< ref
"docs/ops/monitoring/checkpoint_monitoring" >}}#history-tab)
观察到。
-当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
-1. 消除背压源头，通过优化 Flink 作业，通过调整 Flink 或 JVM 参数，抑或是通过扩容。
-2. 减少 Flink 作业中缓冲在 In-flight 数据的数据量。
-3. 启用非对齐 Checkpoints。
+当这种情况发生并成为一个问题时，有三种方法可以解决这个问题：
+1. 通过优化 Flink 作业、调整 Flink 或 JVM 配置或者是通过扩容来消除反压源头。
+2. 减少 Flink 作业中缓冲的大量 In-flight 数据。
+3. 启用非对齐 Checkpoints。
+
这些选项并不是互斥的，可以组合在一起。本文档重点介绍后两个选项。
## 缓冲区 Debloating
-Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的 In-flight 数据的数据量。缓冲区 Debloating
机
+Flink 1.14 引入了一个新的工具，用于自动控制在 Flink 算子/子任务之间缓冲的大量 In-flight 数据。缓冲区 Debloating 机
制可以通过将属性`taskmanager.network.memory.buffer-debloat.enabled`设置为`true`来启用。
-此特性对对齐和非对齐 Checkpoint 都生效，并且在这两种情况下都能缩短 Checkpointing 的时间，不过 Debloating 的效果对于
-对齐 Checkpoint 最明显。
+此功能适用于对齐和未对齐的 Checkpoint，并且可以在这两种情况下改善 Checkpoint 时间，但 Debloating 的效果在
Checkpoint 对齐时最为明显。
当在非对齐 Checkpoint 情况下使用缓冲区 Debloating 时，额外的好处是 Checkpoint 大小会更小，并且恢复时间更快 (需要保存
和恢复的 In-flight 数据更少)。
-有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，可以参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
-请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲在 In-flight 数据的数据量。
+有关缓冲区 Debloating 功能如何工作以及如何配置的更多信息，请参考 [network memory tuning guide]({{< ref
"docs/deployment/memory/network_mem_tuning" >}})。
+请注意，您仍然可以继续使用在前面调优指南中介绍过的方式来手动减少缓冲的大量 In-flight 数据。
-## 非对齐 Checkpoints
+## 非对齐的 Checkpoints
从Flink 1.11开始，Checkpoint 可以是非对齐的。
[Unaligned checkpoints]({{< ref "docs/concepts/stateful-stream-processing"
>}}#unaligned-checkpointing)
-包含 In-flight 数据(例如，存储在缓冲区中的数据)作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
-Checkpoint 时长变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中。
+包含 In-flight 数据（例如，存储在缓冲区中的数据）作为 Checkpoint State的一部分，允许 Checkpoint Barrier
跨越这些缓冲区。因此，
+Checkpoint 持续时间变得与当前吞吐量无关，因为 Checkpoint Barrier 实际上已经不再嵌入到数据流当中了。
-如果您的 Checkpointing 由于背压导致周期非常的长，您应该使用非对齐 Checkpoint。这样，Checkpointing 时间基本上就与
-端到端延迟无关。请注意，非对齐 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
-正的瓶颈时，您不应当使用非对齐 Checkpointing。
+如果由于反压导致你的 Checkpointing 持续时间非常长，你应该使用非对齐 Checkpoints。这样，Checkpointing 时间基本上就与
+端到端延迟无关。请注意，非对齐的 Checkpointing 会增加状态存储的 I/O，因此当状态存储的 I/O 是 整个 Checkpointing
过程当中真
+正的瓶颈时，你不应当使用它。
-为了启用非对齐 Checkpoint，您可以：
+为了启用非对齐的 checkpoints，你可以：
{{< tabs "4b9c6a74-8a45-4ad2-9e80-52fe44a85991" >}}
{{< tab "Java" >}}
```java
StreamExecutionEnvironment env =
StreamExecutionEnvironment.getExecutionEnvironment();
-// 启用非对齐 Checkpoint
+// 启用非对齐的 checkpoints
Review Comment:
还应当使用 checkpoint ，其他地方同理。
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
