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 2020/08/05 05:18:35 UTC
[GitHub] [flink] klion26 commented on a change in pull request #9008: [FLINK-12942][docs-zh] Translate Elasticsearch Connector page into Ch…
klion26 commented on a change in pull request #9008:
URL: https://github.com/apache/flink/pull/9008#discussion_r465473496
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -58,23 +56,19 @@ of the Elasticsearch installation:
</tbody>
</table>
-Note that the streaming connectors are currently not part of the binary
-distribution. See [here]({{site.baseurl}}/dev/project-configuration.html) for information
-about how to package the program with the libraries for cluster execution.
+请注意，当前 Flink 二进制安装文件不包括 Elasticsearch 流连接器。有关信息，请参见[此处]({{site.baseurl}}/zh/dev/project-configuration.html)
Review comment:
现在社区建议使用 `{%link dev/project-configuration.zh.md}` 的形式来写链接了，这里需要修改一下。
具体可以参考[这里](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Reminder-Prefer-link-tag-in-documentation-td42362.html)
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -283,43 +277,21 @@ input.addSink(esSinkBuilder.build)
</div>
</div>
-For Elasticsearch versions that still uses the now deprecated `TransportClient` to communicate
-with the Elasticsearch cluster (i.e., versions equal or below 5.x), note how a `Map` of `String`s
-is used to configure the `ElasticsearchSink`. This config map will be directly
-forwarded when creating the internally used `TransportClient`.
-The configuration keys are documented in the Elasticsearch documentation
-[here](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html).
-Especially important is the `cluster.name` parameter that must correspond to
-the name of your cluster.
+对于 Elasticsearch（即版本等于或低于5.x）的集群仍使用现已弃用的 `TransportClient` 进行通信，请注意 `ElasticsearchSink` 使用一个由 `String` 构成的 `Map` 来进行参数配置 。这个配置 map 将直接在内部创建使用`TransportClient` 时转发。配置关键参数在 Elasticsearch 文档中[此处](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)可以查看。特别重要的是 `cluster.name` 参数必须对应你集群的名称。
-For Elasticsearch 6.x and above, internally, the `RestHighLevelClient` is used for cluster communication.
-By default, the connector uses the default configurations for the REST client. To have custom
-configuration for the REST client, users can provide a `RestClientFactory` implementation when
-setting up the `ElasticsearchClient.Builder` that builds the sink.
+对于 Elasticsearch 6.x及更高版本，在内部，使用 `RestHighLevelClient` 进行集群通信。默认情况下，连接器使用 REST 客户端的默认配置。要想自定义 REST 客户端的配置，用户可以在提供 `RestClientFactory` 实现时设置构建 sink 的 `ElasticsearchClient.Builder` 。
-Also note that the example only demonstrates performing a single index
-request for each incoming element. Generally, the `ElasticsearchSinkFunction`
-can be used to perform multiple requests of different types (ex.,
-`DeleteRequest`, `UpdateRequest`, etc.).
+另外请注意，该示例仅展示了执行单个索引请求的每个传入元素。通常，`ElasticsearchSinkFunction` 可用于执行不同类型的多个请求（例如，`DeleteRequest` ，`UpdateRequest` 等）。
-Internally, each parallel instance of the Flink Elasticsearch Sink uses
-a `BulkProcessor` to send action requests to the cluster.
-This will buffer elements before sending them in bulk to the cluster. The `BulkProcessor`
-executes bulk requests one at a time, i.e. there will be no two concurrent
-flushes of the buffered actions in progress.
+在内部，Flink Elasticsearch Sink 的每个并行实例都使用一个 `BulkProcessor` ，用于向集群发送操作请求。这将在批量发送到集群之前缓冲元素。 `BulkProcessor` 一次执行一个批量请求，即不会有两个并发刷新正在进行的缓冲操作。
-### Elasticsearch Sinks and Fault Tolerance
+### Elasticsearch Sink 与容错处理
-With Flink’s checkpointing enabled, the Flink Elasticsearch Sink guarantees
-at-least-once delivery of action requests to Elasticsearch clusters. It does
-so by waiting for all pending action requests in the `BulkProcessor` at the
-time of checkpoints. This effectively assures that all requests before the
-checkpoint was triggered have been successfully acknowledged by Elasticsearch, before
-proceeding to process more records sent to the sink.
+在启用 Flink 的 Checkpoint 后，Flink Elasticsearch Sink 可以保证至少一次向 Elasticsearch 集群传递操作请求。确实如此所以通过等待 `BulkProcessor` 中的所有待处理操作请求 checkpoints 的时间。这有效地保证了之前的所有请求在触发 checkpoint 之前已被 Elasticsearch 成功接收确认继续处理发送到接收器的更多记录。
-More details on checkpoints and fault tolerance are in the [fault tolerance docs]({{site.baseurl}}/zh/learn-flink/fault_tolerance.html).
+更多有关 checkpoint 和容错的详细信息，请参见[容错相关文档]({{site.baseurl}}/zh/learn-flink/fault_tolerance.html)。
Review comment:
这里的链接需要使用 `{%link %}` 的形式来改写一下
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -58,23 +56,19 @@ of the Elasticsearch installation:
</tbody>
</table>
-Note that the streaming connectors are currently not part of the binary
-distribution. See [here]({{site.baseurl}}/dev/project-configuration.html) for information
-about how to package the program with the libraries for cluster execution.
+请注意，当前 Flink 二进制安装文件不包括 Elasticsearch 流连接器。有关信息，请参见[此处]({{site.baseurl}}/zh/dev/project-configuration.html)
+关于如何将程序与库打包以供集群执行。
-## Installing Elasticsearch
+## 安装 Elasticsearch
Review comment:
对于翻译的标题需要在之前添加一个 `<a>` 标签[1]，这个这样其他引用该标题链接的地方可以不修改
这里可以参考英文版 url 生成的链接来添加，比如这里使用 `<a name="installing-elasticsearch"></a>
[1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Translation+Specifications
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -336,22 +308,14 @@ env.enableCheckpointing(5000) // checkpoint every 5000 msecs
</div>
</div>
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>NOTE</b>: Users can disable flushing if they wish to do so, by calling
-<b>disableFlushOnCheckpoint()</b> on the created <b>ElasticsearchSink</b>. Be aware
-that this essentially means the sink will not provide any strong
-delivery guarantees anymore, even with checkpoint for the topology enabled.
-</p>
+<p style =“border-radius：5px; padding：5px”class =“bg-danger”>
+<b>注意</b>：如果用户希望在创建的 <b>ElasticsearchSink</b> 上禁用 flush，可以通过调用 <b>disableFlushOnCheckpoint()</b> 。注意这基本上意味着即使拓扑的 checkpoint 开启了，sink 也无法提供任何强语义的消息投递保证。</p>
-### Handling Failing Elasticsearch Requests
+### 处理失败的 Elasticsearch 请求
Review comment:
这里需要增加 `<a>` 标签
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -283,43 +277,21 @@ input.addSink(esSinkBuilder.build)
</div>
</div>
-For Elasticsearch versions that still uses the now deprecated `TransportClient` to communicate
-with the Elasticsearch cluster (i.e., versions equal or below 5.x), note how a `Map` of `String`s
-is used to configure the `ElasticsearchSink`. This config map will be directly
-forwarded when creating the internally used `TransportClient`.
-The configuration keys are documented in the Elasticsearch documentation
-[here](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html).
-Especially important is the `cluster.name` parameter that must correspond to
-the name of your cluster.
+对于 Elasticsearch（即版本等于或低于5.x）的集群仍使用现已弃用的 `TransportClient` 进行通信，请注意 `ElasticsearchSink` 使用一个由 `String` 构成的 `Map` 来进行参数配置 。这个配置 map 将直接在内部创建使用`TransportClient` 时转发。配置关键参数在 Elasticsearch 文档中[此处](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)可以查看。特别重要的是 `cluster.name` 参数必须对应你集群的名称。
-For Elasticsearch 6.x and above, internally, the `RestHighLevelClient` is used for cluster communication.
-By default, the connector uses the default configurations for the REST client. To have custom
-configuration for the REST client, users can provide a `RestClientFactory` implementation when
-setting up the `ElasticsearchClient.Builder` that builds the sink.
+对于 Elasticsearch 6.x及更高版本，在内部，使用 `RestHighLevelClient` 进行集群通信。默认情况下，连接器使用 REST 客户端的默认配置。要想自定义 REST 客户端的配置，用户可以在提供 `RestClientFactory` 实现时设置构建 sink 的 `ElasticsearchClient.Builder` 。
Review comment:
```suggestion
对于 Elasticsearch 6.x 及更高版本，在内部，使用 `RestHighLevelClient` 进行集群通信。默认情况下，连接器使用 REST 客户端的默认配置。要想自定义 REST 客户端的配置，用户可以在提供 `RestClientFactory` 实现时设置构建 sink 的 `ElasticsearchClient.Builder` 。
```
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -412,61 +376,36 @@ input.addSink(new ElasticsearchSink(
</div>
</div>
-The above example will let the sink re-add requests that failed due to
-queue capacity saturation and drop requests with malformed documents, without
-failing the sink. For all other failures, the sink will fail. If a `ActionRequestFailureHandler`
-is not provided to the constructor, the sink will fail for any kind of error.
-
-Note that `onFailure` is called for failures that still occur only after the
-`BulkProcessor` internally finishes all backoff retry attempts.
-By default, the `BulkProcessor` retries to a maximum of 8 attempts with
-an exponential backoff. For more information on the behaviour of the
-internal `BulkProcessor` and how to configure it, please see the following section.
-
-By default, if a failure handler is not provided, the sink uses a
-`NoOpFailureHandler` that simply fails for all kinds of exceptions. The
-connector also provides a `RetryRejectedExecutionFailureHandler` implementation
-that always re-add requests that have failed due to queue capacity saturation.
-
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>IMPORTANT</b>: Re-adding requests back to the internal <b>BulkProcessor</b>
-on failures will lead to longer checkpoints, as the sink will also
-need to wait for the re-added requests to be flushed when checkpointing.
-For example, when using <b>RetryRejectedExecutionFailureHandler</b>, checkpoints
-will need to wait until Elasticsearch node queues have enough capacity for
-all the pending requests. This also means that if re-added requests never
-succeed, the checkpoint will never finish.
-</p>
-
-### Configuring the Internal Bulk Processor
-
-The internal `BulkProcessor` can be further configured for its behaviour
-on how buffered action requests are flushed, by setting the following values in
-the provided `Map<String, String>`:
-
- * **bulk.flush.max.actions**: Maximum amount of actions to buffer before flushing.
- * **bulk.flush.max.size.mb**: Maximum size of data (in megabytes) to buffer before flushing.
- * **bulk.flush.interval.ms**: Interval at which to flush regardless of the amount or size of buffered actions.
-
-For versions 2.x and above, configuring how temporary request errors are
-retried is also supported:
-
- * **bulk.flush.backoff.enable**: Whether or not to perform retries with backoff delay for a flush
- if one or more of its actions failed due to a temporary `EsRejectedExecutionException`.
- * **bulk.flush.backoff.type**: The type of backoff delay, either `CONSTANT` or `EXPONENTIAL`
- * **bulk.flush.backoff.delay**: The amount of delay for backoff. For constant backoff, this
- is simply the delay between each retry. For exponential backoff, this is the initial base delay.
- * **bulk.flush.backoff.retries**: The amount of backoff retries to attempt.
-
-More information about Elasticsearch can be found [here](https://elastic.co).
-
-## Packaging the Elasticsearch Connector into an Uber-Jar
-
-For the execution of your Flink program, it is recommended to build a
-so-called uber-jar (executable jar) containing all your dependencies
-(see [here]({{site.baseurl}}/dev/project-configuration.html) for further information).
-
-Alternatively, you can put the connector's jar file into Flink's `lib/` folder to make it available
-system-wide, i.e. for all job being run.
+上面的示例将让 sink 重新添加由于失败而导致的请求队列容量饱和和丢弃请求与格式错误的文档，没有失败了。对于所有其他故障， sink 将失败。如果是 `ActionRequestFailureHandler` 没有提供给构造函数，接收器将因任何类型的错误而失败。
+
+请注意，`onFailure` 被调用用于仅在之后仍然发生的故障 `BulkProcessor` 内部完成所有退避重试尝试。默认情况下，`BulkProcessor` 重试最多8次尝试指数退避。有关行为的更多信息内部 `BulkProcessor` 以及如何配置它，请参阅以下部分。
+
+默认情况下，如果未提供失败处理程序，则接收器使用a `NoOpFailureHandler` 只是因各种异常而失败。该连接器还提供了 `RetryRejectedExecutionFailureHandler` 实现总是重新添加由于队列容量饱和而失败的请求。
+
+<b>重要</b>：将请求重新添加回内部 <b>BulkProcessor</b> 在失败时会导致 checkpoints 变长，sink 也一样需要等待重新添加的请求在 checkpoint 时被刷新。例如，当使用 <b>RetryRejectedExecutionFailureHandler</b> 时，checkpoints 需要等待直到 Elasticsearch 节点队列有足够的容量处理所有等待的请求。这也意味着如果从不重新添加请求成功，checkpoint 将永远不会结束。</p>
+
+
+### Bulk Processor 内部配置
+
+`BulkProcessor` 内部 可以进一步配置其行为，通过在提供的 `Map <String，String>` 中设置以下值来控制刷新缓冲操作请求的行为：
+
+ * **bulk.flush.max.actions**: 在刷新之前要缓冲的最大操作量。
+ * **bulk.flush.max.size.mb**: 在刷新之前要缓冲的最大数据大小(以兆字节为单位)。
+ * **bulk.flush.interval.ms**: 不论缓冲操作的数量或大小，都要刷新的时间间隔。
+
+对于 2.x 及更高版本，还支持配置临时请求错误的方式：
+
+ * **bulk.flush.backoff.enable**: 是否启用带回退延迟的刷新重试。如果一个或多个操作由于临时的 `EsRejectedExecutionException` 而失败。
+ * **bulk.flush.backoff.type**: 回退延迟的类型，`CONSTANT` 或 `EXPONENTIAL`。
+ * **bulk.flush.backoff.delay**: 回退的延迟量。对于常数回退，这个只是每次重试之间的延迟。对于指数回退，这是初始延迟。
+ * **bulk.flush.backoff.retries**: 重试回退的次数。
+
+更多有关 Elasticsearch 的信息可以在[这里](https://elastic.co)找到。
+
+## 将 Elasticsearch Connector 打包到 Uber-Jar 中
+
+为了执行 Flink 程序，建议构建一个包含所有依赖项的所谓 uber-jar（可执行 jar ）有关详细信息，请参阅[此处]({{site.baseurl}}/zh/dev/project-configuration.html)。
Review comment:
这个链接需要修改成 `{%link %}` 的形式
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -412,61 +376,36 @@ input.addSink(new ElasticsearchSink(
</div>
</div>
-The above example will let the sink re-add requests that failed due to
-queue capacity saturation and drop requests with malformed documents, without
-failing the sink. For all other failures, the sink will fail. If a `ActionRequestFailureHandler`
-is not provided to the constructor, the sink will fail for any kind of error.
-
-Note that `onFailure` is called for failures that still occur only after the
-`BulkProcessor` internally finishes all backoff retry attempts.
-By default, the `BulkProcessor` retries to a maximum of 8 attempts with
-an exponential backoff. For more information on the behaviour of the
-internal `BulkProcessor` and how to configure it, please see the following section.
-
-By default, if a failure handler is not provided, the sink uses a
-`NoOpFailureHandler` that simply fails for all kinds of exceptions. The
-connector also provides a `RetryRejectedExecutionFailureHandler` implementation
-that always re-add requests that have failed due to queue capacity saturation.
-
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>IMPORTANT</b>: Re-adding requests back to the internal <b>BulkProcessor</b>
-on failures will lead to longer checkpoints, as the sink will also
-need to wait for the re-added requests to be flushed when checkpointing.
-For example, when using <b>RetryRejectedExecutionFailureHandler</b>, checkpoints
-will need to wait until Elasticsearch node queues have enough capacity for
-all the pending requests. This also means that if re-added requests never
-succeed, the checkpoint will never finish.
-</p>
-
-### Configuring the Internal Bulk Processor
-
-The internal `BulkProcessor` can be further configured for its behaviour
-on how buffered action requests are flushed, by setting the following values in
-the provided `Map<String, String>`:
-
- * **bulk.flush.max.actions**: Maximum amount of actions to buffer before flushing.
- * **bulk.flush.max.size.mb**: Maximum size of data (in megabytes) to buffer before flushing.
- * **bulk.flush.interval.ms**: Interval at which to flush regardless of the amount or size of buffered actions.
-
-For versions 2.x and above, configuring how temporary request errors are
-retried is also supported:
-
- * **bulk.flush.backoff.enable**: Whether or not to perform retries with backoff delay for a flush
- if one or more of its actions failed due to a temporary `EsRejectedExecutionException`.
- * **bulk.flush.backoff.type**: The type of backoff delay, either `CONSTANT` or `EXPONENTIAL`
- * **bulk.flush.backoff.delay**: The amount of delay for backoff. For constant backoff, this
- is simply the delay between each retry. For exponential backoff, this is the initial base delay.
- * **bulk.flush.backoff.retries**: The amount of backoff retries to attempt.
-
-More information about Elasticsearch can be found [here](https://elastic.co).
-
-## Packaging the Elasticsearch Connector into an Uber-Jar
-
-For the execution of your Flink program, it is recommended to build a
-so-called uber-jar (executable jar) containing all your dependencies
-(see [here]({{site.baseurl}}/dev/project-configuration.html) for further information).
-
-Alternatively, you can put the connector's jar file into Flink's `lib/` folder to make it available
-system-wide, i.e. for all job being run.
+上面的示例将让 sink 重新添加由于失败而导致的请求队列容量饱和和丢弃请求与格式错误的文档，没有失败了。对于所有其他故障， sink 将失败。如果是 `ActionRequestFailureHandler` 没有提供给构造函数，接收器将因任何类型的错误而失败。
+
+请注意，`onFailure` 被调用用于仅在之后仍然发生的故障 `BulkProcessor` 内部完成所有退避重试尝试。默认情况下，`BulkProcessor` 重试最多8次尝试指数退避。有关行为的更多信息内部 `BulkProcessor` 以及如何配置它，请参阅以下部分。
+
+默认情况下，如果未提供失败处理程序，则接收器使用a `NoOpFailureHandler` 只是因各种异常而失败。该连接器还提供了 `RetryRejectedExecutionFailureHandler` 实现总是重新添加由于队列容量饱和而失败的请求。
+
+<b>重要</b>：将请求重新添加回内部 <b>BulkProcessor</b> 在失败时会导致 checkpoints 变长，sink 也一样需要等待重新添加的请求在 checkpoint 时被刷新。例如，当使用 <b>RetryRejectedExecutionFailureHandler</b> 时，checkpoints 需要等待直到 Elasticsearch 节点队列有足够的容量处理所有等待的请求。这也意味着如果从不重新添加请求成功，checkpoint 将永远不会结束。</p>
+
+
+### Bulk Processor 内部配置
+
+`BulkProcessor` 内部 可以进一步配置其行为，通过在提供的 `Map <String，String>` 中设置以下值来控制刷新缓冲操作请求的行为：
+
+ * **bulk.flush.max.actions**: 在刷新之前要缓冲的最大操作量。
+ * **bulk.flush.max.size.mb**: 在刷新之前要缓冲的最大数据大小(以兆字节为单位)。
+ * **bulk.flush.interval.ms**: 不论缓冲操作的数量或大小，都要刷新的时间间隔。
+
+对于 2.x 及更高版本，还支持配置临时请求错误的方式：
+
+ * **bulk.flush.backoff.enable**: 是否启用带回退延迟的刷新重试。如果一个或多个操作由于临时的 `EsRejectedExecutionException` 而失败。
+ * **bulk.flush.backoff.type**: 回退延迟的类型，`CONSTANT` 或 `EXPONENTIAL`。
+ * **bulk.flush.backoff.delay**: 回退的延迟量。对于常数回退，这个只是每次重试之间的延迟。对于指数回退，这是初始延迟。
+ * **bulk.flush.backoff.retries**: 重试回退的次数。
+
+更多有关 Elasticsearch 的信息可以在[这里](https://elastic.co)找到。
+
+## 将 Elasticsearch Connector 打包到 Uber-Jar 中
+
+为了执行 Flink 程序，建议构建一个包含所有依赖项的所谓 uber-jar（可执行 jar ）有关详细信息，请参阅[此处]({{site.baseurl}}/zh/dev/project-configuration.html)。
+
+或者，您可以将连接器的 jar 文件放入 Flink 的`lib /`文件夹中以使其可用于所有系统，即所有正在运行的 job 。
Review comment:
```suggestion
或者，您可以将连接器的 jar 文件放入 Flink 的 `lib/` 文件夹中以使其可用于所有系统，即所有正在运行的 job 。
```
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -412,61 +376,36 @@ input.addSink(new ElasticsearchSink(
</div>
</div>
-The above example will let the sink re-add requests that failed due to
-queue capacity saturation and drop requests with malformed documents, without
-failing the sink. For all other failures, the sink will fail. If a `ActionRequestFailureHandler`
-is not provided to the constructor, the sink will fail for any kind of error.
-
-Note that `onFailure` is called for failures that still occur only after the
-`BulkProcessor` internally finishes all backoff retry attempts.
-By default, the `BulkProcessor` retries to a maximum of 8 attempts with
-an exponential backoff. For more information on the behaviour of the
-internal `BulkProcessor` and how to configure it, please see the following section.
-
-By default, if a failure handler is not provided, the sink uses a
-`NoOpFailureHandler` that simply fails for all kinds of exceptions. The
-connector also provides a `RetryRejectedExecutionFailureHandler` implementation
-that always re-add requests that have failed due to queue capacity saturation.
-
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>IMPORTANT</b>: Re-adding requests back to the internal <b>BulkProcessor</b>
-on failures will lead to longer checkpoints, as the sink will also
-need to wait for the re-added requests to be flushed when checkpointing.
-For example, when using <b>RetryRejectedExecutionFailureHandler</b>, checkpoints
-will need to wait until Elasticsearch node queues have enough capacity for
-all the pending requests. This also means that if re-added requests never
-succeed, the checkpoint will never finish.
-</p>
-
-### Configuring the Internal Bulk Processor
-
-The internal `BulkProcessor` can be further configured for its behaviour
-on how buffered action requests are flushed, by setting the following values in
-the provided `Map<String, String>`:
-
- * **bulk.flush.max.actions**: Maximum amount of actions to buffer before flushing.
- * **bulk.flush.max.size.mb**: Maximum size of data (in megabytes) to buffer before flushing.
- * **bulk.flush.interval.ms**: Interval at which to flush regardless of the amount or size of buffered actions.
-
-For versions 2.x and above, configuring how temporary request errors are
-retried is also supported:
-
- * **bulk.flush.backoff.enable**: Whether or not to perform retries with backoff delay for a flush
- if one or more of its actions failed due to a temporary `EsRejectedExecutionException`.
- * **bulk.flush.backoff.type**: The type of backoff delay, either `CONSTANT` or `EXPONENTIAL`
- * **bulk.flush.backoff.delay**: The amount of delay for backoff. For constant backoff, this
- is simply the delay between each retry. For exponential backoff, this is the initial base delay.
- * **bulk.flush.backoff.retries**: The amount of backoff retries to attempt.
-
-More information about Elasticsearch can be found [here](https://elastic.co).
-
-## Packaging the Elasticsearch Connector into an Uber-Jar
-
-For the execution of your Flink program, it is recommended to build a
-so-called uber-jar (executable jar) containing all your dependencies
-(see [here]({{site.baseurl}}/dev/project-configuration.html) for further information).
-
-Alternatively, you can put the connector's jar file into Flink's `lib/` folder to make it available
-system-wide, i.e. for all job being run.
+上面的示例将让 sink 重新添加由于失败而导致的请求队列容量饱和和丢弃请求与格式错误的文档，没有失败了。对于所有其他故障， sink 将失败。如果是 `ActionRequestFailureHandler` 没有提供给构造函数，接收器将因任何类型的错误而失败。
+
+请注意，`onFailure` 被调用用于仅在之后仍然发生的故障 `BulkProcessor` 内部完成所有退避重试尝试。默认情况下，`BulkProcessor` 重试最多8次尝试指数退避。有关行为的更多信息内部 `BulkProcessor` 以及如何配置它，请参阅以下部分。
Review comment:
这里改成 "`onFailure` 仅在 `BulkProcessor` 内部完成所有退避重试尝试后仍有问题的情况下被调用“ 会好一些吗？
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -58,23 +56,19 @@ of the Elasticsearch installation:
</tbody>
</table>
-Note that the streaming connectors are currently not part of the binary
-distribution. See [here]({{site.baseurl}}/dev/project-configuration.html) for information
-about how to package the program with the libraries for cluster execution.
+请注意，当前 Flink 二进制安装文件不包括 Elasticsearch 流连接器。有关信息，请参见[此处]({{site.baseurl}}/zh/dev/project-configuration.html)
+关于如何将程序与库打包以供集群执行。
-## Installing Elasticsearch
+## 安装 Elasticsearch
-Instructions for setting up an Elasticsearch cluster can be found
-[here](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html).
-Make sure to set and remember a cluster name. This must be set when
-creating an `ElasticsearchSink` for requesting document actions against your cluster.
+[这里](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html)可以找到有关设置Elasticsearch集群的说明。确保设置并记住集群名称。集群名称将在创建一个`ElasticsearchSink`时使用，用于请求对你安装的集群的文档操作。
Review comment:
```suggestion
[这里](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html)可以找到有关设置 Elasticsearch集群的说明。确保设置并记住集群名称。集群名称将在创建一个 `ElasticsearchSink` 时使用，用于请求对你安装集群的文档操作。
```
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -116,7 +110,7 @@ input.addSink(new ElasticsearchSink<>(config, transportAddresses, new Elasticsea
.type("my-type")
.source(json);
}
-
+
Review comment:
这个修改格式更好看了 👍
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -412,61 +376,36 @@ input.addSink(new ElasticsearchSink(
</div>
</div>
-The above example will let the sink re-add requests that failed due to
-queue capacity saturation and drop requests with malformed documents, without
-failing the sink. For all other failures, the sink will fail. If a `ActionRequestFailureHandler`
-is not provided to the constructor, the sink will fail for any kind of error.
-
-Note that `onFailure` is called for failures that still occur only after the
-`BulkProcessor` internally finishes all backoff retry attempts.
-By default, the `BulkProcessor` retries to a maximum of 8 attempts with
-an exponential backoff. For more information on the behaviour of the
-internal `BulkProcessor` and how to configure it, please see the following section.
-
-By default, if a failure handler is not provided, the sink uses a
-`NoOpFailureHandler` that simply fails for all kinds of exceptions. The
-connector also provides a `RetryRejectedExecutionFailureHandler` implementation
-that always re-add requests that have failed due to queue capacity saturation.
-
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>IMPORTANT</b>: Re-adding requests back to the internal <b>BulkProcessor</b>
-on failures will lead to longer checkpoints, as the sink will also
-need to wait for the re-added requests to be flushed when checkpointing.
-For example, when using <b>RetryRejectedExecutionFailureHandler</b>, checkpoints
-will need to wait until Elasticsearch node queues have enough capacity for
-all the pending requests. This also means that if re-added requests never
-succeed, the checkpoint will never finish.
-</p>
-
-### Configuring the Internal Bulk Processor
-
-The internal `BulkProcessor` can be further configured for its behaviour
-on how buffered action requests are flushed, by setting the following values in
-the provided `Map<String, String>`:
-
- * **bulk.flush.max.actions**: Maximum amount of actions to buffer before flushing.
- * **bulk.flush.max.size.mb**: Maximum size of data (in megabytes) to buffer before flushing.
- * **bulk.flush.interval.ms**: Interval at which to flush regardless of the amount or size of buffered actions.
-
-For versions 2.x and above, configuring how temporary request errors are
-retried is also supported:
-
- * **bulk.flush.backoff.enable**: Whether or not to perform retries with backoff delay for a flush
- if one or more of its actions failed due to a temporary `EsRejectedExecutionException`.
- * **bulk.flush.backoff.type**: The type of backoff delay, either `CONSTANT` or `EXPONENTIAL`
- * **bulk.flush.backoff.delay**: The amount of delay for backoff. For constant backoff, this
- is simply the delay between each retry. For exponential backoff, this is the initial base delay.
- * **bulk.flush.backoff.retries**: The amount of backoff retries to attempt.
-
-More information about Elasticsearch can be found [here](https://elastic.co).
-
-## Packaging the Elasticsearch Connector into an Uber-Jar
-
-For the execution of your Flink program, it is recommended to build a
-so-called uber-jar (executable jar) containing all your dependencies
-(see [here]({{site.baseurl}}/dev/project-configuration.html) for further information).
-
-Alternatively, you can put the connector's jar file into Flink's `lib/` folder to make it available
-system-wide, i.e. for all job being run.
+上面的示例将让 sink 重新添加由于失败而导致的请求队列容量饱和和丢弃请求与格式错误的文档，没有失败了。对于所有其他故障， sink 将失败。如果是 `ActionRequestFailureHandler` 没有提供给构造函数，接收器将因任何类型的错误而失败。
+
+请注意，`onFailure` 被调用用于仅在之后仍然发生的故障 `BulkProcessor` 内部完成所有退避重试尝试。默认情况下，`BulkProcessor` 重试最多8次尝试指数退避。有关行为的更多信息内部 `BulkProcessor` 以及如何配置它，请参阅以下部分。
+
+默认情况下，如果未提供失败处理程序，则接收器使用a `NoOpFailureHandler` 只是因各种异常而失败。该连接器还提供了 `RetryRejectedExecutionFailureHandler` 实现总是重新添加由于队列容量饱和而失败的请求。
+
+<b>重要</b>：将请求重新添加回内部 <b>BulkProcessor</b> 在失败时会导致 checkpoints 变长，sink 也一样需要等待重新添加的请求在 checkpoint 时被刷新。例如，当使用 <b>RetryRejectedExecutionFailureHandler</b> 时，checkpoints 需要等待直到 Elasticsearch 节点队列有足够的容量处理所有等待的请求。这也意味着如果从不重新添加请求成功，checkpoint 将永远不会结束。</p>
+
+
+### Bulk Processor 内部配置
Review comment:
这里需要增加 `<a>` 标签
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -336,22 +308,14 @@ env.enableCheckpointing(5000) // checkpoint every 5000 msecs
</div>
</div>
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>NOTE</b>: Users can disable flushing if they wish to do so, by calling
-<b>disableFlushOnCheckpoint()</b> on the created <b>ElasticsearchSink</b>. Be aware
-that this essentially means the sink will not provide any strong
-delivery guarantees anymore, even with checkpoint for the topology enabled.
-</p>
+<p style =“border-radius：5px; padding：5px”class =“bg-danger”>
+<b>注意</b>：如果用户希望在创建的 <b>ElasticsearchSink</b> 上禁用 flush，可以通过调用 <b>disableFlushOnCheckpoint()</b> 。注意这基本上意味着即使拓扑的 checkpoint 开启了，sink 也无法提供任何强语义的消息投递保证。</p>
-### Handling Failing Elasticsearch Requests
+### 处理失败的 Elasticsearch 请求
-Elasticsearch action requests may fail due to a variety of reasons, including
-temporarily saturated node queue capacity or malformed documents to be indexed.
-The Flink Elasticsearch Sink allows the user to specify how request
-failures are handled, by simply implementing an `ActionRequestFailureHandler` and
-providing it to the constructor.
+由于各种原因，发给 Elasticsearch 的操作请求可能会失败，如暂时饱和的节点队列容量或索引异常文档。Flink Elasticsearch Sink 允许用户指定如何处理请求失败，通过简单地实现`ActionRequestFailureHandler`接口并传给 ElasticsearchSink 的构造函数即可。
Review comment:
```suggestion
由于各种原因，发给 Elasticsearch 的操作请求可能会失败，如暂时饱和的节点队列容量或索引异常文档。Flink Elasticsearch Sink 允许用户指定如何处理请求失败，通过简单地实现 `ActionRequestFailureHandler` 接口并传给 ElasticsearchSink 的构造函数即可。
```
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -412,61 +376,36 @@ input.addSink(new ElasticsearchSink(
</div>
</div>
-The above example will let the sink re-add requests that failed due to
-queue capacity saturation and drop requests with malformed documents, without
-failing the sink. For all other failures, the sink will fail. If a `ActionRequestFailureHandler`
-is not provided to the constructor, the sink will fail for any kind of error.
-
-Note that `onFailure` is called for failures that still occur only after the
-`BulkProcessor` internally finishes all backoff retry attempts.
-By default, the `BulkProcessor` retries to a maximum of 8 attempts with
-an exponential backoff. For more information on the behaviour of the
-internal `BulkProcessor` and how to configure it, please see the following section.
-
-By default, if a failure handler is not provided, the sink uses a
-`NoOpFailureHandler` that simply fails for all kinds of exceptions. The
-connector also provides a `RetryRejectedExecutionFailureHandler` implementation
-that always re-add requests that have failed due to queue capacity saturation.
-
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>IMPORTANT</b>: Re-adding requests back to the internal <b>BulkProcessor</b>
-on failures will lead to longer checkpoints, as the sink will also
-need to wait for the re-added requests to be flushed when checkpointing.
-For example, when using <b>RetryRejectedExecutionFailureHandler</b>, checkpoints
-will need to wait until Elasticsearch node queues have enough capacity for
-all the pending requests. This also means that if re-added requests never
-succeed, the checkpoint will never finish.
-</p>
-
-### Configuring the Internal Bulk Processor
-
-The internal `BulkProcessor` can be further configured for its behaviour
-on how buffered action requests are flushed, by setting the following values in
-the provided `Map<String, String>`:
-
- * **bulk.flush.max.actions**: Maximum amount of actions to buffer before flushing.
- * **bulk.flush.max.size.mb**: Maximum size of data (in megabytes) to buffer before flushing.
- * **bulk.flush.interval.ms**: Interval at which to flush regardless of the amount or size of buffered actions.
-
-For versions 2.x and above, configuring how temporary request errors are
-retried is also supported:
-
- * **bulk.flush.backoff.enable**: Whether or not to perform retries with backoff delay for a flush
- if one or more of its actions failed due to a temporary `EsRejectedExecutionException`.
- * **bulk.flush.backoff.type**: The type of backoff delay, either `CONSTANT` or `EXPONENTIAL`
- * **bulk.flush.backoff.delay**: The amount of delay for backoff. For constant backoff, this
- is simply the delay between each retry. For exponential backoff, this is the initial base delay.
- * **bulk.flush.backoff.retries**: The amount of backoff retries to attempt.
-
-More information about Elasticsearch can be found [here](https://elastic.co).
-
-## Packaging the Elasticsearch Connector into an Uber-Jar
-
-For the execution of your Flink program, it is recommended to build a
-so-called uber-jar (executable jar) containing all your dependencies
-(see [here]({{site.baseurl}}/dev/project-configuration.html) for further information).
-
-Alternatively, you can put the connector's jar file into Flink's `lib/` folder to make it available
-system-wide, i.e. for all job being run.
+上面的示例将让 sink 重新添加由于失败而导致的请求队列容量饱和和丢弃请求与格式错误的文档，没有失败了。对于所有其他故障， sink 将失败。如果是 `ActionRequestFailureHandler` 没有提供给构造函数，接收器将因任何类型的错误而失败。
+
+请注意，`onFailure` 被调用用于仅在之后仍然发生的故障 `BulkProcessor` 内部完成所有退避重试尝试。默认情况下，`BulkProcessor` 重试最多8次尝试指数退避。有关行为的更多信息内部 `BulkProcessor` 以及如何配置它，请参阅以下部分。
+
+默认情况下，如果未提供失败处理程序，则接收器使用a `NoOpFailureHandler` 只是因各种异常而失败。该连接器还提供了 `RetryRejectedExecutionFailureHandler` 实现总是重新添加由于队列容量饱和而失败的请求。
+
+<b>重要</b>：将请求重新添加回内部 <b>BulkProcessor</b> 在失败时会导致 checkpoints 变长，sink 也一样需要等待重新添加的请求在 checkpoint 时被刷新。例如，当使用 <b>RetryRejectedExecutionFailureHandler</b> 时，checkpoints 需要等待直到 Elasticsearch 节点队列有足够的容量处理所有等待的请求。这也意味着如果从不重新添加请求成功，checkpoint 将永远不会结束。</p>
Review comment:
这里是不是漏掉了 `<p>` 标签
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -116,7 +110,7 @@ input.addSink(new ElasticsearchSink<>(config, transportAddresses, new Elasticsea
.type("my-type")
.source(json);
}
Review comment:
可以的话，建议把注释也翻译一下，这样更容易理解
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -336,22 +308,14 @@ env.enableCheckpointing(5000) // checkpoint every 5000 msecs
</div>
</div>
-<p style="border-radius: 5px; padding: 5px" class="bg-danger">
-<b>NOTE</b>: Users can disable flushing if they wish to do so, by calling
-<b>disableFlushOnCheckpoint()</b> on the created <b>ElasticsearchSink</b>. Be aware
-that this essentially means the sink will not provide any strong
-delivery guarantees anymore, even with checkpoint for the topology enabled.
-</p>
+<p style =“border-radius：5px; padding：5px”class =“bg-danger”>
Review comment:
这个地方的渲染有问题，可能是中文符号导致的。
这个有个小技巧：在修改完成后，本地执行 `./docs/docker/run.sh` 然后执行 `./build_docs.sh -p` 打开 localhost:4000 可以看到渲染后的结果
##########
File path: docs/dev/connectors/elasticsearch.zh.md
##########
@@ -283,43 +277,21 @@ input.addSink(esSinkBuilder.build)
</div>
</div>
-For Elasticsearch versions that still uses the now deprecated `TransportClient` to communicate
-with the Elasticsearch cluster (i.e., versions equal or below 5.x), note how a `Map` of `String`s
-is used to configure the `ElasticsearchSink`. This config map will be directly
-forwarded when creating the internally used `TransportClient`.
-The configuration keys are documented in the Elasticsearch documentation
-[here](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html).
-Especially important is the `cluster.name` parameter that must correspond to
-the name of your cluster.
+对于 Elasticsearch（即版本等于或低于5.x）的集群仍使用现已弃用的 `TransportClient` 进行通信，请注意 `ElasticsearchSink` 使用一个由 `String` 构成的 `Map` 来进行参数配置 。这个配置 map 将直接在内部创建使用`TransportClient` 时转发。配置关键参数在 Elasticsearch 文档中[此处](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)可以查看。特别重要的是 `cluster.name` 参数必须对应你集群的名称。
-For Elasticsearch 6.x and above, internally, the `RestHighLevelClient` is used for cluster communication.
-By default, the connector uses the default configurations for the REST client. To have custom
-configuration for the REST client, users can provide a `RestClientFactory` implementation when
-setting up the `ElasticsearchClient.Builder` that builds the sink.
+对于 Elasticsearch 6.x及更高版本，在内部，使用 `RestHighLevelClient` 进行集群通信。默认情况下，连接器使用 REST 客户端的默认配置。要想自定义 REST 客户端的配置，用户可以在提供 `RestClientFactory` 实现时设置构建 sink 的 `ElasticsearchClient.Builder` 。
-Also note that the example only demonstrates performing a single index
-request for each incoming element. Generally, the `ElasticsearchSinkFunction`
-can be used to perform multiple requests of different types (ex.,
-`DeleteRequest`, `UpdateRequest`, etc.).
+另外请注意，该示例仅展示了执行单个索引请求的每个传入元素。通常，`ElasticsearchSinkFunction` 可用于执行不同类型的多个请求（例如，`DeleteRequest` ，`UpdateRequest` 等）。
-Internally, each parallel instance of the Flink Elasticsearch Sink uses
-a `BulkProcessor` to send action requests to the cluster.
-This will buffer elements before sending them in bulk to the cluster. The `BulkProcessor`
-executes bulk requests one at a time, i.e. there will be no two concurrent
-flushes of the buffered actions in progress.
+在内部，Flink Elasticsearch Sink 的每个并行实例都使用一个 `BulkProcessor` ，用于向集群发送操作请求。这将在批量发送到集群之前缓冲元素。 `BulkProcessor` 一次执行一个批量请求，即不会有两个并发刷新正在进行的缓冲操作。
-### Elasticsearch Sinks and Fault Tolerance
+### Elasticsearch Sink 与容错处理
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:
users@infra.apache.org