并行流中的 Watermark
Watermark 在源函数处或源函数之后直接生成。源函数的每个并行子任务通常独立生成其水印。这些水印定义了该特定并行源处的事件时间。
随着 Watermark 在流媒体程序中的流动，它们会提前到达其到达的 Operator 的 Event Time。每当 Operator 提前其事件时间时，都会为其后续 Operator 在下游生成新的 Watermark。
一些运算符消费多个输入流；例如，并集 union、键控 keyBy(…) 或分区 partition(…) 函数的运算符。这样的 Operator 的当前事件时间是其输入流的事件时间中的最小值。随着其输入流更新其事件时间，Operator 也将更新。
下图显示了流过并行流的事件和 Watermark 的示例，Operator 跟踪事件时间。
（并行流用的不多，这里留个坑吧，待之后用到再来补=-=）
延迟的元素
某些元素可能会违反 Watermark 条件，这意味着即使在发生 Watermark(t) 之后，也会出现更多时间戳为 t'<= t 的元素。实际上，在许多现实世界的设置中，某些元素可以任意延迟，从而无法指定某个事件时间戳记的所有元素都将发生的时间。此外，即使可以限制延迟，通常也不希望将 Watermark 延迟太多，因为这会导致事件时间窗的评估延迟过多。
由于这个原因，流式传输程序可能会明确期望某些延迟元素。延迟元素是指系统的事件时间时钟（由 Watermark 指示）在经过延迟元素时间戳之后的时间到达的元素。有关如何在事件时间窗口中使用延迟元素的更多信息，请参见允许延迟。
Watermark 实际使用例子
- Generating Timestamps / Watermarks
- Flink Watermark 机制浅析
看了这两篇文章后，能对 Watermark 的设置有个基础的了解，在实际场景中，需要评估下面两者：定期 Watermark或标点 Watermark，了解两者差别后才使用。
总结
本篇主要讲了三种时间类型：Processing Time、Event Time 和 Ingestion Time，了解了它们所发生的位置，三者的使用差别，以及 Watermark 与 事件时间 Event Time 的关系，可以使用 Watermark 来解决乱序的事件流，请参考实际使用例子的链接，调整算法来达到你所需要解决的实际场景~
以及本篇时间 Time 的介绍有点“太干”，学起来有点费力，如有其它学习建议或文章不对之处，请与我联系~
项目地址
https://github.com/Vip-Augus/flink-learning-note
git clone https://github.com/Vip-Augus/flink-learning-note
参考资料
- Event Time
- Flink 从 0 到 1 学习 —— Flink 中几种 Time 详解
- Flink Watermark 机制浅析
- Flink 小贴士 (3): 轻松理解 Watermark
- Generating Timestamps / Watermarks
- 允许延迟
