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

Rainbow_Sea
101 阅读8分钟

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

今天是大数据专场基础班的第四次课，主要内容是介绍流计算中的 Window 计算，主要分为下面四个板块。

一、 概述

1. 流式计算VS批式计算

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

image.png

2. 批处理

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

image.png

  • 小时级批计算

image.png

3. 处理时间窗口

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

image.png

4. 处理时间VS事件时间

image.png

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

5. 事件时间窗口

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

image.png

6. Watermark

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

image.png

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

image.png

小结

  1. 批式计算一般是T+1的数仓架构
  2. 数据实时性越高，数据的价值越高
  3. 实时计算分为处理时间和事件时间
  4. 事件时间需要Watermark配合来处理乱序

二、 Watermark

1. 什么是 Watermark?

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

2. 如何产生Watermark?

  • SQL

image.png

  • DataStream

image.png

3. 如何传递Watermark?

image.png

4. 如何通过Flink UI观察Watermark?

image.png

image.png

5. 典型问题一

Per-partition Vs per-subtask watermark生成

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

6. 典型问题二

部分partition/subtask断流

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

  • 解决方案: ldle source

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

7. 典型问题三

迟到数据处理

  • 因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据
  • 算子自身来决定如何处理迟到数据:
    • Window聚合，默认会丢弃迟到数据
    • 边双流join，如果是outer join，则可以认为它不能join到任何数据
    • CEP，默认丢弃

小结

  1. 含义:表示系统认为的当前真实时间
  2. 生成:可以通过Watermark Generator来生成
  3. 传递:取上游所有subtask的最小值
  4. 部分数据断流: ldle Source
  5. 迟到数据处理: Window算子是丢弃;Join 算子认为跟之前的数据无法join 到

三、 window

1. 基本功能

1.1 Window分类

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

1.2 Window使用

image.png

1.3 滚动窗口

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

image.png

1.4 滑动窗口

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

image.png

1.5 会话窗口

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

image.png

1.6 迟到数据处理

怎么定义迟到?

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

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

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

image.png

1.7 增量VS全量计算

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

image.png

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

image.png

1.8 EMIT触发

1.8.1 什么叫EMIT?

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

1.8.2 怎么实现?

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

小结

  1. 三种(滚动、滑动、会话)窗口的定义
  2. 迟到数据处理: AllowLateness、SideOutput
  3. 增量计算和全量计算模型
  4. EMIT触发提前输出窗口的结果

2. 高级优化

2.1 Mini-batch优化

image.png

image.png

2.2 倾斜优化-local-global

image.png

2.3 Distinct计算状态复用

image.png

image.png

2.4 Pane优化

image.png

image.png

小结

  1. Mini-batch 优化解决频繁访问状态的问题
  2. local-global优化解决倾斜问题
  3. Distinct状态复用降低状态量
  4. Pane优化降低滑动窗口的状态存储量

四、 案例分析

1. 使用Flink SQL计算抖音的日活曲线

  • 问题：所有数据都需要在一个subtask中完成窗口计算，无法并行
    • 通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可 image.png

2. 使用Flink SQL计算大数据任务的资源使用

  • 问题描述: 大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用(CPU、内存)情况上报。一般大数据任务运行时间从几分钟到几小时不等
  • 需求: 根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源

假设前后两个container结束时间差不超过10min

image.png

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

五、 课程总结

  1. 第一部分介绍了流式计算基本概念，以及和批式计算的区别

  2. 第二部分介绍了watermark的含义、如何生成、如何传递，以及如何处理部分partition断流的问题

  3. 第三部分介绍了三种基本的window的定义，以及迟到数据处理、增量计算VS全量计算、EMIT输出;同时也介绍了local-global优化、mini-batch优化、distinct状态优化、滑动窗口的pane的优化等

  4. 两个案例介绍滚动窗口、会话窗口，以及两阶段聚合解决倾斜问题

引用参考

内容主要参考了李本超老师在「流计算中的 Window 计算」课程里所教授的内容，图片来自于老师的PPT，链接如下：​‌‍‬⁠⁡⁢⁣⁤流计算中的 Window 计算 - 李本超 - ppt.pptx - 飞书文档 (feishu.cn)

avatar
文章
阅读
粉丝