As described in [timestamps and watermark handling](//ci.apache.org/projects/flink/flink-docs-release-1.7/dev/event_timestamps_watermarks.html), Flink provides abstractions that allow the programmer to assign their own timestamps and emit their own watermarks. More specifically, one can do so by implementing one of the `AssignerWithPeriodicWatermarks` and `AssignerWithPunctuatedWatermarks` interfaces, depending on the use case. In a nutshell, the first will emit watermarks periodically, while the second does so based on some property of the incoming records, e.g. whenever a special element is encountered in the stream.
In order to further ease the programming effort for such tasks, Flink comes with some pre-implemented timestamp assigners. This section provides a list of them. Apart from their out-of-the-box functionality, their implementation can serve as an example for custom implementations.
### **Assigners with ascending timestamps 具有升序时间戳的分配方**
The simplest special case for _periodic_ watermark generation is the case where timestamps seen by a given source task occur in ascending order. In that case, the current timestamp can always act as a watermark, because no earlier timestamps will arrive.
Note that it is only necessary that timestamps are ascending _per parallel data source task_. For example, if in a specific setup one Kafka partition is read by one parallel data source instance, then it is only necessary that timestamps are ascending within each Kafka partition. Flink’s watermark merging mechanism will generate correct watermarks whenever parallel streams are shuffled, unioned, connected, or merged.
请注意，仅有必要时间戳是升序 _per parallel data source task_。例如，如果在特定的设置中，一个KAFKA分区由一个并行数据源实例读取，则仅有必要在每个Kafka分区中递增时间戳。每当并行流被混洗、统一、连接或合并时，flink的水印合并机制将产生正确的水印。
...
...
@@ -39,9 +40,9 @@ val withTimestampsAndWatermarks = stream.assignAscendingTimestamps( _.getCreatio
### **Assigners allowing a fixed amount of lateness**
### **Assigners allowing a fixed amount of lateness 指定人允许一定数量的迟到 **
Another example of periodic watermark generation is when the watermark lags behind the maximum (event-time) timestamp seen in the stream by a fixed amount of time. This case covers scenarios where the maximum lateness that can be encountered in a stream is known in advance, e.g. when creating a custom source containing elements with timestamps spread within a fixed period of time for testing. For these cases, Flink provides the `BoundedOutOfOrdernessTimestampExtractor` which takes as an argument the `maxOutOfOrderness`, i.e. the maximum amount of time an element is allowed to be late before being ignored when computing the final result for the given window. Lateness corresponds to the result of `t - t_w`, where `t` is the (event-time) timestamp of an element, and `t_w` that of the previous watermark. If `lateness > 0` then the element is considered late and is, by default, ignored when computing the result of the job for its corresponding window. See the documentation about [allowed lateness](//ci.apache.org/projects/flink/flink-docs-release-1.7/dev/stream/operators/windows.html#allowed-lateness) for more information about working with late elements.
