这是我参与「第四届青训营」笔记创作活动的的第4天，以下是我的课堂笔记。
本次课程主要分为四个大板块：
1. 概述
2. watermark
3. window
4. 案例分析

1. 概述

1.1 流式计算VS批式计算

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

1.2 批处理

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

周期调度浪费水资源且有可能做不到

1.3 处理时间窗口

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

1.4 处理时间VS事件时间

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

1.5 事件时间窗口

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

1.6 watermark

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

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

1.7 小结

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

2. Watermark

2.1 什么是 Watermark ?

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

2.2如何产生Watermark

SQL: DataStream:

2.3 如何传递Watermark

2.4 如何通过Flink UI观察Watermark ?

去看这个时间戳是否正常，没有的话可能是上游的数据不够多或者数据异常等情况

2.5 典型问题

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

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

2.6 小结

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

3. Window

3.1 Window分类

典型的Window :

Tumble Window(滚动窗口)
Sliding Window（滑动窗口)
Session Window（会话窗口)

其它Window:

全局 Window \
Count Window
累计窗口
.....

3.2 Wwindow 使用

SQL API:

表示API抽象程度的分层，层次越高，抽象程度越高，用户的使用成本就越低，但是表达能力相对来说更有限

3.3 滚动窗口

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

3.4 滑动窗口

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

3.5 会话窗口

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

与前面两个窗口的不同之处：前面两个窗口是固定窗口，因为数据时间唯一确定了他所属的窗口，而会话窗口不能确定最终所属的窗口是哪一个，只能确定这条数据属于哪个窗口。

3.6 迟到的数据处理

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

3.7 增量VS全量计算

增量计算：

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

全量计算:

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

3.8 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.8 Window-高级优化

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

4. 案例分析

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

（使用Flink SQL计算抖音的日活曲线）

问题:所有数据都需要在一个subtask中完成窗口计算，无法并行。
（因为只有时间窗口，必须要有单并发的全局窗口才能够聚合到所有用户的uid）

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

4.2 需求二:计算大数据任务的资源使用

（使用Flink SQL计算大数据任务的资源使用）

问题描述︰大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用(（CPU、内存)）情况上报。一般大数据任务运行时间从几分钟到几小时不等。

需求: 根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。
假设前后两个container结束时间差不超过10min

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

5. 总结

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

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