课程目录
这是我参与「第四届青训营」笔记创作活动的的第4天
01.概述
1.1 流式计算 VS 批式计算
数据价值：实时性越高，数据价值越高
1.2批处理
批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。
通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。
1.3处理时间窗口
实时计算:处理时间窗口 数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
1.4 处理时间 VS 事件时间
处理时间:数据在流式计算系统中真正处理时所在机器的当前时间。
事件时间:数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。
1.5事件时间窗口
实时计算:事件时间窗口数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。
什么时候窗口才算结束呢?
1.6 Watermark
在数据中插入一些watermark,来表示当前的真实时间。
V在数据存 在乱序的时候，watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一一个平衡。
01.小结
1.批式计算一般是T+1的数仓架构
2.数据实时性越高，数据的价值越高
3.实时计算分为处理时间和事件时间
4.事件时间需要Watermark配合来处理乱序
02.Watermark
2.1 什么是Watermark
表示系统认为的当前真实的事件时间
2.2 如何产生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>>fo rBounded0utOfOrde rness (Duration. ofSeconds (20)) . withTimestampAss igner( (event, timestamp) -> event.f0);
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生成机制，这种机制可以有效避免上面的问题。
2.6典型问题二
部分partition/subtask断流
根据上面提到的watermark传递机制，下游subtask会将.上游所有subtask的watermark值的最小值作为自身的watermark值。如果.上游有一个subtask的watermark不更新了，则下游的watermark都不更新。
解决方案: ldle source
当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle,并下发一个idle的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask。
2.7典型问题三
迟到数据处理
因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。
算子自身来决定如何处理迟到数据:
1）Window聚合，默认会丢弃迟到数据；
2）双流join,如果是outer join,则可以认为它不能join到任何数据；
3）CEP，默认丢弃
02. Watermark小结
1.含义:表示系统认为的当前真实时间
2.生成:可以通过Watermark Generator来生成
3.传递:取上游所有subtask的最小值
4.部分数据断流: Idle Source
5.迟到数据处理: Window算子是丢弃; Join 算子认为跟之前的数据无法join到
03.Window
3.1 Window分类
典型的Window:
- Tumble Window ( 滚动窗口)
- Sliding Window (滑动窗口)
- Session Window ( 会话窗口)
其它Window:
1.全局Window
2.Count Window
3.累计窗口
3.1 Window使用
3.1滚动窗口
窗口划分:
1.每个key单独划分
2.每条数据只会属于一个窗口
窗口触发:
Window结束时间到达的时候一次性 触发
3.1滑动窗口
窗口划分:
1.每个key单独划分
2.每条数据可能会属于多个窗口
窗口触发:
Window结束时间到达的时候一次性触发
3.1会话窗口
窗口划分:
1.每个key单独划分
2.每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge
窗口触发:
Window结束时间到达的时候一次性触发
3.1迟到数据处理
怎么定义迟到?
一条数据到来后会用WindowAssigner 给它划分-一个window, 一般时间窗口是 -个时间区间， 比如[10:00, 1 1:00)，如果划分出来的window end比当前watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。
什么情况下会产生迟到数据?
只有事件时间下才会有迟到的数据。
迟到数据默认处理?
丢弃
1. Allow lateness
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马.上清理状态，而是会多保留allowl _ateness这么长时间，在这段时间内如果还有数据到来则继续之前的状态进行计算 。
适用于: DataStream、SQL
2. SideOutput (侧输出流)
这种方式需要对迟到数据打一个tag,然后在DataStream上根据这 个tag获取到迟到数据流，然后业务层面自行选择进行处理。
适用于: DataStream
3.1增量 VS 全量计算
增量计算:
1）每条数据到来， 直接进行计算，window只存储计算结果 。比如计算sum,状态中只需要存储sum的结果，不需要保存每条数据。
2）典型的reduce、aggregate等 函数都是增量计算
3）SQL中的聚合只有增量计算
全量计算:
1）每条数据到来，会存储到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算。
2）典型的process函数就是全量计算
3.1 EMIT计算
什么叫EMIT?
通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window,只有在1个小时结束的时候才能统一输出结果。
如果窗口比较大，比如1h或者1天，甚至于更大的话
在DataStream里面可以通过自定义Trigger来实现，那计算结果输出的延迟就比较高，失去了实时计算的意义。
EMIT输出指的是，在window没有结束的时候，提前把window计算的部分结果输出出来。
怎么实现?
Trigger的结果可以是:
1）CONTINUE
2）FIRE ( 触发计算，但是不清理)
3）PURGE
4）FIRE AND_ PURGE
SQL，也可以使用，通过配置:
1） table.exec.emit.early-fire.enabled=true
2） table.exec.emit.early-fire.delay= {time}
3.1 小结
1.三种(滚动、滑动、会话)窗口的定义
2.迟到数据处理: Allowl ateness、SideOutput
3.增量计算和全量计算模型
4.EMIT触发提前输出窗口的结果
3.2 Window - 高级优化
3.2 Mini-batch优化
3.2倾斜优化 - local-global
3.2 Distinct计算状态复用
3.2Pane优化
03.小结
1.Mini-batch优化解决频繁访问状态的问题
2.local-global 优化解决倾斜问题
3.Distinct 状态复用降低状态量
4.Pane 优化降低滑动窗口的状态存储量
04.案例分析
4.1需求一
使用Flink SQL计算抖音的日活曲线
4.1需求一:计算抖音的日活曲线
问题:所有数据都需要在一个subtask中完成窗口计算，无法并行。
SELECT COUNT(DISTINCT uid) as dau TUMBLE_ START(event_ time, INTERVAL '1' DAY) as wstart, LOCALTIMESTAMP AS current_ ts FROM user_ activity GROUP BY TUMBLE( event_ time, INTERVAL '1' DAY)
table.exec.emit.early-fire.enabled-true
table.exec.emit.early-fire.delay-5min
4.1需求一:计算抖音的日活曲线
通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可。
SELECT SUM(partial cnt) as dau TUMBLE_ START( event_ time, INTERVAL '1' DAY) as wstart, LOCALTIMESTAMP as current ts FROM ( SELECT COUNT(DISTINCT uid) as partial cnt, TUMBLE_ ROWTIME (event_ time, INTERVAL '1' DAY) as event time FROM user_ activity GROUP BY TUMBLE(event_ time, INTERVAL， '1' DAY), MOD(uid，10000) --根据uid分为10000个桶 GROUP BY TUMBLE( event _time， INTERVAL '1' DAY)
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计算大数据任务的资源使用
4.2需求二:计算大数据任务的资源使用
问题描述: 大数据任务( 特指离线任务)运行时通常会有多个container启动并运行，每个 container在运行结束的时候，YARN会负责将它的资源使用(CPU、 内存)情况 上报。一般大数据任务运行时间从几分钟到几小时不等。
需求:
根据YARN.上报的各个container的信息，在任务结束的时候，尽快的计算出一个 任务运行所消耗的总的资源。
假设前后两个container结束时间差不超过10min
4.2需求二:计算大数据任务的资源使用
SEL ECT application_ id SUM( cpu usage) as cpu_ total . SUM( memory_ usage) as memory total, FROM resource_ usage GROUP BY application_ id, SESSION ( event_ time， INTERVAL ' 10' MINUTE )
典型的可以通过会话窗口来将数据划分到一个window中，然后再将结果求和即可。
课程总结
-
流式计算基本概念和批式计算的区别，直接将离线仓做实时运算有哪些困难；
-
Watermark的含义、如何产生和传递以及生产实践遇到的问题和解决办法；
-
三种典型的Window和迟到数据处理、增量计算VS全量计算、EMIT输出；
-
Window高级优化：Mini-batch、倾斜优化、Distinct状态复用和Pane优化。
