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

Illusionary
545 阅读10分钟

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

流计算中的 Window 计算

Flink可做到有状态计算 checkpoint实时纠正错误 端到端语义

01 概述

1.1流式计算vs批式计算

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

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

1.2 批处理

image.png

1.3处理时间窗口

划分成一个一个小数据

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

image.png

1.4处理时间|事件时间

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

image.png

1.5 事件时间窗口

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

image.png 什么时候算窗口结束？（无法预知）--->由此引入watermark

image.png

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

image.png

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

  • 小结

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

02 Watermark

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

  • SQL image.png

  • DataStream image.png

  • Watermark传递 image.png

  • 有两个并行路，source向下游传递watermark

  • window会选择上游传递下来的最小值作为它的watermark值

通过Flink UI 观察 Watermark

image.png 观察watermarker的时间戳

image.png

典型问题

(1)Per-partition VS per-subtask watermark生成

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

(2)部分partition/subtask断流

  • 根据上面提到的watermark传递机制，下游subtask 会将上游所有subtask的 watermark值的最小值作为自身的 watermark值。如果上游有一个subtask的watermark 不更新了，则下游的watermark都不更新。
  • 解决方案:ldle source
    • 当某个subtask断流超过配置的 idle超时时间时，将当前subtask置为idle，并下发一个idle的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask。

(3)迟到数据处理

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

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

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

  • 总结

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

03 Window

3.1Window分类

  • 典型的Window:
    • Tumble Window（滚动窗口)
    • Sliding Window(滑动窗口)
    • Session Window(会话窗口)
  • 其它 Window:
    • 全局Window
    • Count Window
    • 累计窗口
    • 等等

使用

  • SQL API: image.png
  • 在聚合的地方加一个TUMBLE，定义出一个窗口
  • DataStream API: image.png
  • 加一个窗口定义(5s的处理时间) image.png

滚动窗口

image.png 14个窗口 3个user

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

滑动窗口

image.png

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

会话窗口

image.png

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

迟到数据处理

  • 怎么定义迟到?

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

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

    • 只有事件时间下才会有迟到的数据。处理时间不可能，数据到来后直接进行计算。

  • 迟到数据默认处理?

    • 丢弃

  • 除了丢弃还可怎么处理？

  • Allow lateness

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

  • SideOutput(侧输出流)

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

增量与全量计算

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

image.png

  • 全量计算:
    • 每条数据到来,会存储到window的state中。等到window融发计算的时候,将所有数据拿出来—起计算。
    • 典型的process网数就是全量计算 image.png

EMIT 触发

  • 什么叫EMIT?
    • 通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window，只有在1个小时结束的时候才能统—输出结果。
    • 如果窗口比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。
    • EMIT输出指的是,在window没有结束的时候，提前把window计算的部分结果输出出来。
  • 怎么实现?
    • 在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是:
      • CONTINUE
      • FIRE(触发计算，但是不清理)
      • PURGE
      • FIRE_AND_PURGE
  • SQL也可以使用，通过配置:
    • table.exec.emit.earlyfire.enabled=true
    • table.exec.emit.early-fire.delay={time}
  • 小结
    • 三种(滚动、滑动、会话)窗口的定义
    • 迟到数据处理:AllowLateness、SideOutput
    • 增量计算和全量计算模型
    • EMIT触发提前输出窗口的结果

3.2 Window高级优化

Mini-batch优化

image.png

image.png Simple：

  • 每一条消息都会读写state
  • 大量序列化/反序列化开销 MiniBatch
  • 使用内存进行攒批
  • 内存中即可聚合，减少state读写输出数据少，下游压力降低
  • 大幅提升吞吐

倾斜优化-local-global

  • Local-Global优化即将原先的Aggregate分成Local和Global两阶段聚合，即MapReduce模型中Combine+Reduce处理模式。第一阶段在上游节点本地攒一批数据进行聚合（localAgg），并输出这次微批的增量值（Accumulator）。第二阶段再将收到的Accumulator merge起来，得到最终的结果（globalAgg）。
  • Local-Global本质上能够靠localAgg聚合掉倾斜的数据，从而降低globalAgg热点，从而提升性能。Local-Global用于提升SUM、COUNT、MAX、MIN和AVG等普通Aggregate性能，以及解决这些场景下的数据热点问题。 image.png

LocalGlobal优化可以用来解决聚合时的数据倾斜问题。其核心思想是，将聚合分为两个阶段执行，先在上游进行局部(本地/Local)聚合，再在下游进行全局(Global)聚合，类似MapReduce的Combine + Reduce，即先进行一个本地Reduce，再进行全局Reduce。该方法，只完成了先进行一次聚合，减少数据量这个目标。

Distinct计算状态复用

image.png image.png 这边Distinct 可详见某云文档。 可用groupby 达到去重的同样效果 例如

SELECT expressions FROM tables GROUP BY expressions ;

Pane优化

image.png

  • 以滑动周期为单位，将窗口划分为若干相互不重合的pane。 每个窗口由一到多个pane组成，多个pane对窗口构成了覆盖关系。所谓一个pane即一个滑动周期
  • 当某个数据到来时，并不分配到具体的窗口中，而是根据自己的时间戳计算出该数据所属的pane，并将其保存到对应的pane中。
  • 一个数据仅保存在一个pane中，内存中只有一份。 -当需要触发某个窗口时，计算该窗口包含的所有pane，并取出合并成一个完整的窗口计算

image.png

  • 当某个pane不再需要时，将其从内存中删除

  • 小结

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

04 案例分析

需求一

  • 使用Flink SQL计算抖音的日活曲线 将每天的用户活跃数量画成一个曲线，展示变化过程
  • 问题:所有数据都需要在一个subtask中完成窗口计算，无法并行。 image.png
  • table.exec.emit.early-fire.enabled=true
  • table.exec.emit.early-fire.delay=5min

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

  • 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

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

课程总结

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