window计算 | 青训营笔记

foliage
86 阅读6分钟

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

概述

数据价值：实时性越高，数据价值越高

流式计算和批式计算对比

批处理：数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。计算引擎为Hive或者Spark等。在计算的时候，数据是完全ready的，输入和输出都是确定的。

小时级批处理：将调度周期换成一小时，理论上可以实现更实时的数仓，但是每次周期性调度申请、释放等过程，比较消耗资源。

image-20220729202743329.png

一些概念：

处理时间窗口

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

处理时间和事件时间

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

watermark

什么是watermark？

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

如何产生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);

如何传递watermark？

每个算子的watermark取上游所有传递给它的watermark数值最小值，同时也要给下游传递watermark数值

image-20220729211124915.png

典型问题

  1. Per-partition VS per-subtask watermark 生成
  • Per-subtask watermark生成 早期版本都是这种机制。典型的问题是如果一个source subtask 消费多个 partition，那么多个partition 之间的数据读取可能会加剧乱序程度。
  • Per-partition watermark生成 新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。
  1. 部分partition/subtask 断流
  • 根据上面提到的 watermark 传递机制，下游 subtask 会将上游所有 subtask 的 watermark 值的最小值作为自身的 watermark 值。如果上游有一个 subtask 的 watermark 不更新了，则下游的 watermark 都不更新。
  • 解决方案：Idle source 当某个 subtask 断流超过配置的 idle 超时时间时，将当前 subtask 置为 idle，并下发一个 idle 的状态给下游。下游在计算自身 watermark 的时候，可以忽略掉当前是 idle 的那些 subtask。
  1. 迟到数据处理

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

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

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

window

典型的Window

  1. Tumble Window（滚动窗口）
  2. Sliding Window（滑动窗口）
  3. Session Window（会话窗口

滚动窗口

划分：

  • 每个key单独划分
  • 每条数据只会属于一个窗口

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

滑动窗口

  • 每个key单独划分
  • 每条数据可能会属于多个窗口

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

会话窗口

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

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

迟到数据处理

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

什么情况下会产生迟到数据？ 只有事件时间下才会有迟到的数据。

迟到数据默认处理？ 丢弃

迟到数据处理

  1. Allow lateness

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

  1. SideOutput（侧输出流）

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

增量计算和全量计算

增量计算：

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

image-20220729214456303.png 全量计算（需要大量缓存）：

image-20220729214529654.png

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

EMIT触发

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

怎么实现？

  1. 在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是： (1) CONTINUE (2) FIRE（触发计算，但是不清理） (3)PURGE (4)FIRE_AND_PURGE
  2. SQL也可以使用，通过配置： (1)table.exec.emit.early-fire.enabled=true (2)table.exec.emit.early-fire.delay=（time）

window高级优化

Mini-batch优化：解决中间输出较多、状态访问比较频繁

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

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

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

案例

1. 使用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)

存在的问题：所有数据都需计算，无法并行。

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

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

问题二

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

\

avatar
文章
阅读
粉丝