这是我参与「第四届青训营 」笔记创作活动的第6天
本次笔记重点内容
-
- 对比流式计算跟批式计算
-
- 介绍实时计算中的Watermark概念，以及如何产生、传递，还有一些典型的生产实践中遇到的问题
流式计算 VS 批式计算
实时性越高，数据价值越高
- 资源模型：计算本身使用的资源的模型，定时调度是指批式计算的过程中跑一个任务处理完需要处理的数据就结束了，长期持有指流式计算的过程中资源是持续有效
处理时间窗口
数据实时流动和计算，窗口结束直接发送结果，不需要周期任务调度
处理时间 VS 事件时间
处理时间是数据在流式计算系统中真正处理时所在机器的当前时间，事件时间是数据产生的时间。
- 一大挑战是根据事件时间的真实时间来计算窗口
Watermark
表示当前系统认为的事件时间所在的真实时间
主要利于数据乱序时在乱序容忍和实时性之间做一个平衡，比如我们插入11的一个数据W（11），若在这个数据之后（即左边）有比这个数小的数据，我们就认为存在延迟，并防止它进入接下来的计算。
如何传递Watermark？
上游会将watermark传递给下游，下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，如window（2）收到29和14两个数值，会把14当作自己的watermark，同时它也会将自己watermark传递给它的下游，经过整个传递过程，最终系统中每一个计算单元都会实时的知道自身当前的watermark是多少。
如何通过Flink Web UI观察Watermark？
Per-partition VS per-subtask watermark
在Flink里早期都是per-subtask的方式进行watermark的生成，但是每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而增加数据的乱序程度。新版本引入per-partition的方式来产生watermark，来避免上面的问题。
部分partition/subtask断流
如果上游有一个subtask的watermark不更新了，则下游的都不更新了。
- Idle source：我们可以用一种idle状态来标记上游这种subtask，并下发一个idle状态给下游，被标记为这种状态的subtask在计算watermark的时候可以把它先排除在外，这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。
迟到数据处理
算子自身决定如何处理迟到数据，Window聚合、双流join、CEP，默认丢弃
