流式计算中的Window机制 ｜ 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的的第6天
概述
流式计算vs批式计算
特性 批式计算 流式计算 数据存储 HDFS、Hive Kafka、Pulsar 数据时效性 天级别 分钟级别 准确性 精准 精准和时效性之间取舍 典型计算引擎 Hive、Spark、Flink Flink 计算模型 Exactly-Once At least Once/Exactly-Once 资源模型 定时调度 长期持有（一直占用资源进行计算） 主要场景 离线天级别数据报表 实时数仓、实时营销、实时风控
处理时间：数据在流式计算系统中真正处理时所在机器的当前时间
事件时间：数据产生时间，客户端、传感器、后端代码等上报数据时的时间
实时计算：事件时间窗口，数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。 为了解决数据延迟到到达和乱序问题，引入watermark。
Watermark
watermark
系统认为的当前真实的事件时间
如何产生Watermark
-
SQL： Create Table Orders( user BIGINT, product STRING, order_time TIMESTAMP(3), WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND )WITH(...);
-
DataStream: WatermarkStrategy .<Tuple2<Long, String>>forBoundOutOrderness(Duration.ofSecond(20)) .withTimestampAssigner((event, timestamp) -> event.f0)
如何传递Watermark？
使用Flink UI 观察Watermark
Window基本功能
window分类
-
Tumble window
-
Sliding window
-
Session window
-
其他窗口
- 全局窗口
- count window
- 累计窗口
- 自定义窗口
window使用
SQL API和DataStream API使用 SQL API：TUMBLE（order_time, INTERVAL '1' DAY） DataStream: .window(TumblingProcessingTimeWindows.of(Time.seconds(5)))
滚动窗口
- 窗口划分：
- 每个key单独划分
- 每条数据只会属于一个窗口
- 窗口触发：
- window结束时间到达的时候一次性触发
滑动窗口
- 窗口划分：
- 每个key单独划分
- 每条数据可能会属于多个窗口
- 窗口触发：
- window结束时间到达的时候一次性触发
会话窗口
- 窗口划分：
- 每个key单独划分
- 每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge
- 窗口触发： window结束时间达到的时候一次性触发
迟到数据处理
- Allow lateness：设置允许迟到时间，窗口正常计时结束后，不会马上清理状态，数据保留迟到时间指定的时间。
- SideOutput（侧输出流）：需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取迟到数据流，然后业务层面自行选择处理。
增量VS全量计算
-
增量计算：数据到来时直接进行计算，存储结果，不保存每条数据。
-
全量计算：每条数据都会存储到window的state中。
EMIT触发
在window没有结束的时候提前把window计算的部分结果输出。 DataStream可以通过自定义Trigger来实现
window高级优化
Mini-batch优化
倾斜优化-local global
处理节点数据太多，shuffle负担大。
Distinct计算状态复用
Pane优化
窗口划分小粒度，重叠部分去重，最后在merge。
案例分析
使用Flink SQL计算抖音日活曲线
滚动窗口 + EMIT
计算大数据任务的资源使用
会话窗口
