流式计算中的Window计算|青训营笔记

白木talk
73 阅读3分钟

这是我参与「第四届青训营」笔记创作活动的第4天

一.概述

1.处理时间窗口

实时计算：处理时间窗口

数据是实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务

image.png

  • 处理时间：数据在流式计算系统中真正处理时所在机器的当前时间。
  • 事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。

2.Watermark

image.png

二.Watermark

1.产生方式

image.png 第一种：倒数第二行生成watermark，从原始数据order_time减去5s作为watermark的数值。

第二种：用事件时间减去固定的20s作为watermark的数值

问题一

Per-partition VS per-subtask watermark生成

Per-subtask watermark生成

早期版本都是这种机制。典型的问题是如果一个source suubtask消费多个partition，分区之间读取可能速度不同，那么多个partition之间的数据读取可能会加剧乱序程度。

Per-partition watermark生成

新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。

问题二

部分partition/subtask断流

根据上面提到的watermark传递机制，下游subtask会将上游所有的subtask的watermark值的最小值作为自身的watermark值。如果上游有一个subtask的watermark不更新了，则下游的watermark都不更新。

解决方案：Idle source

当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle，并下发一个idle的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask。

三.Window

1.分类

典型的window：

  • Tumble Window(滚动窗口）
  • Sliding Window（滑动窗口）
  • Session Winsow（会话窗口）

其它Window：

全局window count window 累计窗口 ...

2.迟到数据处理(默认丢弃)

image.png

  1. Allow lateness

这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。会应用到retract机制。

适用于：DataStream、SQL

2.SideOutput（侧输出流） 这种方式需要对迟到数据打一个tag，然后再DataStream上根据这个tag获取迟到数据，然后业务层面自行选择进行处理。

适用于：DataStream

image.png

增量计算：

  • 每条数据到来，直接进行计算，window只存储计算结果。比如计算sum，状态中只需要存储sum的结果，不需要保存每条数据。
  • 典型的reduce、aggregate等级函数都是增量计算 -SQL的聚合只有增量计算

image.png

全量计算：

  • 每条数据到来，会存储到window的state中。等到window出发计算的时候，将所有数据拿出来一起计算。
  • 典型的process函数就是全量计算。

3.EMIT

EMIT输出指的是，在window没有结束的时候，提前把window计算的部分结果输出出来，可以中间结果输出多次，下游可以看到不断变换的结果，也需要用到retract机制，最终满足一致性语义。

怎么实现？ 在DataStream里可以通过自定义Trigger来实现，Trigger的结果可以是：

  • CONTIUNE
  • FIRE(出发计算，但是不清理）
  • PURGE
  • FIRE_AND_PURGE

SQL也可以使用，通过配置：

  • table.exec.emit.early-fire.enabled=true
  • table.exec.emit.early-fire.delay=(time)
avatar
文章
阅读
粉丝