网页设计规划,seo对网店推广的作用有哪些,php代码删除网站,destoon 网站后台显示不出模板1.乱序问题
流处理从事件产生#xff0c;到流经source#xff0c;再到operator#xff0c;中间是有一个过程和时间的#xff0c;虽然大部分情况下#xff0c;流到operator的数据都是按照事件产生的时间顺序来的#xff0c;但是也不排除由于网络、分布式等原因#xff0…1.乱序问题
流处理从事件产生到流经source再到operator中间是有一个过程和时间的虽然大部分情况下流到operator的数据都是按照事件产生的时间顺序来的但是也不排除由于网络、分布式等原因导致乱序的产生所谓乱序就是指Flink接收到的事件的先后顺序不是严格按照事件的Event Time顺序排列的。
一旦出现乱序如果只根据eventTime决定window的运行我们不能明确数据是否全部到位但又不能无限期的等下去此时必须要有个机制来保证一个特定的时间后必须触发window去进行计算了这个特别的机制就是Watermark。
例如某App会记录用户的所有点击行为并回传日志在网络不好的情况下先保存在本地延后回传。A用户在11:02对App进行操作B用户在11:03对App进行操作但是A用户的网络不太稳定回传日志延迟了导致我们在服务端先接受到B用户11:03的消息然后再接受到A用户11:02的消息消息乱序了。
2.什么是Watermark
Watermark是Apache Flink提出的一种用来解决乱序、延迟数据等情况的解决方案。
它是建立在事件时间上的一个概念用来刻画数据流的完整性。如果按照处理时间来衡量事件一切都是有序的、完美的自然而然也就不需要Watermark了。换句话说事件时间带来了乱序的问题而Watermark就是用来解决乱序问题。所谓的乱序其实就是有事件延迟了对于延迟的元素我们不可能无限期的等下去必须要有一种机制来保证一个特定的时间后必须触发Window进行计算。这个特别的机制,就是Watermark,它告诉了算子延迟到达的消息不应该再被接收。
watermrk具体特点如下
Watermark是一种衡量Event Time进展的机制。Watermark是用于处理乱序事件的通常用Watermark机制结合window来实现。数据流中的Watermark用于表示timestamp小于Watermark的数据都已经到达了因此window的执行也是由Watermark触发的。Watermark可以理解成一个延迟触发机制我们可以设置Watermark的延时时长t每次系统会校验已经到达的数据中最大的maxEventTime然后认定eventTime小于maxEventTime - t的所有数据都已经到达如果有窗口的停止时间等于maxEventTime – t那么这个窗口被触发执行。watermark 用来让程序自己平衡延迟和结果正确性。
3.Watermark原理
Watermark会携带一个单调递增的时间戳tWatermark(t)表示所有时间戳不大于t的数据都已经到来了未来小于等于t的数据不会再来因此可以放心地触发和销毁窗口了。
当Flink,接收到数据时会按照一定的规则去生成Watermark这条Watermark就等于当前所有到达数据中的maExertT me-延N时长也就定说Watermark是基于数据携带的时间戳生成的一旦Watermark比当前未触发的窗口的停止时间要晚那么就会触发相应窗口的执行。由于eventtime是由数据携带的因此如果运行过程中无法获取新的数据那么没有被触发的窗口将永远都不被触发。
4.延迟数据处理机制
Watermark能够应对乱序的数据但是真实世界中没法得到一个完美的 Watermark数值。要么没法获取到要么耗费太大因此实际工作中会近似 Watermark(t)之后还有较小的概率接收到时间戳t之前的数据在Flink中将这些数据定义为“late elements”可以在Window中指定允许延迟的最大时间默认为О)。
延迟事件是乱序事件的特例和一般乱序事件不同的是它们的乱序程度超出了水位线( Watermark)的预计导致窗口在它们到达之前已经关闭。
延迟事件出现时窗口已经关闭并产出了计算结果对于此种情况处理的方法有3种:
重新激活已经关闭的窗口并重新计算以修正结果。将延迟事件收集起来另外处理。将延迟事件视为错误消息并丢弃。
Flink默认的处理方式是第3种直接丢弃其他两种方式分别使用Side Output和AllowedLateness。
Side Output机制将延迟事件单独放入一个数据流分支这会作为Window计算结果的副产品以便用户获取并对其进行特殊处理。迟来的数据同样可以触发窗口进行输出。Allowed Lateness机制允许用户设置一个允许的最大延迟时长。Flink会在窗口关闭后一直保存窗口的状态直至超过允许延迟时长这期间的延迟事件不会被丢弃而是默认会触发窗口重新计算。因为保存窗口状态需要额外内存并且如果窗口计算使用了ProcessWindowFunction APl还可能使得每个延迟事件触发一次窗口的全量计算代价比较大所以允许延迟时长不宜设得太长延迟事件也不宜过多。
