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

122 阅读5分钟

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

0x00 流式计算

0.1 批式vs流式

3_流式vs批式.png

0.2 批处理

批处理模型典型的数仓架构为T+1架构,即数据计算是天级别的,当天只能看到前一天的计算结果;

通常使用的计算引擎为Hive或者Spark等。计算的时候,数据是完全ready的,输入和输出都是确定性的。 3_批处理1.jpeg 3_批处理0.jpeg

0.3 处理时间窗口

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

0.4 处理时间与事件时间

处理时间:数据在流式计算系统中真正处理时所在机器的当前时间。

事件时间:数据产生的时间,比如客户端、传感器、后端代码等上报数据时的时间。

3_处理时间和事件时间.jpeg

0.5 事件时间窗口

数据实时进入到真实事件发生的窗口中进行计算,可以有效的处理数据延迟和乱序。 3_事件时间窗口.jpeg

0.6 Watermark

在数据中插入一些watermark,来表示当前的真实时间。

在数据存在乱序的时候,watermark就比较重要了,它可以用来在乱序容忍和实时性之间做一个平衡。 3_Watermark0.png 3_Watermark1.png


0x01 Watermark

Watermark表示系统认为的当前真实的事件时间

  • SQL中使用事件时间字段减去指定时间来表示Watermark

  • DataStream中指定ofSeconds()指定时间,事件时间减去指定数值表示

1.1 Watermark的传递

每次从上游传递值中选择最小值作为Watermark

3_传递Watermark.png

1.2 Watermark典型问题

1.2.1 典型问题一

  • Per-partition VS per-subtask watermark生成

    1. Per-subtask watermark生成

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

    2. Per-partition watermark生成

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

1.2.2 典型问题二

  • 部分partition/subtask断流

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

  • 解决方案:Idle source

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

1.2.3 典型问题三

  • 迟到数据处理

    因为watermark表示当前事件发生的真实时间,那晚于watermark的数据到来时,系统会认为这种数据是迟到的数据。算子自身来决定如何处理迟到数据:

    * Window聚合,默认会丢弃迟到数据

    * 双流join,如果是outer join,则可以认为它不能join到任何数据

    * CEP,默认丢弃


0x02 Window

2.1 Window使用

3_Windows使用.png

2.2 Window分类

2.2.1 滚动窗口

  • 窗口划分:

    1. 每个key单独划分

    2. 每条数据只会属于一个窗口

  • 窗口触发:

    Window结束时间到达的时候一次性触发

3_滚动.png

2.2.2 滑动窗口

  • 窗口划分:

    1. 每个key单独划分

    2. 每条数据可能会属于多个窗口

  • 窗口触发:

    Window结束时间到达的时候一次性触发

3_滑动.png

2.2.3 会话窗口

  • 窗口划分:

    1. 每个key单独划分

    2. 每条数据会单独划分为一个窗口,如果window之间有交集,则会对窗口进行merge

  • 窗口触发:

    Window:结束时间到达的时候一次性触发

3_会话.png

2.3 迟到数据处理

  • 一条数据到来后,会用WindowAssigner给它划分一个window,一般时间窗口是一个时间区间,比如[10:00,11:00),如果划分出来的window end比当前的watermark值还小,说明这个窗口已经触发了计算了,这条数据会被认为是迟到数据。

  • 只有事件时间下才会有迟到的数据,迟到的数据将会被丢弃。

  • 处理方式:

    1. Allow lateness

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

    2. SideOutput(侧输出流)

    这种方式需要对迟到数据打一个tag,然后在DataStream上根据这个tag获取到迟到数据流,然后业务层面自行选择进行处理。适用于:DataStream

2.4 增量 VS 全量计算

  • 增量计算:

    1. 每条数据到来,直接进行计算,window只存储计算结果。比如计算sum,状态中只需要存储sum的结果,不需要保存每条数据。

    2. 典型的reduce、aggregate等函数都是增量计算

    3. SQL中的聚合只有增量计算

  • 全量计算:

    1. 每条数据到来,会存储到window的state中。等到window触发计算的时候,将所有数据拿出来一起计算。

    2. 典型的process函数就是全量计算

2.5 EMIT触发

  • 什么是EMIT

    1. 通常来讲,window都是在结束的时候才能输出结果,比如1h的tumble window,只有在1个小时结束的时候才能统一输出结果。如果窗口比较大,比如1h或者1天,甚至于更大的话那计算结果输出的延迟就比较高,失去了实时计算的意义。

    2. EMIT输出指的是,在window没有结束的时候,提前把window计算的部分结果输出出来。

  • 如何实现

    1. 在DataStream里面可以通过自定义Trigger来实现

    2. Triggert的结果可以是:CONTINUE、FIRE(触发计算,但是不清理)、PURGE、FIRE_AND_PURGE

    3. SQL也可以使用,通过配置:

    table.exec.emit.early-fire.enabled=true
    table.exec.emit.early-fire.delay={time)

0x03 Window - 高级优化

3.1 Mini-batch优化

3_Window - 高级优化0.png

Mini-batch用来解决"中间结果较多,状态访问较频繁"的问题

3_Window - 高级优化1.png

3.2 倾斜优化 - local-global

3_Window - 高级优化2.png

3.3 Distinct计算状态复用

3_Window - 高级优化3.jpeg

3_Window - 高级优化4.png

3.4 Pane优化

将窗口划分为更小的粒度,输出时需要进行merge

3_Window - 高级优化5.png 3_Window - 高级优化6.png