流式计算中的Window机制 ｜ 青训营笔记

用户7353691004881
159 阅读7分钟

流式计算中的Window机制 ｜ 青训营笔记

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

重点内容：

一、概述

1、流式计算 vs 批式计算

数据价值：数据的实时性越高，那么数据价值越高

特征批式计算流式计算
数据存储HDFS、HiveKafka、Pulsar
数据时效性天级别分钟级别
准确性精准精准和时效性之间取舍
典型计算引擎Hive、Spark、FlinkFlink
计算模型Exactly-OnceAt Least Once/Exacty Once
资源模型定时调度长期持有
主要场景离线天级别数据报表实时数仓、实时营销、实时风控

从表中可以看出，批式处理的实时性是较低的，所以需要引入流式计算加强实时性--数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。

1、 处理时间窗口

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

2、 处理时间VS事件时间

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

3、 事件时间窗口

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

4、 Watermark

  • 在数据中插入一些 watermark，来表示当前的真实时间。
  • 在数据存在乱序的时候，watermark 就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡。

二、Watermark

1、 什么是Watermark

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

2、 如何产生Watermark

  • SQL

CREATE TABLE Orders( user BIGINT, product STRING, order_time TIMESTAMP(3), WATERMARK FOR order_time AS order_time-INTERVAL '5' SECOND ) WITH(...);

  • DataStream

WatermarkStrategy .<Tuple2<Long,String>>forBoundedoutofOrderness(Duration.ofSeconds(20)) .withTimestampAssigner((event,timestamp)->event.f0);

3、 如何通过Flink UI观察 Watermark

典型问题：

（一）Per-partition VS per-subtask watermark 生成

Per-subtask watermark生成 早期版本都是这种机制。典型的问题是如果一个source subtask 消费多个 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。

（三）迟到数据处理

  • 因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。

  • 算子自身来决定如何处理迟到数据：

1、Window聚合，默认会丢弃迟到数据；

2、双流join，如果是outer join，则可以认为它不能join到任何数据；

3、CEP，默认丢弃

三、Window

1、Window分类

典型的Window：

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

其它Window：

  • 全局Window
  • Count Window
  • 累计窗口

滚动窗口

  • 窗口划分：

  • 每个 key 单独划分

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

  • 窗口触发： Window 结束时间到达的时候一次性触发

滑动窗口

  • 窗口划分：

  • 每个 key 单独划分

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

  • 窗口触发： Window 结束时间到达的时候一次性触发

会话窗口

  • 窗口划分：

  • 每个key单独划分

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

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

2、迟到数据的处理

  • 怎么定义迟到？

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

  • 什么情况下会产生迟到数据？

只有事件时间下才会有迟到的数据。

  • 迟到数据默认处理？

丢弃

  1. Allow lateness
    这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留 allowLateness 这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
    适用于：DataStream、SQL
  2. SideOutput（侧输出流）
    这种方式需要对迟到数据打一个 tag，然后在 DataStream 上根据这个 tag 获取到迟到数据流，然后业务层面自行选择进行处理。
    适用于：DataStream

增量VS全量计算

  • 增量计算：

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

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

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

图一： image.png

  • 全量计算：

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

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

图二： image.png EMIT 触发

  • 什么叫EMIT？

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

  • 怎么实现？
    在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是：
    (1) CONTINUE
    (2) FIRE（触发计算，但是不清理）
    (3)PURGE
    (4)FIRE_AND_PURGE

SQL也可以使用，通过配置：
(1)table.exec.emit.early-fire.enabled=true
(2)table.exec.emit.early-fire.delay=（time）

3、高级优化

  • Mini-batch
    Mini-batch优化解决频繁访问状态的问题

  • 倾斜优化-local-global
    local-global 优化解决倾斜问题

  • Distinct 计算状态复用
    Distinct 状态复用降低状态量

  • Pane 优化
    Pane 优化降低滑动窗口的状态存储量

四、案例分析

需求一：使用Flink SQL 计算抖音的日活曲线

SELECT COUNT(DISTINCT uid) as dau TUMBLE_START(event_time, INTERVAL '1' DAY) as wstart, LOCALTIMESTAMP AS current_ts FROM user_activity GROUP BY TUMBLE(event_time, INTERVAL '1' DAY)

配置： table. exec. emit. early-fire. enabled=true
table. exec. emit. early-fire. delay=5min

存在问题：所有数据都需要在一个窗口中进行计算，无法并行。

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

思路如下：

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_time，INTERVAL，'1'DAY）， MOD（uid，10000）--根据uid分为10000个桶 ) GROUP BY TUMBLE（event_time，INTERVAL'1'DAY）

配置：

table.exec.emit.early-fire.enabled=true
table.exec.emit.early-fire.delay=5min
table.exec.window.allow-retract-input=true

需求二：使用Flink SQL 计算大数据任务的资源使用

问题描述：
大数据任务（特指离线任务）运行时通常会有多个 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_time,INTERVAL '10'MINUTE)

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

注：

图片来源

图一：青训营

图二：青训营

avatar
文章
阅读
粉丝