[FLINK-37502][docs] Translate documentation for Disaggregated State Management into Chinese #26312
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davidradl
reviewed
Mar 20, 2025
| @@ -497,6 +497,8 @@ In a typical stateful Flink Application you don't need operators state. It is | |||
| mostly a special type of state that is used in source/sink implementations and | |||
| scenarios where you don't have a key by which state can be partitioned. | |||
|
|
|||
| **Notes:** Operator state is still not supported in Python DataStream API. | |||
There was a problem hiding this comment.
nit: in Python -> in the Python
Zakelly
reviewed
Mar 31, 2025
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md
Outdated
Show resolved
Hide resolved
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md
Outdated
Show resolved
Hide resolved
| This is called the 'disaggregated state management'. For more information about this, | ||
| please see [Disaggregated State Management]({{< ref "docs/ops/state/disaggregated_state" >}}). | ||
| 新的 state API 比以前的 API 更灵活，用户可以通过新的 API 使用异步状态操作，这使得新的 API 更加强大有效。 | ||
| 异步 state 访问对“存算分离”来说是必要的，即令状态后端支持大状态和在必要时将文件溢出到远程文件系统的能力。更多关于 |
There was a problem hiding this comment.
Suggested change
| 异步 state 访问对“存算分离”来说是必要的，即令状态后端支持大状态和在必要时将文件溢出到远程文件系统的能力。更多关于 | |
| 异步 state 访问对存算分离来说是必要的，即令状态后端支持大状态时将文件溢出到远程文件系统的能力。更多关于 |
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md
Outdated
Show resolved
Hide resolved
| 和之前的 state API 不同，新的 state API 允许用户使用异步状态访问。每种类型的状态都提供了两种版本的 API：同步和异步。 | ||
| 同步 API 是一个阻塞等待状态访问完成的 API。异步 API 是非阻塞的，它会返回一个 `StateFuture`，这个 `StateFuture` 会在状态访问完成时完成。 | ||
| 在 `StateFuture` 完成时，callback 或者 后续逻辑将会被调用（如果有的话）。异步 API 比同步 API 更加高效，更推荐使用异步 API。 | ||
| 注意，**不建议**在同一个用户函数中混合使用同步和异步状态访问。 |
There was a problem hiding this comment.
Suggested change
| 注意，**不建议**在同一个用户函数中混合使用同步和异步状态访问。 | |
| 需要注意，**不建议**在同一个用户函数中混合使用同步和异步状态访问。 |
| 但两个`asyncGet`的完成顺序不能保证。因此，无法保证两个 `StateFuture` 后续步骤的执行顺序，即无法确定元素 A 和 元素 B 的 | ||
| `asyncClear` 和 `asyncUpdate` 的调用顺序。 | ||
|
|
||
| 尽管状态访问方法可能会乱序执行，这也不意味着所有用户代码会串行执行。在 `processElement`, `flatMap` 或者 `thenXXxx` |
There was a problem hiding this comment.
Suggested change
| 尽管状态访问方法可能会乱序执行，这也不意味着所有用户代码会串行执行。在 `processElement`, `flatMap` 或者 `thenXXxx` | |
| 尽管状态访问方法可能会乱序执行，这也不意味着所有用户代码会并行执行。在 `processElement`, `flatMap` 或者 `thenXXxx` |
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md
Outdated
Show resolved
Hide resolved
|
|
||
| 通常，您无需担心状态访问方法的执行顺序问题，但 Flink 仍确保一些规则: | ||
| * 同 key 的元素的执行顺序严格按照元素到达 `flatMap` 的顺序执行的。 | ||
| * 传递给 `thenXXxx` 方法的函数会按照调用链的顺序执行。如果它们不属于调用链，或者同时有多个调用链，则无法保证执行顺序。 |
There was a problem hiding this comment.
Suggested change
| * 传递给 `thenXXxx` 方法的函数会按照调用链的顺序执行。如果它们不属于调用链，或者同时有多个调用链，则无法保证执行顺序。 | |
| * 传递给 `thenXXxx` 方法的函数会按照调用链的顺序执行。如果同时有多个调用链，则无法保证执行顺序。 |
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md
Outdated
Show resolved
Hide resolved
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md
Outdated
Show resolved
Hide resolved
…anagement into Chinese
Zakelly
reviewed
Apr 1, 2025
| 在 Flink 的前 10 年，状态管理是基于 TaskManager 的内存或本地磁盘。该方法适用于大多数用户场景，但存在一些限制： | ||
| * **本地磁盘限制**: 状态大小受限于 TaskManager 的内存或者磁盘大小。 | ||
| * **资源使用尖刺**：本地状态模型会在 checkpoint 时触发 SST 文件的 compaction，引起 CPU 和网络 I/O 的尖刺。 | ||
| * **恢复繁重**：在恢复期间，需要下载状态。恢复时间与状态大小成比例，大状态的恢复非常慢。 |
There was a problem hiding this comment.
Suggested change
| * **恢复繁重**：在恢复期间，需要下载状态。恢复时间与状态大小成比例，大状态的恢复非常慢。 | |
| * **恢复很慢**：在恢复期间，状态后端需要下载状态。恢复时间与状态大小成比例，大状态的恢复非常慢。 |
Comment on lines
+37
to
+43
| 在 Flink 2.0，我们引入了存算分离(disaggregated state management). 存算分离允许用户将状态直接存储在第三方存储系统，如 S3，HDFS 等， | ||
| 这在状态非常大时很有用。存算分离以一种更有效的方式存储状态，轻量地持久化或恢复状态。存算分离有如下好处： | ||
| * **状态大小无限制**：状态大小仅取决于外部存储系统大小。 | ||
| * **资源使用稳定**：状态被存储在外部存储上，因此 checkpoint 可以非常轻量。SST 文件的 compaction 也可以被放在远程（TODO）。 | ||
| * **恢复快速**：在恢复期间无需下载状态到本地，恢复时间与状态大小无关。 | ||
| * **灵活**：用户可以轻松地选择不同的外部存储系统或I/O性能级别，或者根据需求独立地扩展存储资源，而不需要改变他们的硬件。 | ||
| * **经济实惠**：外部存储通常比本地磁盘便宜。如果有瓶颈，用户可以灵活、独立地调整计算资源以及存储资源。 |
There was a problem hiding this comment.
Suggested change
| 在 Flink 2.0，我们引入了存算分离(disaggregated state management). 存算分离允许用户将状态直接存储在第三方存储系统，如 S3，HDFS 等， | |
| 这在状态非常大时很有用。存算分离以一种更有效的方式存储状态，轻量地持久化或恢复状态。存算分离有如下好处： | |
| * **状态大小无限制**：状态大小仅取决于外部存储系统大小。 | |
| * **资源使用稳定**：状态被存储在外部存储上，因此 checkpoint 可以非常轻量。SST 文件的 compaction 也可以被放在远程（TODO）。 | |
| * **恢复快速**：在恢复期间无需下载状态到本地，恢复时间与状态大小无关。 | |
| * **灵活**：用户可以轻松地选择不同的外部存储系统或I/O性能级别，或者根据需求独立地扩展存储资源，而不需要改变他们的硬件。 | |
| * **经济实惠**：外部存储通常比本地磁盘便宜。如果有瓶颈，用户可以灵活、独立地调整计算资源以及存储资源。 | |
| 在 Flink 2.0，我们引入了存算分离(disaggregated state management)来解决上述问题。 存算分离允许状态后端将状态直接存储在远端存储系统，如 S3，HDFS 等。 | |
| 存算分离以一种更有效的方式存储状态，能够轻量地持久化或恢复状态。它有如下好处： | |
| * **状态大小无限制**：状态大小仅取决于外部存储系统大小。 | |
| * **资源使用稳定**：状态被存储在外部存储上，因此 checkpoint 可以非常轻量。SST 文件的 compaction 也可以被放在远程（TODO）。 | |
| * **恢复快速**：在恢复期间无需下载状态到本地，恢复时间与状态大小无关。 | |
| * **灵活**：用户可以轻松地选择不同的外部存储系统或I/O性能级别，或者根据需求独立地扩展存储资源，而不需要改变他们的硬件。 | |
| * **经济实惠**：外部存储通常比本地磁盘便宜。如果有瓶颈，用户可以灵活、独立地调整计算资源以及存储资源。 |
| Disaggregated state and asynchronous state access are encouraged for large state. However, when | ||
| the state size is small, the local state management with synchronous state access is a better | ||
| choice. | ||
| 对大状态作业，推荐使用存算分离和异步状态访问。如果状态很小，本地状态管理和同步状态访问是更好的选择。 |
There was a problem hiding this comment.
Suggested change
| 对大状态作业，推荐使用存算分离和异步状态访问。如果状态很小，本地状态管理和同步状态访问是更好的选择。 | |
| 对于大状态作业，我们推荐使用存算分离和异步状态访问。如果作业状态很小，本地状态管理和同步状态访问会是更好的选择。 |
Comment on lines
+45
to
+50
| 存算分离包括三个部分： | ||
| * **ForSt 状态后端**: 一个以外部存储系统作为主存的状态后端。它还可以利用本地磁盘进行缓存和缓冲。 | ||
| 异步I/O模型用于读取和写入状态。详细信息请参阅[ForSt State Backend]({{< ref "docs/ops/state/state_backends#the-forststatebackend" >}}). | ||
| * **新的状态 API**: 引入了新的状态 API (State V2) 用于异步状态读取和写入，异步状态访问是存算分离克服高网络延迟的必要组件。 | ||
| 详细信息请参阅[New State APIs]({{< ref "docs/dev/datastream/fault-tolerance/state_v2" >}}). | ||
| * **SQL 支持**: 许多 SQL 算子都被重写以支持存算分离和异步状态访问。用户可以轻松地通过配置项启用这些功能。 |
There was a problem hiding this comment.
Suggested change
| 存算分离包括三个部分： | |
| * **ForSt 状态后端**: 一个以外部存储系统作为主存的状态后端。它还可以利用本地磁盘进行缓存和缓冲。 | |
| 异步I/O模型用于读取和写入状态。详细信息请参阅[ForSt State Backend]({{< ref "docs/ops/state/state_backends#the-forststatebackend" >}}). | |
| * **新的状态 API**: 引入了新的状态 API (State V2) 用于异步状态读取和写入，异步状态访问是存算分离克服高网络延迟的必要组件。 | |
| 详细信息请参阅[New State APIs]({{< ref "docs/dev/datastream/fault-tolerance/state_v2" >}}). | |
| * **SQL 支持**: 许多 SQL 算子都被重写以支持存算分离和异步状态访问。用户可以轻松地通过配置项启用这些功能。 | |
| 存算分离包括三个部分： | |
| * **ForSt 状态后端**: 一个以外部存储系统作为主存的状态后端，它可以利用本地磁盘进行缓存。 | |
| 它使用异步 I/O 模型用于读取和写入状态。详细信息请参阅[ForSt State Backend]({{< ref "docs/ops/state/state_backends#the-forststatebackend" >}}). | |
| * **新的状态 API**: 引入了新的状态 API (State V2) 用于异步状态读取和写入，异步状态访问是存算分离克服高网络延迟的必要组件。 | |
| 详细信息请参阅[New State APIs]({{< ref "docs/dev/datastream/fault-tolerance/state_v2" >}}). | |
| * **SQL 支持**: 许多 SQL 算子使用异步状态 API 来重新实现，用户可以轻松地通过配置项启用这些算子。 |
Comment on lines
+77
to
+79
| 如此一来，您可以在 SQL 作业中使用存算分离和异步状态访问。目前还未全部实现所有 SQL 算子的异步状态访问。 | ||
| 对于还未支持异步状态访问的算子，算子会自动回退到同步状态实现，这种情况下性能可能不是最佳的。 | ||
| 目前支持异步状态访问的有状态算子有： |
There was a problem hiding this comment.
Suggested change
| 如此一来，您可以在 SQL 作业中使用存算分离和异步状态访问。目前还未全部实现所有 SQL 算子的异步状态访问。 | |
| 对于还未支持异步状态访问的算子，算子会自动回退到同步状态实现，这种情况下性能可能不是最佳的。 | |
| 目前支持异步状态访问的有状态算子有： | |
| 如此一来，您可以在 SQL 作业中使用存算分离和异步状态访问。目前我们并未实现所有异步状态访问版本的 SQL 算子。 | |
| 对于还未支持异步状态访问的算子，算子会自动回退到同步状态实现，这种情况下性能可能不是最佳的。 | |
| 目前支持异步状态访问的有状态算子有： |
| 以下场景推荐使用 ForStStateBackend： | ||
| - 大状态、长窗口、大 key/value 状态的作业，本地磁盘空间不足以来存储状态。 | ||
| - 全高可用的设置。 | ||
| - 倾向异步状态访问。ForStStateBackend 是目前唯一支持异步状态访问的状态后端。 |
There was a problem hiding this comment.
Suggested change
| - 倾向异步状态访问。ForStStateBackend 是目前唯一支持异步状态访问的状态后端。 | |
| - 希望使用异步状态访问。ForStStateBackend 是目前唯一支持异步状态访问的状态后端。 |
|
|
||
| 以下场景推荐使用 ForStStateBackend： | ||
| - 大状态、长窗口、大 key/value 状态的作业，本地磁盘空间不足以来存储状态。 | ||
| - 全高可用的设置。 |
There was a problem hiding this comment.
Suggested change
| - 全高可用的设置。 | |
| - 需要高可用的作业，定期使用检查点并在遇到报错时恢复。 |
| - 大状态、长窗口、大 key/value 状态的作业，本地磁盘空间不足以来存储状态。 | ||
| - 全高可用的设置。 | ||
| - 倾向异步状态访问。ForStStateBackend 是目前唯一支持异步状态访问的状态后端。 | ||
| - 需要轻量级的 checkpoint 和恢复的作业，例如云原生应用。 |
There was a problem hiding this comment.
Suggested change
| - 需要轻量级的 checkpoint 和恢复的作业，例如云原生应用。 | |
| - 需要轻量级的执行检查点和恢复的作业，例如云原生应用。 |
Comment on lines
+121
to
+124
| 相比 EmbeddedRocksDBStateBackend，ForStStateBackend 将数据保存在远程文件系统上，因此可以存储无限多的状态。TaskManager | ||
| 上的本地磁盘仅用来缓存文件，以提供更好的性能。请注意，当大部分的活跃状态都保存在远程文件系统上时，状态访问的性能可能会受网络延迟的影响。 | ||
| Flink 介绍了异步状态访问以缓解这个问题，您可以使用 State API V2 的异步状态访问方法来从异步状态访问中受益。请参考 | ||
| [State API V2 文档]({{< ref "docs/dev/datastream/fault-tolerance/state_v2" >}}) 以熟悉 State API V2。 |
There was a problem hiding this comment.
Suggested change
| 相比 EmbeddedRocksDBStateBackend，ForStStateBackend 将数据保存在远程文件系统上，因此可以存储无限多的状态。TaskManager | |
| 上的本地磁盘仅用来缓存文件，以提供更好的性能。请注意，当大部分的活跃状态都保存在远程文件系统上时，状态访问的性能可能会受网络延迟的影响。 | |
| Flink 介绍了异步状态访问以缓解这个问题，您可以使用 State API V2 的异步状态访问方法来从异步状态访问中受益。请参考 | |
| [State API V2 文档]({{< ref "docs/dev/datastream/fault-tolerance/state_v2" >}}) 以熟悉 State API V2。 | |
| 相比 EmbeddedRocksDBStateBackend，ForStStateBackend 将数据保存在远程文件系统上，因此可以存储无限多的状态。TaskManager | |
| 上的本地磁盘仅用来缓存文件，以提供更好的性能。请注意，当大部分的活跃状态都保存在远程文件系统上时，状态访问的性能可能会受网络延迟的影响。 | |
| Flink 引入了异步状态访问以缓解这个问题，您可以使用 State API V2 的异步状态访问方法。请参考 | |
| [State API V2 文档]({{< ref "docs/dev/datastream/fault-tolerance/state_v2" >}}) 以熟悉并使用 State API V2。 |
Comment on lines
+129
to
+130
| 另一方面，`RocksDB` 可以根据可用的 disk 空间扩展。 然而，每个状态的读取和更新都需要(反)序列化，而且在 disk 上进行读操作的性能可能要比基于内存的 state backend 慢一个数量级。 | ||
| 如果您需要处理非常大的状态，并且状态大小超过可用的磁盘空间，或者更倾向于在云原生的设置下快速扩展，那么 `ForStStateBackend` 是一个不错的选择。 |
There was a problem hiding this comment.
Suggested change
| 另一方面，`RocksDB` 可以根据可用的 disk 空间扩展。 然而，每个状态的读取和更新都需要(反)序列化，而且在 disk 上进行读操作的性能可能要比基于内存的 state backend 慢一个数量级。 | |
| 如果您需要处理非常大的状态，并且状态大小超过可用的磁盘空间，或者更倾向于在云原生的设置下快速扩展，那么 `ForStStateBackend` 是一个不错的选择。 | |
| 另一方面，`RocksDB` 可以根据可用的本地磁盘空间扩展。 然而，每个状态的读取和更新都需要(反)序列化，而且在磁盘上进行读操作的性能可能要比基于内存的状态后端慢一个数量级。 | |
| 如果您需要处理非常大的状态，并且状态大小超过可用的磁盘空间，或者更倾向于在云原生的设置下快速扩展，那么 `ForStStateBackend` 是一个不错的选择。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the purpose of the change
Chinese documents for Disaggregate State and new State APIs
Brief change log
Verifying this change
This change is a docs work without any test coverage.
Does this pull request potentially affect one of the following parts:
@Public(Evolving): (no)Documentation