流式计算中的Window 机制|青训营笔记
这是我参与【第四届青训营-大数据场】笔记创作活动的第5天
- 数据价值：实时性高、数据价值高
- 批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。
- 通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全 ready 的，输入和输出都是确定性的
- 实时计算:处理时间窗口
- 数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
- 处理时间:数据在流式计算系统中真正处理时所在机器的当前时间。
- 事件时间:数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。
- 实时计算:事件时间窗口
- 数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。
Watermark
Watermark定义：当前系统认为的事件时间所在的真实时间。
Watermark产生：一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。
Watermark传递：这个类似于上节课中介绍的Checkpoint的制作过程，传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。 在数据中插入一些 Watermark来表示当前的真实时间 在数据存在乱序的时候，Watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡
-
- 一般通过Flink Web UI上的信息来观察当前任务的watermark情况
- 这个问题是生产实践中最容易遇到的问题，大家在开发事件时间的窗口任务的时候，经常会忘记了设置watermark，或者数据太少，watermark没有及时的更新，导致窗口一直不能触发。
-Per-partition VS per-subtask watermark 生成
Per-subtask watermark 生成 早期版本都是这种机制。典型的问题是如果一个 source subtask 消费多个 partition，那么多个 partition 之间的数据读取可能会加剧乱序程度。
Per-partition watermark 生成 新版本引入了基于每个 partition 单独的 watermark 生成机制，这种机制可以有效避免上面的问题。
- Per-partition / Per-subtask 生成watermark的优缺点
