wuchong commented on a change in pull request #9415: [FLINK-12939][docs-zh] Translate "Apache Kafka Connector" page into C… URL: https://github.com/apache/flink/pull/9415#discussion_r312739365
########## File path: docs/dev/connectors/kafka.zh.md ########## @@ -532,41 +442,28 @@ stream = env </div> </div> -Internally, an instance of the assigner is executed per Kafka partition. -When such an assigner is specified, for each record read from Kafka, the -`extractTimestamp(T element, long previousElementTimestamp)` is called to assign a timestamp to the record and -the `Watermark getCurrentWatermark()` (for periodic) or the -`Watermark checkAndGetNextWatermark(T lastElement, long extractedTimestamp)` (for punctuated) is called to determine -if a new watermark should be emitted and with which timestamp. - -**Note**: If a watermark assigner depends on records read from Kafka to advance its watermarks -(which is commonly the case), all topics and partitions need to have a continuous stream of records. -Otherwise, the watermarks of the whole application cannot advance and all time-based operations, -such as time windows or functions with timers, cannot make progress. A single idle Kafka partition causes this behavior. -A Flink improvement is planned to prevent this from happening -(see [FLINK-5479: Per-partition watermarks in FlinkKafkaConsumer should consider idle partitions]( -https://issues.apache.org/jira/browse/FLINK-5479)). -In the meanwhile, a possible workaround is to send *heartbeat messages* to all consumed partitions that advance the watermarks of idle partitions. +在内部，每个 Kafka 分区执行一个 assigner 实例。当指定了这样的 assigner 时，对于从 Kafka 读取的每条消息，调用 `extractTimestamp(T element, long previousElementTimestamp)` 来为记录分配时间戳，并为 `Watermark getCurrentWatermark()` （定期）或 `Watermark checkAndGetNextWatermark(T lastElement, long extractedTimestamp)` （用于标点符号）以确定是否应该发出新的 watermark 以及使用哪个时间戳。 + +**请注意**： 如果水位线 assigner 依赖于从 Kafka 读取的消息来上涨其水位(通常就是这种情况)，那么所有主题和分区都需要有连续的消息流。否则，整个应用程序的水位将无法上涨，所有基于时间的算子(例如时间窗口或带有计时器的函数)也无法运行。单个的 Kafka 分区也会导致这种反应。这是一个已在计划中的 Flink improvement ，目的是为了防止这种情况发生（请见[FLINK-5479: Per-partition watermarks in FlinkKafkaConsumer should consider idle partitions](https://issues.apache.org/jira/browse/FLINK-5479)）。同时，可能的解决方法是将*心跳消息*发送到所有 consumer 的分区里，从而上涨空闲分区的水位。 Review comment: ```suggestion **请注意**： 如果 watermark assigner 依赖于从 Kafka 读取的消息来上涨其 watermark (通常就是这种情况)，那么所有主题和分区都需要有连续的消息流。否则，整个应用程序的 watermark 将无法上涨，所有基于时间的算子(例如时间窗口或带有计时器的函数)也无法运行。单个的 Kafka 分区也会导致这种反应。这是一个已在计划中的 Flink 改进，目的是为了防止这种情况发生（请见[FLINK-5479: Per-partition watermarks in FlinkKafkaConsumer should consider idle partitions](https://issues.apache.org/jira/browse/FLINK-5479)）。同时，可能的解决方法是将*心跳消息*发送到所有 consumer 的分区里，从而上涨空闲分区的 watermark。 ``` 我更倾向于对 watermark 保持同一种翻译，或者都不翻译。 ---------------------------------------------------------------- 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
