You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "qidian99 (via GitHub)" <gi...@apache.org> on 2023/03/31 08:28:02 UTC

[GitHub] [flink] qidian99 opened a new pull request, #22314: Fixed inaccurancy in Chinese doc of Execution Mode

qidian99 opened a new pull request, #22314:
URL: https://github.com/apache/flink/pull/22314

   <!--
   *Thank you very much for contributing to Apache Flink - we are happy that you want to help us improve Flink. To help the community review your contribution in the best possible way, please go through the checklist below, which will get the contribution into a shape in which it can be best reviewed.*
   
   *Please understand that we do not do this to make contributions to Flink a hassle. In order to uphold a high standard of quality for code contributions, while at the same time managing a large number of contributions, we need contributors to prepare the contributions well, and give reviewers enough contextual information for the review. Please also understand that contributions that do not follow this guide will take longer to review and thus typically be picked up with lower priority by the community.*
   
   ## Contribution Checklist
   
     - Make sure that the pull request corresponds to a [JIRA issue](https://issues.apache.org/jira/projects/FLINK/issues). Exceptions are made for typos in JavaDoc or documentation files, which need no JIRA issue.
     
     - Name the pull request in the form "[FLINK-XXXX] [component] Title of the pull request", where *FLINK-XXXX* should be replaced by the actual issue number. Skip *component* if you are unsure about which is the best component.
     Typo fixes that have no associated JIRA issue should be named following this pattern: `[hotfix] [docs] Fix typo in event time introduction` or `[hotfix] [javadocs] Expand JavaDoc for PuncuatedWatermarkGenerator`.
   
     - Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review.
     
     - Make sure that the change passes the automated tests, i.e., `mvn clean verify` passes. You can set up Azure Pipelines CI to do that following [this guide](https://cwiki.apache.org/confluence/display/FLINK/Azure+Pipelines#AzurePipelines-Tutorial:SettingupAzurePipelinesforaforkoftheFlinkrepository).
   
     - Each pull request should address only one issue, not mix up code from multiple issues.
     
     - Each commit in the pull request has a meaningful commit message (including the JIRA id)
   
     - Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below.
   
   
   **(The sections below can be removed for hotfixes of typos)**
   -->
   
   ## What is the purpose of the change
   
   *(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)*
   
   
   ## Brief change log
   
   *(for example:)*
     - *The TaskInfo is stored in the blob store on job creation time as a persistent artifact*
     - *Deployments RPC transmits only the blob storage reference*
     - *TaskManagers retrieve the TaskInfo from the blob cache*
   
   
   ## Verifying this change
   
   Please make sure both new and modified tests in this PR follows the conventions defined in our code quality guide: https://flink.apache.org/contributing/code-style-and-quality-common.html#testing
   
   *(Please pick either of the following options)*
   
   This change is a trivial rework / code cleanup without any test coverage.
   
   *(or)*
   
   This change is already covered by existing tests, such as *(please describe tests)*.
   
   *(or)*
   
   This change added tests and can be verified as follows:
   
   *(example:)*
     - *Added integration tests for end-to-end deployment with large payloads (100MB)*
     - *Extended integration test for recovery after master (JobManager) failure*
     - *Added test that validates that TaskInfo is transferred only once across recoveries*
     - *Manually verified the change by running a 4 node cluster with 2 JobManagers and 4 TaskManagers, a stateful streaming program, and killing one JobManager and two TaskManagers during the execution, verifying that recovery happens correctly.*
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): (yes / no)
     - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: (yes / no)
     - The serializers: (yes / no / don't know)
     - The runtime per-record code paths (performance sensitive): (yes / no / don't know)
     - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
     - The S3 file system connector: (yes / no / don't know)
   
   ## Documentation
   
     - Does this pull request introduce a new feature? (yes / no)
     - If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
   


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

[GitHub] [flink] flinkbot commented on pull request #22314: Fixed inaccurancy in Chinese doc of Execution Mode

Posted by "flinkbot (via GitHub)" <gi...@apache.org>.
flinkbot commented on PR #22314:
URL: https://github.com/apache/flink/pull/22314#issuecomment-1491531606

   <!--
   Meta data
   {
     "version" : 1,
     "metaDataEntries" : [ {
       "hash" : "e227f2951786bdaa66ebde3fcad8e58c74bb15f5",
       "status" : "UNKNOWN",
       "url" : "TBD",
       "triggerID" : "e227f2951786bdaa66ebde3fcad8e58c74bb15f5",
       "triggerType" : "PUSH"
     } ]
   }-->
   ## CI report:
   
   * e227f2951786bdaa66ebde3fcad8e58c74bb15f5 UNKNOWN
   
   <details>
   <summary>Bot commands</summary>
     The @flinkbot bot supports the following commands:
   
    - `@flinkbot run azure` re-run the last Azure build
   </details>


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

[GitHub] [flink] luoyuxia closed pull request #22314: Fixed inaccurancy in Chinese doc of Execution Mode

Posted by "luoyuxia (via GitHub)" <gi...@apache.org>.
luoyuxia closed pull request #22314: Fixed inaccurancy in Chinese doc of Execution Mode
URL: https://github.com/apache/flink/pull/22314


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

[GitHub] [flink] qidian99 commented on pull request #22314: Fixed inaccurancy in Chinese doc of Execution Mode

Posted by "qidian99 (via GitHub)" <gi...@apache.org>.
qidian99 commented on PR #22314:
URL: https://github.com/apache/flink/pull/22314#issuecomment-1493887653

   @luoyuxia Thanks. I have committed the suggested changes, and will open a pull request to master branch shortly.


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

[GitHub] [flink] luoyuxia commented on a diff in pull request #22314: Fixed inaccurancy in Chinese doc of Execution Mode

Posted by "luoyuxia (via GitHub)" <gi...@apache.org>.
luoyuxia commented on code in PR #22314:
URL: https://github.com/apache/flink/pull/22314#discussion_r1155607264


##########
docs/content.zh/docs/dev/datastream/execution_mode.md:
##########
@@ -27,25 +27,25 @@ under the License.
 # 执行模式（流/批）
 DataStream API 支持不同的运行时执行模式，你可以根据你的用例需要和作业特点进行选择。
 
-DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且预计无限期保持在线的无边界作业。
+DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且常驻线上的无边界作业。
 
-此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式更容易让人联想到批处理框架，比如 MapReduce。这种执行模式适用于有一个已知的固定输入，而且不会连续运行的有边界作业。
+此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式类似于MapReduce等批处理框架，适用于已知输入、不常驻的有边界作业。
 
-Apache Flink 对流处理和批处理统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
+Apache Flink 对流处理和批处理的统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
 
-通过启用`批`执行，我们允许 Flink 应用只有在我们知道输入是有边界的时侯才会使用到的额外的优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略，允许实现更高效的任务调度和故障恢复行为的不同 shuffle。下面我们将介绍一些执行行为的细节。
+通过启用`批`执行模式，Flink 可以进行有边界作业特有的额外优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略、不同 shuffle 提高任务调度效率和故障恢复行为。下面我们将介绍一些执行模式的细节。

Review Comment:
   ```suggestion
   通过启用`批`执行模式，Flink 可以对有边界作业进行额外的优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略、不同 shuffle 实现来提高任务调度和故障恢复的效率。下面我们将介绍一些执行模式的细节。
   ```



##########
docs/content.zh/docs/dev/datastream/execution_mode.md:
##########
@@ -27,25 +27,25 @@ under the License.
 # 执行模式（流/批）
 DataStream API 支持不同的运行时执行模式，你可以根据你的用例需要和作业特点进行选择。
 
-DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且预计无限期保持在线的无边界作业。
+DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且常驻线上的无边界作业。
 
-此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式更容易让人联想到批处理框架，比如 MapReduce。这种执行模式适用于有一个已知的固定输入，而且不会连续运行的有边界作业。
+此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式类似于MapReduce等批处理框架，适用于已知输入、不常驻的有边界作业。

Review Comment:
   ```suggestion
   此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式类似于 MapReduce 等批处理框架，适用于已知输入、不会连续运行的的有边界作业。
   ```



##########
docs/content.zh/docs/dev/datastream/execution_mode.md:
##########
@@ -27,25 +27,25 @@ under the License.
 # 执行模式（流/批）
 DataStream API 支持不同的运行时执行模式，你可以根据你的用例需要和作业特点进行选择。
 
-DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且预计无限期保持在线的无边界作业。
+DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且常驻线上的无边界作业。
 
-此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式更容易让人联想到批处理框架，比如 MapReduce。这种执行模式适用于有一个已知的固定输入，而且不会连续运行的有边界作业。
+此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式类似于MapReduce等批处理框架，适用于已知输入、不常驻的有边界作业。
 
-Apache Flink 对流处理和批处理统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
+Apache Flink 对流处理和批处理的统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
 
-通过启用`批`执行，我们允许 Flink 应用只有在我们知道输入是有边界的时侯才会使用到的额外的优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略，允许实现更高效的任务调度和故障恢复行为的不同 shuffle。下面我们将介绍一些执行行为的细节。
+通过启用`批`执行模式，Flink 可以进行有边界作业特有的额外优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略、不同 shuffle 提高任务调度效率和故障恢复行为。下面我们将介绍一些执行模式的细节。
 
 ## 什么时候可以/应该使用批执行模式？
 
-`批`执行模式只能用于 _有边界_ 的作业/Flink 程序。边界是数据源的一个属性，告诉我们在执行前，来自该数据源的所有输入是否都是已知的，或者是否会有新的数据出现，可能是无限的。而对一个作业来说，如果它的所有源都是有边界的，则它就是有边界的，否则就是无边界的。
+`批`执行模式只能用于 _有边界_ 的作业/Flink 程序。边界是数据源的一个属性，告诉我们是否在执行之前已经知道来自该数据源的所有输入，或者新数据是否会出现，该情况下数据可能无限期地出现。对一个作业来说，如果它的所有源都是有边界的，则它就是有边界的，否则就是无边界的。

Review Comment:
   ```suggestion
   `批`执行模式只能用于 _有边界_ 的作业/Flink 程序。边界是数据源的一个属性，告诉我们是否在执行之前已经知道来自该数据源的所有输入，或者新数据是否会无限期地出现。对一个作业来说，如果它的所有源都是有边界的，则它就是有边界的，否则就是无边界的。
   ```



##########
docs/content.zh/docs/dev/datastream/execution_mode.md:
##########
@@ -27,25 +27,25 @@ under the License.
 # 执行模式（流/批）
 DataStream API 支持不同的运行时执行模式，你可以根据你的用例需要和作业特点进行选择。
 
-DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且预计无限期保持在线的无边界作业。
+DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且常驻线上的无边界作业。
 
-此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式更容易让人联想到批处理框架，比如 MapReduce。这种执行模式适用于有一个已知的固定输入，而且不会连续运行的有边界作业。
+此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式类似于MapReduce等批处理框架，适用于已知输入、不常驻的有边界作业。
 
-Apache Flink 对流处理和批处理统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
+Apache Flink 对流处理和批处理的统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
 
-通过启用`批`执行，我们允许 Flink 应用只有在我们知道输入是有边界的时侯才会使用到的额外的优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略，允许实现更高效的任务调度和故障恢复行为的不同 shuffle。下面我们将介绍一些执行行为的细节。
+通过启用`批`执行模式，Flink 可以进行有边界作业特有的额外优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略、不同 shuffle 提高任务调度效率和故障恢复行为。下面我们将介绍一些执行模式的细节。
 
 ## 什么时候可以/应该使用批执行模式？
 
-`批`执行模式只能用于 _有边界_ 的作业/Flink 程序。边界是数据源的一个属性，告诉我们在执行前，来自该数据源的所有输入是否都是已知的，或者是否会有新的数据出现，可能是无限的。而对一个作业来说，如果它的所有源都是有边界的，则它就是有边界的，否则就是无边界的。
+`批`执行模式只能用于 _有边界_ 的作业/Flink 程序。边界是数据源的一个属性，告诉我们是否在执行之前已经知道来自该数据源的所有输入，或者新数据是否会出现，该情况下数据可能无限期地出现。对一个作业来说，如果它的所有源都是有边界的，则它就是有边界的，否则就是无边界的。
 
 而`流`执行模式，既可用于有边界任务，也可用于无边界任务。
 
-一般来说，在你的程序是有边界的时候，你应该使用`批`执行模式，因为这样做会更高效。当你的程序是无边界的时候，你必须使用`流`执行模式，因为只有这种模式足够通用，能够处理连续的数据流。
+一般来说，在你的程序是有边界的时候，应该使用`批`执行模式，因为这样做会更高效。当你的程序是无边界的时候，必须使用`流`执行模式，因为只有这种模式足够通用，能够处理连续的数据流。
 
-一个明显的例外是当你想使用一个有边界作业去自展一些作业状态，并将状态使用在之后的无边界作业的时候。例如，通过`流`模式运行一个有边界作业，取一个 savepoint，然后在一个无边界作业上恢复这个 savepoint。这是一个非常特殊的用例，当我们允许将 savepoint 作为`批`执行作业的附加输出时，这个用例可能很快就会过时。
+一些特殊情况下，你可以使用`流`模式运行有边界作业。其中一种情况为使用有边界作业的运行结果去初始化一些作业状态，并将状态在之后的无边界作业中使用。例如，通过`流`模式运行一个有边界作业，获取一个 savepoint，然后在一个无边界作业上恢复这个 savepoint。目前来说这是一个可行但非常特殊的用例。当我们允许将 savepoint 作为 `批` 执行作业的附加输出时，这个用例会被以`批`执行模式运行有边界作业的更好实践所取代。

Review Comment:
   ```suggestion
   一些特殊情况下，你可以使用`流`模式运行有边界作业。其中一种情况为使用有边界作业的运行结果去初始化一些作业状态，并将该状态在之后的无边界作业中使用。例如，通过`流`模式运行一个有边界作业，获取一个 savepoint，然后在一个无边界作业上恢复这个 savepoint。目前来说这是一个可行但非常特殊的用例。当我们允许将 savepoint 作为 `批` 执行作业的附加输出时，这个用例会被以`批`执行模式运行有边界作业的更好实践所取代。
   ```



##########
docs/content.zh/docs/dev/datastream/execution_mode.md:
##########
@@ -27,25 +27,25 @@ under the License.
 # 执行模式（流/批）
 DataStream API 支持不同的运行时执行模式，你可以根据你的用例需要和作业特点进行选择。
 
-DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且预计无限期保持在线的无边界作业。
+DataStream API 有一种”经典“的执行行为，我们称之为`流（STREAMING）`执行模式。这种模式适用于需要连续增量处理，而且常驻线上的无边界作业。
 
-此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式更容易让人联想到批处理框架，比如 MapReduce。这种执行模式适用于有一个已知的固定输入，而且不会连续运行的有边界作业。
+此外，还有一种批式执行模式，我们称之为`批（BATCH）`执行模式。这种执行作业的方式类似于MapReduce等批处理框架，适用于已知输入、不常驻的有边界作业。
 
-Apache Flink 对流处理和批处理统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
+Apache Flink 对流处理和批处理的统一方法，意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。

Review Comment:
   ```suggestion
   Apache Flink 对流处理和批处理采取统一的处理方式，这意味着无论配置何种执行模式，在有界输入上执行的 DataStream 应用都会产生相同的*最终* 结果。重要的是要注意*最终* 在这里是什么意思：一个在`流`模式执行的作业可能会产生增量更新（想想数据库中的插入（upsert）操作），而`批`作业只在最后产生一个最终结果。尽管计算方法不同，只要呈现方式得当，最终结果会是相同的。
   ```



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