大数据-复习笔记-4 | 青训营笔记

能鸽善鹉
243 阅读8分钟

流式计算中的Window机制-复习笔记

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

1. 概述

1.1 流式计算VS批式计算

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

1.2 批处理

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

1.2.1 小时级批处理

  • 将调度级别下降到小时级，每小时一次调度，理论上可以实现更实时的数仓，但是每次周期处理调度外还有申请、释放等过程，比较消耗资源。
  • 一般线上数仓任务，计算时间从几分钟到几小时不等，分布不均匀，数仓的建模是分层的，三层五层甚至七层都存在，若所有的数据从产生到计算完成都要求在一个小时内，在很多场景下是做不到的。

1.2.2 处理时间窗口

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

1.2.3 处理时间VS事件时间

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

1.2.4 事件时间窗口

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

1.2.5 Watermark

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

2. Watermark

2.1 什么是Watermark

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

2.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);

2.3 如何传递Watermark

2.4 如何通过Flink UI观察 Watermark

2.5 典型问题

  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聚合，默认会丢弃迟到数据；
    • 双流oin，如果是outer join，则可以认为它不能join到任何数据；
    • CEP，默认丢弃。

3. Window

3.1 基本功能

3.1.1 Window分类

  • 典型的Window：
  1. Tumble Window（滚动窗口）
  2. Sliding Window（滑动窗口）
  3. Session Window（会话窗口）
  • 其它Window：
  1. 全局Window
  2. Count Window
  3. 累计窗口
  4. ...

3.1.2 滚动窗口

  • 窗口划分：
  1. 每个 key 单独划分
  2. 每条数据只会属于一个窗口
  • 窗口触发：
    Window 结束时间到达的时候一次性触发

3.1.3 滑动窗口

  • 窗口划分：
  1. 每个 key 单独划分
  2. 每条数据可能会属于多个窗口
  • 窗口触发：
    Window 结束时间到达的时候一次性触发

3.1.4 会话窗口

  • 窗口划分：
  1. 每个key单独划分
  2. 每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge
  • 窗口触发：
    Window结束时间到达的时候一次性触发

3.1.5 迟到数据的处理

  • 怎么定义迟到？
    一条数据到来后，会用WindowAssigner 给它划分一个 window，一般时间窗口是一个时间区间，比如[10：00，11：00），如果划分出来的 window end 比当前的 watermark 值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。
  • 什么情况下会产生迟到数据？
    只有事件时间下才会有迟到的数据。
  • 迟到数据默认处理？
    丢弃
  1. Allow lateness
    这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留 allowLateness 这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
    适用于：DataStream、SQL
  2. SideOutput（侧输出流）
    这种方式需要对迟到数据打一个 tag，然后在 DataStream 上根据这个 tag 获取到迟到数据流，然后业务层面自行选择进行处理。
    适用于：DataStream

3.1.6 增量VS全量计算

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

3.1.7 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.2 高级优化

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

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

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

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

4. 案例分析

4.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)

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

4.2 需求二：使用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中，然后再将结果求和即可。

5. 课程总结

  1. 第一部分介绍了流式计算基本概念，以及和批式计算的区别
  2. 第二部分介绍了watermark的含义、如何生成、如何传递，以及如何处理部分partition断流的问题
  3. 第三部分介绍了三种基本的window的定义，以及迟到数据处理、增量计算VS全量计算、EMIT输出；同时也介绍了local-global优化、mini-batch优化、distinct状态优化、滑动窗口的pane的优化等
  4. 两个案例介绍滚动窗口、会话窗口，以及两阶段聚合解决倾斜问题
avatar
文章
阅读
粉丝