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

JESSY
100 阅读8分钟

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

01.概述

简述流式计算的基本概念，与批式计算相比的难点和挑战

1.1 流式计算VS批式计算

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

image.png

1.2 批处理

批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。

通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。

image.png

image.png

1.3 处理时间窗口

实时计算：处理时间窗口

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

image.png

1.4 处理时间VS事件时间

image.png

处理时间：数据在流式计算系统中真正处理时所在机器的当前时间。

事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。

1.5 事件时间窗口

实时计算：事件时间窗口

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

image.png

1.6 Watermark

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

image.png

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

01.小结

  1. 批式计算一般是T+1的数仓架构

  2. 数据实时性越高，数据的价值越高

  3. 实时计算分为处理时间和事件时间

  4. 事件时间需要 Watermark配合来处理乱序

02.Watermark

Watermark的含义、生成方法、传递机制，以及一些典型场景的问题和优化

2.1 什么是Watermark?

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

2.2 如何产生 Watermark?

  • SQL

image.png

  • DataStream

image.png

2.3 如何传递Watermark?

image.png

2.4 如何通过 Flink UI 观察 Watermark?

image.png

image.png

2.5 典型问题一

Per-partition VS per-subtask watermark 生成

  • Per-subtask watermark生成

早期版本都是这种机制。典型的问题是如果一个source subtask消费多个partition,那么多个partition之间的数据读取可能会加剧乱序程度。

  • Per-partition watermark生成

新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。

2.6 典型问题二

部分 partition/subtask 断流

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

解决方案：ldle source

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

2.7 典型问题三

迟到数据处理

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

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

  • Window聚合，默认会丢弃迟到数据

  • 双流join,如果是outer join,则可以认为它不能join到任何数据

  • CEP，默认丢弃

02.Watermark小结

  1. 含义：表示系统认为的当前真实时间

  2. 生成：可以通过Watermark Generator来生成

  3. 传递：取上游所有subtask的最小值

  4. 部分数据断流：Idle Source

  5. 迟到数据处理：Window算子是丢弃；Join算子认为跟之前的数据无法join到

03.Window

Window基本功能和高级优化。

3.1 基本功能

Window分类

典型的Window:

  1. Tumble Window(滚动窗口）

  2. Sliding Window(滑动窗口）

  3. Session Window(会话窗口）

其它Window:

  1. 全局Window

  2. Count Window

  3. 累计窗口

  4. ……

Window 使用

image.png

图中SQL和DATa Stream/DataSet API分别对应下列的SQL API，DataStream API。

  • SQL API

image.png

  • DataStream API

image.png

滚动窗口

窗口划分：

  1. 每个key单独划分

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

窗口触发：

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

image.png

滑动窗口

窗口划分：

  1. 每个key单独划分

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

窗口触发：

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

image.png

会话窗口

窗口划分：

  1. 每个key单独划分

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

窗口触发：

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

image.png

迟到数据处理

  • 怎么定义迟到？

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

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

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

  • 迟到数据默认处理？

    丢弃

  1. Allow lateness

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

适用于：DataStream、SQL

  1. SideOutput（侧输出流）

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

适用于：DataStream

image.png

增量VS 全量计算

增量计算：

  • 每条数据到来，直接进行计算，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.early-fire.enabled=true

  • table.exec.emit.early-fire.delay={time}

3.1 小结

  1. 三种（滚动、滑动、会话）窗口的定义

  2. 迟到数据处理：AllowLateness、SideOutput

  3. 增量计算和全量计算模型

  4. EMIT触发提前输出窗口的结果

3.2 高级优化

Mini-batch 优化

image.png

image.png

倾斜优化-local-global

image.png

Distinct 计算状态复用

image.png

image.png

Pane 优化

image.png

image.png

03.小结

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

  2. local-global 优化解决倾斜问题

  3. Distinct状态复用降低状态量

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

04.案例分析

抖音 DAU 实时曲线计算

大数据任务资源使用实时统计分析

4.1 需求一：计算抖音的日活曲线

使用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

4.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. 两个案例介绍滚动窗口、会话窗口，以及两阶段聚合解决倾斜问题

avatar
文章
阅读
粉丝