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

1 概述

1.1 流计算 vs批计算

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

1.2 批处理

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

问题：是否可以做到小时级别的批数据？

1.3 处理时间窗口

实时计算：处理时间窗口(window)

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

1.4 处理时间 VS 事件时间

事件时间事件产生的时间，比如用户上传数据的时间
处理时间服务器中，真正处理这个事件的时间

如图可以看到： 处理时间永远慢于事件时间

1.5 事件时间窗口

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

1.6 WaterMark

没有乱序的情况

在数据中插入一些watermark，来表示当前的真实时间，配合事件窗口处理数据乱序。

比如这个数据：数据依次递增，就没有乱序

乱序

比如这个，有乱序的数据，说明数据迟到了，可能需要被丢弃

2 WaterMark

2.1 什么是WaterMark

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

2.2 如何产生WaterMark

SQL

DataStream

如何传递 Watermark

如图可以看到有三个task，source，map，window。
对于接收多个watermark，选取最小的对于接收单个watermark，那就接收

2.3如何通过Flink UI观察watermark？

2.4典型问题

1 Per-partition VS per-subtask watermark生成

2 部分partition/subtask断流

3 迟到数据处理

3 Window

3.1 Window 基本功能

Window 分类 典型的window：

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

其它Window：

全局window
count window
累计窗口
...

Window 使用

滚动窗口

滑动窗口

会话窗口

3.2 迟到数据处理

怎么定义迟到

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

默认的处理方式：遗弃这个数据

只有事件事件才会有迟到数据

3.2.1 迟到数据处理

1.Allow lateness

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

适用于：DataStream、SQL

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

适用于：DataStream

例子

3.2.2 增量和全量计算

增量计算

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

全量计算

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

3.2.3 EMIT 触发

什么是EMIT 通常来讲，winsow都是在结束的时候才能输出结果，比如1h的tumble window，只有在1个小时结束的时候才能统一输出结果。

如果窗口比较大，把比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。

EMIT输出指的是，在window没有结束的时候，提前把window计算的部分结果输出出来，可以将中间结果多次输出

实现

在DataStream里可以通过自定义Trigger来实现，Trigger的结果可以是：

CONTIUNE
FIRE(出发计算，但是不清理）
PURGE
FIRE_AND_PURGE

SQL也可以使用，通过配置：

table.exec.emit.early-fire.enabled=true
table.exec.emit.early-fire.delay=(time)

3.3window 高级优化

3.3.1 Mini-Bitch 优化

简单理解：让算子一次存储一小批数据，对这一小批读取一次状态

3.3.2 倾斜优化-local-global

简单理解：有的节点计算量过大，在这个节点之前进行处理。

3.3.3 Dinstinct计算状态复用降低状态量

3.3.4 Pane优化

简单理解：滑动窗口有一些数据是复用的，我们可以把窗口分为小窗口，先存储小窗口的数据，需要用的时候累加就好。

4 案例分析

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

问题所有数据都在一个task，一个window中运行，数据量太大无法一次计算完成。