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

serendipity__
96 阅读9分钟

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

流计算中的 Window 计算

一、概述

1.1 流式计算与批式计算的对比

image.png

1.2 批处理

批处理模型典型的数仓架构为T↓1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。 通常使用的计算3 |擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。 image.png

小时级批计算

image.png

1.3 处理时间窗口

实时计算:处理时间窗口 数据实时流动，实时计算，窗结束直接发送结果，不需要周期调度任务。 image.png

1.4 处理时间 VS 事件时间

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

1.5 事件时间窗口

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

image.png 1.6 Watermark 在数据中插入watermark，来表示当前的真实时间

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

image.png

二、Watermark

2.1 什么是watermark？

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

2.2 如何产生watermark？

image.png

2.3 如何传递Watermark？

这个类似于上节课中介绍的Checkpoint的制作过程，传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。

image.png

2.4 如果通过Flink UI 观察Watermark？

image.png

2.5 典型问题一

Per-partition VS per- subtask watermark生成

  • Per-subtask watermark生成 早期版本都是这种机制。典型的问题是如果一个source subtask消费多个partition,那么多个partition之间的数据读取可能会加剧乱序程度。
  • Per-partition watermark生成 新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。

2.6 典型问题二

部分partition/subtask断流

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

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

2.7 典型问题三

迟到数据处理

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

  • Window聚合，默认会丢弃迟到数据
  • 双流join, 如果是outer join, 则可以认为它不能join到任何数据
  • CEP， 默认丢弃

三、Window

3.1 Window基本使用

image.png

TUMBLE Window （滚动窗口）

这是最常见的窗口类型，就是根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中windowStart = timestamp - timestamp % windowSize，这条数据所属的window就是[windowStart, windowStart + windowSize)

Flink 中的窗口划分是key级别的 比如下方的图中，有三个key，那每个key的窗口都是单独的。每条数据只会属于一个窗口所以整个图中，一种存在14个窗口。

窗口的触发，是时间大于等于window end的时候，触发对应的window的输出（计算有可能提前就增量计算好了），目前的实现是给每个window都注册一个timer，通过处理时间或者事件时间的timer来触发window的输出 image.png

HOP Window （滑动窗口）

上面的TUMBLE窗口是每条数据只会落在一个窗口中。在HOP窗口中，每条数据是可能会属于多个窗口的（具体属于多少，取决于窗口定义的大小和滑动），比如下图中假设滑动是1h的话，那窗口大小就是2h，这种情况每条数据会属于两个窗口。除了这一点之外，其它的基本跟HOP窗口是类似的，比如也是key级别划分窗口，每条数据可能会属于多个窗口。

窗口触发：也是靠timer进行窗口触发输出。Windows结束时间到达的时候一次性触发。

image.png

SESSION Window （会话窗口）

会话窗口跟上面两种窗口区别比较大，上面两个窗口的划分，都是根据当前数据的时间就可以直接确定它所属的窗口。会话窗口的话，是一个动态merge的过程。一般会设置一个会话的最大的gap，比如10min。会话窗口中，每条数据会单独划分为一个窗口，如果Windows之间有交集，则会对窗口进行merge，

那某个key下面来第一条数据的时候，它的window就是 [event_time, event_time + gap)，当这个key后面来了另一条数据的时候，它会立即产生一个窗口，如果这个窗口跟之前的窗口有overlap的话，则会将两个窗口进行一个merge，变成一个更大的窗口，此时需要将之前定义的timer取消，再注册一个新的timer。

所以会话窗口要求所有的聚合函数都必须有实现merge。

image.png

3.1.1 迟到数据

定义迟到：一条数据到来以后，会用WindowsAssigner给他划分一个window，一般时间窗口是一个时间区间，如果划分出来的window end比当前的watermark值还小，说明这个窗口已经触发了计算，这条数据会被认为是迟到数据。只有事件时间才有迟到数据。

对于迟到的数据，我们现在有两种处理方式：

  1. 使用side output方式，把迟到的数据转变成一个单独的流，再由用户自己来决定如何处理这部分数据

  2. 直接drop掉

注意：side output只有在DataStream的窗口中才可以用，在SQL中目前还没有这种语义，所以暂时只有drop这一个策略。

3.1.2 增量计算 VS 全量计算

  • 增量计算:
    • 每条数据到来，直接进行计算，window只存储计算结果。比如计算sum,状态中只需要存储sum的结果，不需要保存每条数据。
    • 典型的reduce、aggregate等函数都是增量计算
    • SQL 中的聚合只有增量计算
  • 全量计算:
    • 每条数据到来，会存储到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算。
    • 典型的process函数就是全量计算

3.1.3 EMIT触发

1、什么叫EMIT?

通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window,只有在1个小时结束的时候才能统一输出结果。

如果窗比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。

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

2、怎么实现?

在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是:

  • CONTINUE
  • FIRE (触发计算， 但是不清理)
  • PURGE
  • FIRE _AND_PURGE
  • SQL也可以使用，通过配置:
  • table.exec.emit.early-fire.enabled =true
  • table.exec.emit.early-fire.delay ={time}

3.2 Window-高级优化

3.2.1 Mini-batch优化

image.png

image.png

3.2.2 倾斜优化

image.png

3.2.3 Distinct计算状态复用

image.png

3.2.4 Pane优化

滑动窗口如上面所述，一条数据可能会属于多个window。所以这种情况下同一个key下的window数量可能会比较多，比如3个小时的窗口，1小时的滑动的话，每条数据到来会直接对着3个窗口进行计算和更新。这样对于状态访问频率是比较高的，而且计算量也会增加很多。

优化方法就是，将窗口的状态划分成更小粒度的pane，比如上面3小时窗口、1小时滑动的情况，可以把pane设置为1h，这样每来一条数据，我们就只更新这条数据对应的pane的结果就可以了。当窗口需要输出结果的时候，只需要将这个窗口对应的pane的结果merge起来就可以了。

注意：这里也是需要所有聚合函数都有merge的实现的

image.png

四、案例分析

案例一：计算实时抖音DAU曲线

DAU(Daily Active User)：指的是每天的去重活跃用户数

输出：每个5s更新一下当前的DAU数值，最终获得一天内的DAU变化曲线

要求：通过上面课程中学到的窗口的功能以及相关的优化，开发一个Flink SQL任务，使得可以高效的计算出来上面要求的实时结果。

SELECT
SUM(partial_ .cnt)
as dau
TUMBLE_ START(event_ _time, INTERVAL '1' DAY) as wstart,
LOCALTIMESTAMP as current_ ts
FROM (
SELECT
COUNT(DISTINCT uid) as partial_ .cnt,
TUMBLE_ _ROWTIME( event_ _time, INTERVAL '1' DAY) as event_ time
FROM user_ _activity
GROUP BY
TUMBLE(event_ .t ime, INTERVAL， '1' DAY),
MOD(uid，10000)  //根据uid分为10000个桶
GROUP BY TUMBLE( event_ time， INTERVAL '1' DAY)

通过俩阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可。

案例二：计算大数据任务的资源使用

问题描述：大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用（CPU、内存）情况上报。一般大数据任务运行时间从几分钟到几小时不等。

需求：根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。假设前后两个container结束时间差不超过10min。

SELECT
application_ id
SUM(cpu_ _usage) as cpu_ total
SUM ( memory_ _usage) as memory_ total,
FROM resource_ usage
GROUP BY
application_ id,
SESSION ( event_ t ime，INTERVAL' 10 ' MINUTE )

典型的可以通过会话窗口来将数据划分到一个window中，然后再将结果求和即可。

avatar
文章
阅读
粉丝