klion26 commented on a change in pull request #8300: [FLINK-11638][docs-zh] 
Translate Savepoints page into Chinese
URL: https://github.com/apache/flink/pull/8300#discussion_r280980371
 
 

 ##########
 File path: docs/ops/state/savepoints.zh.md
 ##########
 @@ -25,32 +25,22 @@ under the License.
 * toc
 {:toc}
 
-## What is a Savepoint? How is a Savepoint different from a Checkpoint?
+## 什么是 Savepoint ? Savepoint 与 Checkpoint 有什么不同?
 
-A Savepoint is a consistent image of the execution state of a streaming job, 
created via Flink's [checkpointing mechanism]({{ site.baseurl 
}}/internals/stream_checkpointing.html). You can use Savepoints to 
stop-and-resume, fork,
-or update your Flink jobs. Savepoints consist of two parts: a directory with 
(typically large) binary files on stable storage (e.g. HDFS, S3, ...) and a 
(relatively small) meta data file. The files on stable storage represent the 
net data of the job's execution state
-image. The meta data file of a Savepoint contains (primarily) pointers to all 
files on stable storage that are part of the Savepoint, in form of absolute 
paths.
+Savepoint 是依据 Flink [checkpointing 机制]({{ site.baseurl 
}}/internals/stream_checkpointing.html)所创建的流作业执行状态的一致镜像。 你可以使用 Savepoint 进行 
Flink 作业的停止与重启、fork或者更新。 Savepoint 由两部分组成:稳定存储(列入 HDFS,S3,...) 
上包含二进制文件的目录(通常很大),和元数据文件(相对较小)。 稳定存储上的文件表示作业执行状态的数据镜像。 Savepoint 
的元数据文件以(绝对路径)的形式包含(主要)指向作为 Savepoint 一部分的稳定存储上的所有文件的指针。
 
 <div class="alert alert-warning">
-<strong>Attention:</strong> In order to allow upgrades between programs and 
Flink versions, it is important to check out the following section about <a 
href="#assigning-operator-ids">assigning IDs to your operators</a>.
+<strong>注意:</strong> 为了允许程序和 Flink 版本之间的升级,请务必查看以下有关<a 
href="#assigning-operator-ids">分配算子 ID </a>的部分 。
 </div>
+从概念上讲, Flink 的 Savepoint 与 Checkpoint 的不同之处类似于传统数据库中的备份与恢复日志之间的差异。 Checkpoint 
的主要目的是为意外失败的作为提供恢复机制。 Checkpoint 的生命周期由 Flink 管理,即 Flink 创建,管理和删除 Checkpoint - 
无需用户交互。 作为一种恢复和定期触发的方法,Checkpoint 实现有两个设计目标:i)轻量级创建和 ii)尽可能快地恢复。 
可能会利用某些特定的属性来达到这个,例如, 工作代码在执行尝试之间不会改变。 在用户终止作业后,通常会删除 Checkpoint(除非明确配置为保留的 
Checkpoint)。
 
-Conceptually, Flink's Savepoints are different from Checkpoints in a similar 
way that backups are different from recovery logs in traditional database 
systems. The primary purpose of Checkpoints is to provide a recovery mechanism 
in case of
-unexpected job failures. A Checkpoint's lifecycle is managed by Flink, i.e. a 
Checkpoint is created, owned, and released by Flink - without user interaction. 
As a method of recovery and being periodically triggered, two main
-design goals for the Checkpoint implementation are i) being as lightweight to 
create and ii) being as fast to restore from as possible. Optimizations towards 
those goals can exploit certain properties, e.g. that the job code
-doesn't change between the execution attempts. Checkpoints are usually dropped 
after the job was terminated by the user (except if explicitly configured as 
retained Checkpoints).
+ 与此相反、Savepoint 由用户创建,拥有和删除。 他们的用例是计划的,手动备份和恢复。 例如,升级 Flink 
版本,调整用户逻辑,改变并行度,以及进行红蓝部署等。 当然,Savepoint 必须在终止工作后继续存在。 从概念上讲,Savepoint 
的生成,恢复成本可能更高一些,Savepoint 更多地关注可移植性和对前面提到的作业更改的支持。
 
-In contrast to all this, Savepoints are created, owned, and deleted by the 
user. Their use-case is for planned, manual backup and resume. For example, 
this could be an update of your Flink version, changing your job graph,
-changing parallelism, forking a second job like for a red/blue deployment, and 
so on. Of course, Savepoints must survive job termination. Conceptually, 
Savepoints can be a bit more expensive to produce and restore and focus
-more on portability and support for the previously mentioned changes to the 
job.
+除去这些概念上的差异,Checkpoint 和 Savepoint 
的当前实现基本上使用相同的代码并生成相同的格式。然而,目前有一个例外,我们可能会在未来引入更多的差异。例外情况是使用 RocksDB 状态后端的增量 
Checkpoint。他们使用了一些 RocksDB 内部格式,而不是 Flink 的本机 Savepoint 格式。这使他们成为了与 Savepoint 
相比,更轻量级的 Checkpoint 机制的第一个实例。
 
-Those conceptual differences aside, the current implementations of Checkpoints 
and Savepoints are basically using the same code and produce the same format. 
However, there is currently one exception from this, and we might
-introduce more differences in the future. The exception are incremental 
checkpoints with the RocksDB state backend. They are using some RocksDB 
internal format instead of Flink’s native savepoint format. This makes them the
-first instance of a more lightweight checkpointing mechanism, compared to 
Savepoints.
+## 分配算子ID
 
-## Assigning Operator IDs
-
-It is **highly recommended** that you adjust your programs as described in 
this section in order to be able to upgrade your programs in the future. The 
main required change is to manually specify operator IDs via the 
**`uid(String)`** method. These IDs are used to scope the state of each 
operator.
+**强烈建议**你按照本节所述调整你的程序,以便将来能够升级你的程序。主要需要的更改是通过**`uid(String)`**方法手动指定算子 ID 。这些 
ID 用于限定每个操作符的状态。
 
 Review comment:
   I think this sentence can be improved `主要需要的更改是通过**`uid(String)`**方法手动指定算子 
ID`

----------------------------------------------------------------
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:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to